Przykłady zasad MXC

W tych przykładach pokazano, jak wymagania dotyczące obciążenia przekładają się na uprawnienia zasobów MXC. Możesz rozpocząć od przewodnika Szybki start dla języka C#, TypeScript lub Rust, a następnie dostosować konfigurację do obciążenia.

Poniższy kod JSON używa nieprzetworzonej struktury konfiguracji wykonania dla schematu MXC 1.0.0. Pełne konfiguracje obejmują wersję i polecenie; sekcje oznaczone jako fragmenty muszą być włączone do istniejącej konfiguracji. Podczas tworzenia w języku C#, TypeScript lub Rust użyj odpowiednich typów zestawu SDK w wersji 1, które nie wymagają określonej wersji schematu.

To są przykłady systemu Windows. Zastąp ścieżki istniejącymi zasobami na hoście, świadomie zapewnij wszelkie dodatkowe zależności narzędzi i upewnij się, że wersja zestawu SDK i zaplecze obsługują wybrane kontrolki.

Uruchom narzędzie o zakresie repozytorium

Ta kompletna konfiguracja używa tego samego wzorca odczytu wejściowego/zapisu wyjściowego co przewodnik Szybki start. Utwórz C:\src\my-app\input.txt i katalog C:\src\mxc-output przed jego uruchomieniem. Polecenie może odczytać katalog źródłowy i zapisywać w katalogu wyjściowym, ale nie może zapisywać w katalogu źródłowym ani używać sieci lub interfejsu użytkownika.

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "process",
  "process": {
    "commandLine": "C:\\Windows\\System32\\cmd.exe /d /c type input.txt > C:\\src\\mxc-output\\result.txt",
    "cwd": "C:\\src\\my-app",
    "env": [
      "SystemRoot=C:\\Windows",
      "LOCALAPPDATA=C:\\src\\mxc-output",
      "TEMP=C:\\src\\mxc-output",
      "TMP=C:\\src\\mxc-output"
    ],
    "timeout": 30000
  },
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app", "C:\\Windows\\System32\\cmd.exe"],
    "readwritePaths": ["C:\\src\\mxc-output"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "injection": false
  }
}

W tym przykładzie przyjęto założenie, że Windows jest zainstalowana w folderze C:\Windows; użyj rzeczywistego katalogu systemowego na hoście. Żądanie Windows ProcessContainer z jawną listą env musi zawierać zarówno SystemRoot, jak i LOCALAPPDATA. Po zastąpieniu polecenia narzędziem kompilacji lub analizy skonfiguruj jego pamięci podręczne i pliki tymczasowe tak, aby używały dedykowanego katalogu z możliwością zapisu, zamiast przyznawać prawa zapisu do całego repozytorium.

Chroń poświadczenia w ramach szerszego uprawnienia

Poprzednia konfiguracja udziela dostępu do odczytu dla C:\src\my-app. Jeśli ten katalog zawiera plik środowiska lub katalog secrets, dodaj ten fragment wewnątrz istniejącej filesystem sekcji, zachowując listy tylko do odczytu i do zapisu:

{
  "deniedPaths": [
    "C:\\src\\my-app\\.env",
    "C:\\src\\my-app\\secrets"
  ]
}

Te niedozwolone ścieżki znajdują się wewnątrz dozwolonego katalogu źródłowego. Zachowaj niepowiązane repozytoria i katalogi profilów użytkowników poza uprawnieniami.

Przechowuj sekrety poza drzewami uprawnień, jeśli to możliwe. Sprawdź nakładające się uprawnienia i odmowy dla wybranego backendu; niektóre backendy zamontowanych katalogów odrzucają zagnieżdżone odmowy zamiast ich wymuszania.

Zezwalaj na bezpośredni dostęp do zakresu adresów IP

Ten fragment konfiguracji zastępuje sekcję network. Zezwala na ruch wychodzący przez port TCP 443 do zatwierdzonego zakresu CIDR i odmawia innego ruchu wychodzącego, ruchu przychodzącego i dostępu zwrotnego hosta. Podawaj zatwierdzone zakresy z zaufanej konfiguracji zamiast akceptować je z obciążenia.

{
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        {
          "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }]
        }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

192.0.2.0/24 jest zakresem tylko do dokumentacji. Zastąp go zatwierdzonymi adresami docelowej usługi. Reguła zezwala na protokół TCP na tym porcie, a nie tylko na HTTPS, jedną nazwę hosta lub jedną usługę aplikacji. Bezpośrednie rozwiązywanie nazw hostów może wymagać oddzielnej reguły DNS.

Ten przykład wymaga backendu i hosta obsługującego bezpośrednie reguły ruchu wychodzącego (egress). Nie łącz tego z runtimeConfig.networkProxy. W przypadku decyzji HTTP(S) opartych na nazwach hostów należy zamiast tego użyć obsługiwanej konfiguracji opartej na serwerze proxy.

Użyj serwera proxy dostarczonego przez aplikację

Aplikacja hosta musi uruchomić serwer proxy przed uruchomieniem obciążenia. W tym przykładzie skonfigurowano MXC tak, aby korzystało z istniejącego serwera proxy; nie implementuje, nie uruchamia ani nie zatwierdza zasad obsługi żądań przez serwer proxy.

Poniższy fragment konfiguracji jest przeznaczony dla Windows ProcessContainer ze wspieraną ścieżką wymuszania serwera proxy na poziomie systemu operacyjnego. Scal je z pełną konfiguracją, zachowując polecenie, uprawnienia systemu plików, limit czasu i ograniczenia interfejsu użytkownika. Zastąp punkt końcowy i nazwę peera odpowiednimi wartościami uruchomionego serwera proxy.

{
  "containment": "processcontainer",
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "allow", "hostLoopback": "deny" }
  },
  "runtimeConfig": {
    "networkProxy": "http://127.0.0.1:8080"
  },
  "processContainer": {
    "network": {
      "allowedProxyPeer": "<package-family-name-or-appcontainer-profile-name>"
    }
  }
}

allowedProxyPeer identyfikuje zainstalowany pakiet serwera proxy lub nierozpakowany profil AppContainera. Serwer proxy musi nasłuchiwać skonfigurowanego adresu i portu sprzężenia zwrotnego oraz spełniać udokumentowane wymagania wstępne Windows. Usługa MXC nie wywnioskuje tego identyfikatora z adresu URL.

Important

To mapowanie Windows wymaga ingress.default: "allow", co również zezwala na ruch do serwerów w sieci prywatnej. hostLoopback: "deny" utrzymuje ogólny dostęp do pętli zwrotnej hosta zamknięty, gdy skonfigurowany węzeł proxy jest osiągalny. Przykład nie jest konfiguracją typu all-inbound-denied.

Bezpośredni dostęp do Internetu pozostaje zablokowany na ścieżce wymuszania. Serwer proxy kontroluje, które żądania HTTP(S) przekazuje dalej. Zwykły, niepakietowany serwer proxy hosta bez tożsamości AppContainer wymaga innej, szerszej konfiguracji zgodności; nie usuwaj allowedProxyPeer i nie zakładaj, że te same ograniczenia pozostaną.

Użyj odpowiednich typów zestawu SDK i zweryfikuj obsługę przed użyciem dostępu wyłącznie przez serwer proxy. Zobacz Opcje wdrażania serwera proxy ProcessContainer, aby uzyskać informacje o wymaganiach wstępnych systemu Windows, oraz sieć kierunkową dla innych backendów.

Zezwalanie na widoczne narzędzie bez szerokiego dostępu do interfejsu użytkownika

W przypadku obciążenia wymagającego widocznego okna i danych wejściowych schowka ten fragment konfiguracji zastępuje element ui. Umożliwia odczyty okien i schowka, ale nie zapisy schowka ani syntetyczne dane wejściowe z klawiatury i wskaźnika:

{
  "ui": {
    "disable": false,
    "clipboard": "read",
    "injection": false
  }
}

W zestawie SDK ContainerRequestw wersji 1 równoważne właściwości interfejsu użytkownika to disable, clipboardi allowInputInjection. Zezwalaj na odczyt ze schowka tylko wtedy, gdy wymaga tego zadanie. Sprawdź obsługę interfejsu użytkownika środowiska uruchomieniowego i przetestuj wymagane ograniczenia dla każdego hosta docelowego.

Ponowne używanie piaskownicy obsługującej stan

Użyj wykonywania uwzględniającego stan, gdy polecenia muszą współużytkować środowisko. Utwórz i uruchom je, wykonaj polecenia, a następnie zatrzymaj i usuń je po zakończeniu. Zadbaj o czyszczenie po niepowodzeniu i anulowaniu, a nie tylko po sukcesie.

Wywołania obsługujące stan używają ProvisionRequest specyficznego dla danej fazy i oddzielnego ExecutionRequest dla każdego polecenia, a nie pełnej konfiguracji jednorazowej powyżej. Aprowizowanie zwraca nieinterpretowalne ContainerId; przekaż je bez zmian do późniejszych faz. Użyj MxcLifecycle w .NET, funkcji cyklu życia TypeScript, takich jak v1::container, lub funkcji Rust provisionContainer, takich jak provision_container, z IsolationSession lub WSLc, zapleczami obsługiwanymi przez interfejsy API cyklu życia V1. Aby uzyskać dokładne wymagania, zobacz pojęcia dotyczące cyklu życia, cykl życia kontenera MXC oraz przewodnik .NET, TypeScript lub Rust SDK.

Sprawdź, co wymusza zaplecze cyklu życia, zanim je wybierzesz. IsolationSession oddziela użytkownika i sesję obciążenia, ale nie stosuje filtrowania systemu plików MXC, interfejsu użytkownika ani sieci, a jego żądanie musi jawnie zezwalać na cały ruch sieciowy. Sieć WSLc jest w pełni izolowana lub w pełni mostkowana, bez reguł dla poszczególnych miejsc docelowych. Aby uzyskać szczegółowe informacje, zobacz Wybieranie typu kontenera oraz wybór i ustawienia zaplecza.

Zweryfikuj przykłady

Dla każdej dostosowanej zasady przetestuj zamierzone zachowanie i próby niewłaściwego użycia:

  • Upewnij się, że wymagane dane wejściowe mogą być odczytywane i wymagane dane wyjściowe mogą być zapisywane.
  • Upewnij się, że poświadczenia i niepowiązane pliki pozostają niedostępne.
  • Upewnij się, że połączenia bezpośrednie, połączenia w sieci lokalnej, pętla zwrotna i połączenia przychodzące są zgodne z zasadami.
  • W przypadku dostępu opartego na serwerze proxy upewnij się, że zatwierdzone żądanie zakończy się pomyślnie, a bezpośrednia próba internetowa zakończy się niepowodzeniem.
  • Upewnij się, że schowek, iniekcja danych wejściowych i widoczne okna są zgodne z zasadami interfejsu użytkownika.
  • Upewnij się, że przekroczenia limitu czasu i oczyszczanie działają po powodzeniu, niepowodzeniu i anulowaniu.

Użyj Learning Mode, aby zbadać brakujący dostęp. Nie przyznawaj automatycznie dostępu do każdego zasobu obserwowanego przez reprezentatywne uruchomienie.

Treści powiązane

  • Ostatnia aktualizacja o