Voorbeelden van MXC-beleid

In deze voorbeelden ziet u hoe de workloadvereisten worden omgezet in MXC-resourcemachtigingen. U kunt beginnen met de quickstart C#, TypeScript of Rust en vervolgens de configuratie aanpassen aan uw workload.

De onderstaande JSON maakt gebruik van de onbewerkte vorm van de uitvoeringsconfiguratie voor het MXC-1.0.0schema. Volledige configuraties bevatten een versie en commando; secties die als fragmenten worden gelabeld, moeten worden opgenomen in een bestaande configuratie. Wanneer u in C#, TypeScript of Rust schrijft, gebruikt u de bijbehorende V1 SDK-typen, waarvoor geen specifieke schemaversie is vereist.

Dit zijn Windows voorbeelden. Vervang de paden door bestaande resources op uw host, verleen expliciet eventuele aanvullende afhankelijkheden van hulpprogramma's en bevestig dat de geselecteerde besturingselementen door uw SDK-release en back-end worden ondersteund.

Een hulpprogramma op opslagplaatsniveau uitvoeren

Deze volledige configuratie maakt gebruik van hetzelfde patroon read-input/write-output als de quickstart. Maak C:\src\my-app\input.txt en de C:\src\mxc-output map voordat u deze uitvoert. De opdracht kan de bronmap lezen en naar de uitvoermap schrijven, maar kan niet naar de bronmap schrijven of het netwerk of de gebruikersinterface gebruiken.

{
  "$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
  }
}

In dit voorbeeld wordt ervan uitgegaan dat Windows is geïnstalleerd op C:\Windows; gebruik de werkelijke systeemmap op uw host. Een Windows ProcessContainer-aanvraag met een expliciete env lijst moet zowel SystemRoot als LOCALAPPDATA bevatten. Wanneer u de opdracht vervangt door een build- of analysehulpprogramma, configureert u de caches en tijdelijke bestanden om de toegewezen schrijfbare map te gebruiken in plaats van schrijftoegang te verlenen tot de hele repository.

Inloggegevens beveiligen binnen een bredere machtiging

De voorgaande configuratie verleent leestoegang tot C:\src\my-app. Als deze map een omgevingsbestand of een map met secrets bevat, voegt u dit fragment toe in de bestaande filesystem sectie, waarbij de lijsten met alleen-lezen en schrijflijsten behouden blijven:

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

Deze geweigerde paden bevinden zich in de toegestane bronmap. Bewaar niet-gerelateerde repositories en gebruikersprofielmappen buiten de machtigingen.

Bewaar geheimen buiten toegestane directorystructuren, indien mogelijk. Controleer overlappende toestaan- en weigeren-regels op de geselecteerde backend; sommige backends met aangekoppelde mappen weigeren geneste weigeringen in plaats van ze af te dwingen.

Directe toegang tot een IP-bereik toestaan

Dit configuratiefragment vervangt de network sectie. Hiermee wordt uitgaand verkeer via TCP-poort 443 naar een goedgekeurd CIDR-bereik toegestaan en wordt andere uitgaande toegang, inkomend verkeer en host-loopback-toegang geweigerd. Lever goedgekeurde bereiken aan vanuit vertrouwde configuratie in plaats van ze van de workload te accepteren.

{
  "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 is een range met alleen documentatie. Vervang deze door de goedgekeurde adressen van de beoogde service. De regel staat TCP toe op die poort, niet uitsluitend HTTPS, één hostnaam of één toepassingsservice. Directe hostnaamomzetting kan een afzonderlijke DNS-regel vereisen.

Voor dit voorbeeld is een back-end en host vereist die ondersteuning biedt voor regels voor direct uitgaand verkeer. Combineer het niet met runtimeConfig.networkProxy. Gebruik in plaats daarvan een ondersteunde configuratie op basis van een proxy voor op hostnamen gebaseerde HTTP(S)-beslissingen.

Een door de toepassing geleverde proxy gebruiken

Uw host-app moet de proxy starten voordat de host-app de workload start. In dit voorbeeld wordt MXC geconfigureerd voor het gebruik van een bestaande proxy; het implementeert, start of keurt het beleid voor verzoekafhandeling van de proxy niet goed.

Het volgende configuratiefragment is gericht op Windows ProcessContainer met een ondersteund pad voor het afdwingen van proxy's op OS-niveau. Voeg deze samen in de volledige configuratie, waarbij de opdracht, bestandssysteemmachtigingen, time-outs en ui-beperkingen behouden blijven. Vervang het eindpunt en de peernaam door die van uw actieve 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 identificeert het geïnstalleerde pakket of het niet-verpakte AppContainer-profiel van de proxy. De proxy moet luisteren naar het geconfigureerde loopback-adres en de poort en voldoen aan de gedocumenteerde Windows vereisten. MXC leidt die identiteit niet af uit de URL.

Important

Voor deze Windows-toewijzing is ingress.default: "allow" vereist, waardoor ook verkeer naar servers op het privénetwerk mogelijk is. hostLoopback: "deny" houdt algemene toegang tot host-loopback gesloten terwijl de geconfigureerde proxy peer bereikbaar is. Het voorbeeld is geen configuratie waarbij al het inkomende verkeer wordt geweigerd.

Directe internettoegang blijft geweigerd op het afdwingingspad. De proxy bepaalt welke HTTP(S)-verzoeken deze doorstuurt. Een gewone, niet-verpakte hostproxy zonder een AppContainer-identiteit heeft een andere, bredere compatibiliteitsconfiguratie nodig; verwijder allowedProxyPeer niet en ga ervan uit dat dezelfde beperkingen behouden blijven.

Gebruik de bijbehorende SDK-typen en controleer de ondersteuning voordat u vertrouwt op toegang alleen via een proxy. Zie de opties voor de implementatie van ProcessContainer-proxy's voor Windows-vereisten en directionele netwerkconfiguratie voor andere back-ends.

Een zichtbaar hulpprogramma zonder brede gebruikersinterfacetoegang toestaan

Voor een workload die een zichtbaar venster en klembordinvoer nodig heeft, vervangt uidit configuratiefragment . Hiermee kunnen vensters en klembord-leesbewerkingen worden uitgevoerd, maar geen klembord-schrijfbewerkingen of synthetische toetsenbord- en aanwijzerinvoer:

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

In een V1 SDK ContainerRequestzijn disablede equivalente UI-eigenschappen , clipboarden allowInputInjection. Verleen alleen leestoegang tot het klembord wanneer de werkbelasting deze vereist. Controleer de ondersteuning van de runtime-gebruikersinterface en test de vereiste beperkingen op elke doelhost.

Een statusbewuste sandbox opnieuw gebruiken

Gebruik toestandsbewuste uitvoering wanneer opdrachten een omgeving moeten delen. Richt deze in en start deze, voer de opdrachten uit, stop deze en maak de inrichting ervan ongedaan wanneer u klaar bent. Opschonen na mislukking en annulering, niet alleen na succes.

Toestandsbewuste aanroepen maken gebruik van een fasespecifiek ProvisionRequest en afzonderlijk ExecutionRequest voor elke opdracht, niet de volledige configuratie met één shot hierboven. Provisioning retourneert een ondoorzichtig ContainerId; geef deze ongewijzigd door aan latere fasen. Gebruik MxcLifecycle in .NET, de TypeScript-levenscyclusfuncties zoals provisionContainer, of de v1::container-functies van Rust zoals provision_container, met IsolationSession of WSLc, de back-ends die de V1-levenscyclus-API's ondersteunen. Zie de levenscyclusconcepten, de levenscyclus van MXC-containers en de .NET SDK-handleiding, TypeScript- of Rust-SDK-handleiding voor exacte vereisten.

Controleer wat elke levenscyclusback-end afdwingt voordat u deze kiest. IsolationSession scheidt de gebruiker en de sessie van de workload, maar past geen MXC-bestandssysteem-, UI- of netwerkfiltering toe en de aanvraag moet expliciet al het netwerkverkeer toestaan. WSLc-netwerken zijn volledig geïsoleerd of volledig gebridged, zonder regels per bestemming. Zie Een insluitingstype kiezen en back-endselectie en instellingen voor meer informatie.

Controleer de voorbeelden

Test voor elke aangepaste beleidsregel zowel het beoogde gedrag als een poging tot misbruik:

  • Controleer of de vereiste invoer kan worden gelezen en de vereiste uitvoer kan worden geschreven.
  • Controleer of aanmeldgegevens en niet-gerelateerde bestanden niet toegankelijk blijven.
  • Controleer of directe, lokale netwerk-, loopback- en binnenkomende verbindingen overeenkomen met het beleid.
  • Controleer voor toegang op basis van een proxy of een goedgekeurde aanvraag slaagt en dat een directe internetpoging mislukt.
  • Controleer of het klembord, invoerinjectie en zichtbare vensters overeenkomen met het ui-beleid.
  • Bevestig dat time-outs en opschonen werken na succes, mislukking en annulering.

Gebruik Learning Mode om ontbrekende toegangsrechten te onderzoeken. Ken niet automatisch elke resource toe die een representatieve uitvoering waarneemt.

Verwante onderwerpen

  • Laatst bijgewerkt om