Durcissement / réduction de la surface d'attaque d'un conteneur Docker
Je voudrais mettre en place une instance Docker renforcée, principalement pour exécuter des micro-services tels que des applications golang compilées statiquement. Ce que je recherche, c'est de protéger le système d'exploitation hôte contre un conteneur escroc et les conteneurs les uns des autres. J'ai essayé de résumer la situation avec le scénario suivant.
Scénario:
Nous avons un serveur exécutant un OS minimal tel qu'Alpine Linux (OS basé sur busybox), avec SElinux et grsec installés, activés et correctement configurés.
Sur ce serveur s'exécute une instance Docker avec 2 conteneurs en cours d'exécution, A et B et un volume V.
Le conteneur A contient une application compilée statiquement sans dépendances, mise en réseau avec l'Internet public (application Web ou API publique). Cette application contient un énorme bogue, quelque chose comme l'exécution arbitraire de code/téléchargement/shell inverse complet, le pire que vous puissiez imaginer. Ce conteneur est également mis en réseau avec le volume V en tant que destination de téléchargement, base de données, etc.
Le système d'exploitation hôte contient un indicateur qui ne peut être lu qu'à la racine (appliqué par SElinux).
Le conteneur B contient également un drapeau et une application mais aucune connexion au monde extérieur.
Attaquant:
- L'homme, connaît l'énorme bogue de l'application.
- Il veut récupérer les drapeaux. Les données en V ne sont pas importantes.
- Ce n'est pas une agence d'espionnage mais un spécialiste de la sécurité de haut niveau.
- Peut avoir accès à des jours zéro dont nous ne sommes pas au courant.
Hypothèses:
- Le noyau Linux a des bugs mais grsec suffit pour couvrir cela. Ne peut être un vecteur d'attaque que si grsec est désactivé
- Grsec et SElinux n'ont pas de bogues et ne sont pas mal configurés.
- Une racine utilisateur dans le conteneur est racine en dehors du conteneur (peut-être qu'un jour ce ne sera plus vrai ...)
- Docker est un Docker du monde réel. Aucun bogue connu mais a été affecté par des bogues dans le passé et cela pourrait se reproduire.
- Un système de journalisation pour une enquête future est déjà correctement configuré.
Objectif:
- Protégez les drapeaux. Probablement pas possible car nous supposons que Docker a des bugs.
- Réduire la surface d'attaque.
- Rendre la vie de l'attaquant difficile.
- Définissez une alarme qui se déclenche si l'attaquant tente d'obtenir les drapeaux. De préférence bien avant qu'il ne réussisse à les obtenir.
Questions:
- Dans quelle mesure mes hypothèses sont-elles réalistes?
- Comment atteindriez-vous ces objectifs?
- Comment les marchandises sont mes suggestions suivantes?
- Des conseils de sécurité généraux pour Docker?
Mes suggestions:
- Configurez SElinux tel qu'aucun utilisateur ne peut écrire sur A et aucun utilisateur ne peut exécuter de fichiers sur V.
Utilisez une image Docker extrêmement minimale, sans espace utilisateur. Quelque chose comme:
FROM scratch COPY app / ENTRYPOINT ["/app"]Désescalader le privilège avant d'exécuter l'application. (Je ne sais pas quelle est la bonne façon de le faire ...)
- Un faux userbox land? Quelque chose qui déclencherait une alarme si nous essayions d'appeler
/bin/sh,/bin/lsou quelque chose comme ça.
Je vous renvoie aux CIS Benchmarks pour des directives de durcissement. La référence CIS actuelle pour Docker peut être trouvée ici . Il s'agit d'une norme industrielle acceptée pour le durcissement de base. Ils offrent également des directives pour Linux et al, les serveurs Web, les bases de données, etc.