Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questi esempi illustrano come i requisiti del carico di lavoro si traducono in autorizzazioni per le risorse MXC. È possibile iniziare con l'avvio rapido C#, TypeScript o Rust e quindi adattare la configurazione al carico di lavoro.
Il codice JSON seguente usa la struttura di configurazione dell'esecuzione non elaborata per lo schema MXC 1.0.0. Le configurazioni complete includono una versione e un comando; le sezioni etichettate come frammenti devono essere incorporate in una configurazione esistente. Quando si crea in C#, TypeScript o Rust, usare i tipi SDK V1 corrispondenti, che non richiedono una versione specifica dello schema.
Questi sono esempi di Windows. Sostituire i percorsi con le risorse esistenti nell'host, concedere intenzionalmente eventuali dipendenze aggiuntive degli strumenti e verificare che il rilascio dell'SDK e il back-end supportino i controlli selezionati.
Eseguire uno strumento a livello di repository
Questa configurazione completa usa lo stesso modello lettura-input/scrittura-output della guida rapida. Crea C:\src\my-app\input.txt e la directory C:\src\mxc-output prima di eseguirla. Il comando può leggere la directory di origine e scrivere la directory di output, ma non può scrivere nella directory di origine o usare la rete o l'interfaccia utente.
{
"$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 questo esempio si presuppone che Windows sia installato in C:\Windows; usare la directory di sistema effettiva sul sistema host. Una richiesta Windows ProcessContainer con un elenco esplicito env deve includere sia SystemRoot che LOCALAPPDATA. Quando si sostituisce il comando con uno strumento di compilazione o analisi, configurare le cache e i file temporanei in modo da usare la directory scrivibile dedicata anziché concedere l'accesso in scrittura all'intero repository.
Proteggere le credenziali all'interno di un'autorizzazione più ampia
La configurazione precedente concede l'accesso in lettura a C:\src\my-app. Se tale directory contiene un file di ambiente o una directory dei segreti, aggiungere questo frammento all'interno della sezione esistente filesystemsezione, mantenendo gli elenchi di sola lettura e di lettura/scrittura:
{
"deniedPaths": [
"C:\\src\\my-app\\.env",
"C:\\src\\my-app\\secrets"
]
}
Questi percorsi negati si trovano all'interno della directory di origine concessa. Mantenere repository non correlati e directory del profilo utente al di fuori delle autorizzazioni.
Mantenere i segreti al di fuori delle strutture di autorizzazione concesse, quando possibile. Verificare le concessioni sovrapposte e i dinieghi nel back-end selezionato; alcuni back-end di directory montate rifiutano i dinieghi annidati anziché applicarli.
Consentire l'accesso diretto a un intervallo IP
Questo frammento di configurazione sostituisce la network sezione . Consente il traffico TCP in uscita sulla porta 443 verso un intervallo CIDR approvato e nega tutti gli altri accessi in uscita, in ingresso e di loopback dell'host. Fornitura di intervalli approvati dalla configurazione attendibile anziché accettarli dal carico di lavoro.
{
"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 è un intervallo di versioni solo per la documentazione. Sostituirlo con gli indirizzi approvati del servizio previsto. La regola consente TCP su tale porta, non solo HTTPS, un solo nome host o un solo servizio applicativo. La risoluzione diretta dei nomi host può richiedere una regola DNS separata.
Questo esempio richiede un back-end e un host che supportano regole in uscita dirette. Non combinarlo con runtimeConfig.networkProxy. Per le decisioni HTTP(S) basate su hostname, usare invece una configurazione basata su proxy supportata.
Usare un proxy fornito dall'applicazione
L'app host deve avviare il proxy prima di avviare il carico di lavoro. Questo esempio configura MXC per l'uso di un proxy esistente; non implementa, avvia o approva i criteri di gestione delle richieste del proxy.
Il seguente frammento di configurazione è destinato a Windows ProcessContainer con un percorso supportato di applicazione del proxy a livello di sistema operativo. Unirlo alla configurazione completa, mantenendo il comando, le autorizzazioni del file system, il timeout e le restrizioni dell'interfaccia utente. Sostituire l'endpoint e il nome del peer con quelli del proxy in esecuzione.
{
"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 identifica il pacchetto installato del proxy o il profilo AppContainer non pacchettizzato. Il proxy deve restare in ascolto sull'indirizzo e sulla porta di loopback configurati e soddisfare i prerequisiti Windows documentati. MXC non ricava tale identità dall'URL.
Importante
Questo mapping Windows richiede ingress.default: "allow", che consente anche il traffico del server sulla rete privata.
hostLoopback: "deny" mantiene l'accesso generale al loopback dell'host chiuso mentre il peer proxy configurato è raggiungibile. L'esempio non è una configurazione con tutto il traffico in ingresso negato.
L'accesso diretto a Internet rimane negato nel percorso di imposizione. Il proxy controlla quali richieste HTTP(S) inoltra. Un proxy host semplice e non in pacchetto senza un'identità AppContainer richiede una configurazione di compatibilità diversa e più ampia; non rimuovere allowedProxyPeer presumendo che le stesse restrizioni rimangano.
Usare i tipi SDK corrispondenti e verificare il supporto prima di basarsi sull'accesso solo proxy. Vedere Opzioni di distribuzione proxy ProcessContainer per i prerequisiti di Windows e networking direzionale per altri back-end.
Consenti uno strumento visibile senza accesso ampio all'interfaccia utente
Per un carico di lavoro che richiede una finestra visibile e un input degli Appunti, questo frammento di configurazione sostituisce ui. Consente la lettura delle finestre e degli appunti, ma non la scrittura negli Appunti o l'input sintetico di tastiera e puntatore:
{
"ui": {
"disable": false,
"clipboard": "read",
"injection": false
}
}
In un SDK V1 ContainerRequest, le proprietà equivalenti dell'interfaccia utente sono disable, clipboard e allowInputInjection. Concedi letture degli appunti solo quando il carico di lavoro le richiede. Controllare il supporto dell'interfaccia utente di runtime e testare le restrizioni necessarie su ciascun host di destinazione.
Riutilizzare una sandbox consapevole dello stato
Usare l'esecuzione che tiene conto dello stato quando i comandi devono condividere un ambiente. Effettuare il provisioning e avviarlo, eseguire i comandi, quindi arrestarlo e deprovisionarlo al termine. Disporre la pulizia dopo un fallimento e un annullamento, non solo dopo l'esito positivo.
Le chiamate sensibili allo stato usano un ProvisionRequest specifico per fase e un elemento separato ExecutionRequest per ogni comando, non la configurazione one-shot completa sopra. Il provisioning restituisce un oggetto opaco ContainerId; passarlo invariato alle fasi successive. Usare MxcLifecycle in .NET, le funzioni del ciclo di vita di TypeScript come ad esempio provisionContainer, o le funzioni v1::container di Rust come provision_container, con IsolationSession o WSLc, i back-end supportati dalle API del ciclo di vita V1. Vedere i concetti relativi al ciclo di vita, il ciclo di vita del contenitore MXC e la guida .NET, TypeScript o Rust SDK per i requisiti esatti.
Verificare cosa impone ogni back-end del ciclo di vita prima di sceglierla. IsolationSession separa l'utente e la sessione del carico di lavoro, ma non applica il filtraggio del file system MXC, dell'interfaccia utente o della rete e la relativa richiesta deve consentire esplicitamente tutto il traffico di rete. La rete WSLc è completamente isolata o completamente in bridge, senza regole per destinazione. Per informazioni dettagliate, vedere Scegliere un tipo di isolamento e impostazioni e selezione back-end.
Verificare gli esempi
Per ogni policy adattata, testare sia il comportamento previsto che il tentativo di uso improprio:
- Verificare che gli input necessari possano essere letti e che sia possibile scrivere gli output necessari.
- Verificare che le credenziali e i file non correlati rimangano inaccessibili.
- Verificare che le connessioni dirette, di rete locale, di loopback e in ingresso corrispondano ai criteri.
- Per l'accesso basato su proxy, verificare che una richiesta approvata abbia esito positivo e che un tentativo diretto di Internet abbia esito negativo.
- Verificare che gli Appunti, l'inserimento di input e le finestre visibili corrispondano alla policy dell'interfaccia utente.
- Verificare che i timeout e la pulizia funzionino dopo l'esito positivo, negativo e l'annullamento.
Usare Learning Mode per verificare gli accessi mancanti. Non concedere automaticamente ogni risorsa osservata da un'esecuzione rappresentativa.
Contenuti correlati
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
