Quelles sont les pratiques optimales et complètes à prendre en compte lors de l'exécution de docker en production?

Enfin, vous êtes tellement amoureux de Docker que vous souhaitez transférer vos systèmes de production stratégiques en ligne avec des données clients sensibles vers un Docker Swarm. Certains pourraient même l'avoir déjà fait. L’autre organisation ne peut se permettre une politique interdisant aux processus de production de s’exécuter en mode racine.

Que pourrait être une liste de contrôle des blocs de construction à prendre en compte pour un environnement de production Docker? On n'a pas besoin de tous, mais tous devraient être importants pour être évalués.

Clause de non-responsabilité: Je sais qu'il existe une politique SE visant à éviter les "listes interminables sans fin", mais je pense que cette liste de contrôle ne peut être très longue ... et sans fin.

Alors, quels sont ces blocs de bâtiments?

1. Si ce n’est pas déjà fait, envisagez d’exécuter un système hôte Linux avec des paramètres de sécurité avancés - noyau renforcé, SELinux, etc.
2. Pensez à utiliser une petite image de base Docker, telle que alpine, busybox ou même scratch, par exemple, commencez par une image de base vide.
3. Utiliser un paramètre USER autre que root
4. Évaluez soigneusement pour réduire davantage l'ensemble des capacités du noyau déjà réduites accordées au conteneur
5. Envisagez de n’avoir qu’un seul binaire exécutable par conteneur pour lancer votre processus, idéalement lié statiquement.
6. Ceux qui veulent casser votre système pour obtenir un accès à un shell peuvent se demander s'ils ont découvert que votre conteneur a tous les shells désactivés
7. Monter des volumes en lecture seule où seulement possible

Question: quoi d'autre?

L'hôte sur lequel les conteneurs s'exécutent

Exécutez le banc de sécurité de docker sur chaque nœud qui exécute des conteneurs de docker https://github.com/docker/docker-bench-security

Exécution de la commande suivante sur un noeud qui exécute des conteneurs Docker:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

renvoie une liste de chèques:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Citation du fichier README du référentiel:

Docker Bench for Security est un script qui vérifie des dizaines de pratiques recommandées concernant le déploiement de conteneurs Docker en production. Les tests sont tous automatisés et sont inspirés de CIS Docker Community Edition Benchmark v1.1.0 .

Certains des problèmes signalés par le banc de sécurité pourraient être résolus en lisant l'article officiel sur la sécurité des dockers et en le comparant aux puces définies dans la question, les éléments suivants sont également importants:

• protéger le socket docker daemon en implémentant ssl
• contenu de confiance en utilisant notaire et DOCKER_CONTENT_TRUSTvariable

Docker est encore en développement.

Comme avec tous les autres bogues de développement de logiciel, des fonctionnalités non sécurisées peuvent être ajoutées, des failles architecturales pouvant conduire à des failles de sécurité. Ne sous-estimez pas cela! Votre système est peut-être complètement sûr aujourd'hui, mais avec le correctif de la semaine prochaine, quelqu'un trouve un bogue, écrit un exploit et, tout à coup, votre système est complètement ouvert.

Sauf si vous devez, ne mettez pas à jour à la dernière version. Utilisez plutôt la dernière version bien testée.

Docker n'est pas une virtualisation

Si quelqu'un s'échappe d'un conteneur Docker, cet attaquant se trouve immédiatement sur la vraie machine. Il n'y a pas de deuxième porte comme la virtualisation qui empêcherait une violation.

Traitez un conteneur Docker comme n'importe quel autre programme. Exécutez avec les droits d'utilisateur les plus bas possibles, bloquez tout le trafic réseau non requis, virtualisez l'intégralité de l'hôte Docker si les performances le permettent.

Docker n'est pas une protection

Quel que soit le code utilisé dans les conteneurs Docker, Docker le fait sans poser de question. Tout attaquant peut simplement installer son logiciel dans le conteneur, et Docker l’exécutera comme tout autre code.

Outre les éléments que vous avez mentionnés dans la question, envisagez d'utiliser des mesures et des alertes pour être averti si une image Docker fait des choses étranges. Y a-t-il un pic soudain et continu du processeur? Le programme balaye-t-il soudainement les ports réseau? Y a-t-il un accès suspect au disque? Vous devriez recevoir une notification si cela se produit. Il existe de nombreux outils disponibles pour mesurer ces choses, vous devriez les utiliser.

Docker se représente

Une option supplémentaire consiste à utiliser Clair .

Clair est un projet open source pour l'analyse statique des vulnérabilités dans les conteneurs d'applications (incluant actuellement appc et docker).

À intervalles réguliers, Clair ingère des métadonnées de vulnérabilité provenant d’un ensemble de sources configuré et les stocke dans la base de données.

Les clients utilisent l'API Clair pour indexer leurs images de conteneur. Cela crée une liste des fonctionnalités présentes dans l'image et les stocke dans la base de données.

Les clients utilisent l'API Clair pour interroger la base de données sur les vulnérabilités d'une image particulière. la corrélation des vulnérabilités et des fonctionnalités est effectuée pour chaque demande, évitant ainsi de devoir numériser à nouveau les images.

Lorsque des mises à jour des métadonnées de vulnérabilité se produisent, une notification peut être envoyée pour avertir les systèmes qu'une modification a eu lieu.

Notre objectif est de permettre une vision plus transparente de la sécurité des infrastructures basées sur des conteneurs. Ainsi, le projet a été nommé Clair d'après le terme français qui se traduit par clair, brillant, transparent.

En plus des points dans ce fil; ce qui suit serait ma recommandation:

• Prenez le contrôle de Docker PID1 avec dumb-init
  • ref: PID1 et Zombie récoltant problème
• N'exécutez pas docker en production sans un système d'orchestration de conteneur
  • Faites votre choix parmi Kubernetes, Mesos, Swarm, etc.
• Utiliser gosu pour le contrôle de l'utilisateur dans une image de menu fixe
• Suivez le paradigme des applications à 12 facteurs. Si vous exécutez des applications avec état dans des conteneurs, changez-les.
  • Si vous avez vraiment besoin d'exécuter des applications avec état (mysql, zookeeper, elasticsearch) dans des conteneurs, utilisez des paradigmes d'orchestrateur tels que Kubernetes Statefulsets.
• Faites une gestion secrète / de configuration robuste avec des outils tels que hashicorp vault / consul
• Expédiez le même conteneur construit par les développeurs pour passer à travers un pipeline CI qui le soumet à des tests d'intégration et d'intégration minutieux.
• Créez des notifications autour des CVE et des patchs, déclenchez des builds sur patch-notify
• Si vous avez une journalisation étendue pour avoir un aperçu du conteneur en cours d'exécution, vous ne souhaitez pas donner aux développeurs un accès SSH à l'hôte ou aux conteneurs
  • recommandation: fluentd
• Avoir les métriques conteneur et hôte
  • recommandation: prometheus + node-exportateur

Si vous remplissez votre point d’entrée dans le menu fixe avec des sedcommandes, suivez cette pratique:

• Utilisez un outil tel que confd pour gérer les fichiers de configuration de vos images de menu fixe et les mettre à jour.

Confd lira les données de nombreux magasins de clés-valeurs pris en charge et rendra les modèles de configuration de manière dynamique.

On pourrait utiliser A2D pour créer une application dans une image de menu fixe tout en tenant compte de certains éléments, par exemple les autorisations non root, les autorisations, l'emplacement de l'application:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

résultats:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]