Ho un'applicazione che mi piacerebbe dare il privilegio di avviare attività di breve durata e programmarle come contenitori docker. Stavo pensando di farlo semplicemente tramite docker run.C'è un modo per limitare lo scheduler del contenitore non attendibile?
Come voglio rendere la superficie di attacco il più piccola possibile, considero l'applicazione non attendibile. In quanto tale, può potenzialmente eseguire comandi arbitrari docker run (se il codebase conteneva bug o il contenitore era compromesso, l'input era erroneamente scappato da qualche parte ecc.) Contro un endpoint API docker predefinito.
Per questo mi piacerebbe che limitare l'applicazione (in modo efficace uno scheduler) per certi versi:
- evitare
--privilegeduso - far rispettare
--read-onlybandiera - far rispettare la memoria & limiti della CPU
Ho guardato un paio di Opzioni:
- SELinux
- le politiche di SELinux dovrebbero essere impostato sul livello di host e poi propagato all'interno dei contenitori tramite
--selinux-enabledbandiera sul livellodaemon. Tuttavia, lo scheduler può comunque prevalere tramiterun --privileged.
- le politiche di SELinux dovrebbero essere impostato sul livello di host e poi propagato all'interno dei contenitori tramite
- profili seccomp
- questi vengono applicati solo in un momento di lancio del contenitore (bandiere seccomp sono disponibili per
docker run)
- questi vengono applicati solo in un momento di lancio del contenitore (bandiere seccomp sono disponibili per
- AppArmor
- questo può (ancora) essere sovrascritto a livello di pianificazione tramite
--privileged
- questo può (ancora) essere sovrascritto a livello di pianificazione tramite
- finestra mobile demone
--exec-optsbandiera- una sola opzione è effettivamente disponibile per questo flag (
native.cgroupdriver)
- una sola opzione è effettivamente disponibile per questo flag (
Sembra che Docker è stato progettato per fidarsi pianificatori contenitore per impostazione predefinita. Qualcuno sa se questa è una decisione di progettazione?
C'è qualche altra possibile soluzione disponibile con l'ultima versione di Docker che ho perso?
Ho anche guardato kubernetes e la sua Limit Ranges & Resource Quotas che può essere applicato ad namespace K8S, che sembrava interessante, assumendo c'è un modo per applicare determinate schedulatori di utilizzare solo alcuni namespace. Ciò tuttavia aumenterebbe lo scopo di questo problema nell'operare il cluster K8S.
Direi che "non attendibile" e "in grado di eseguire comandi arbitrari" sono intrinsecamente contraddittori. Stai permettendo loro di eseguire effettivamente qualsiasi comando, e si aspettano solo che sia un comando di 'docker run'? O stai permettendo loro di specificare una stringa di argomenti su 'docker run'? Se il secondo, perché non basta modificare il prefisso 'docker run' per aggiungere i flag' --privileged = false' e '--read-only'? Un comando che specifica un secondo argomento '--privileged' dovrebbe fallire –
Nei documenti viene esplicitamente indicato che solo gli utenti fidati dovrebbero essere autorizzati a controllare il demone. Quindi è improbabile che tu abbia perso molto (tranne forse per gli spazi dei nomi degli utenti che potrebbero essere interessanti). Ti suggerirei di creare uno script di shell di avvio con sudo perms che esegua il contenitore con le restrizioni desiderate, non dando il pieno controllo dell'applicazione "non affidabile". argomenti di docker run'. –
@ F.StephenQ Ho spiegato sopra che "in grado di eseguire comandi arbitrari" non è qualcosa che mi aspetto di accadere "in base alla progettazione", ma piuttosto per errore (ad esempio app compromessa o fuga scorretta). –