Sécurité des tâches et des conteneurs

Vous devriez considérer l'image de conteneur comme la première ligne de défense contre une attaque. Une image peu sécurisée et mal construite peut permettre à un attaquant d'échapper aux limites du conteneur et d'accéder à l'hôte. Vous devez faire ce qui suit pour atténuer le risque que cela se produise.

Recommendations

Nous vous recommandons d'effectuer les opérations suivantes lors de la configuration de vos tâches et conteneurs.

Créer un minimum ou utiliser des images sans distroless

Commencez par supprimer tous les fichiers binaires superflus de l'image du conteneur. Si vous utilisez une image inconnue de Docker Hub, inspectez l'image pour faire référence au contenu de chacune des couches du conteneur. Vous pouvez utiliser une application telle quePlongéePour

Vous pouvez également utiliserdistrolessqui incluent uniquement votre application et ses dépendances d'exécution. Ils ne contiennent pas de gestionnaires de paquets ou d'interpréteurs de commandes. Les images sans distroless améliorent le « signal au bruit des scanners et réduisent le fardeau d'établir la provenance à ce dont vous avez besoin ». Pour plus d'informations, consultez la Documentation GitHub surdistroless.

Docker dispose d'un mécanisme permettant de créer des images à partir d'une image minimale réservée appeléegratter. Informations Formore, consultezCréation d'une image parent simple à l'aide degratterdans la documentation Docker. Avec des langages comme Go, vous pouvez créer un binaire lié statique et le référencer dans votre Dockerfile. L'exemple suivant montre comment effectuer cette opération.

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder
# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache git
WORKDIR $GOPATH/src/mypackage/myapp/
COPY . .
# Fetch dependencies.
# Using go get.
RUN go get -d -v
# Build the binary.
RUN go build -o /go/bin/hello
############################
# STEP 2 build a small image
############################
FROM scratch
# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello
# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]
This creates a container image that consists of your application and nothing else, making it extremely secure.

L'exemple précédent est également un exemple de construction en plusieurs étapes. Ces types de builds sont attrayants du point de vue de la sécurité, car vous pouvez les utiliser pour minimiser la taille de l'image finale envoyée dans votre registre de conteneurs. Les images de conteneur dépourvues d'outils de construction et d'autres fichiers binaires externes améliorent votre posture de sécurité en réduisant la surface d'attaque de l'image. Pour plus d'informations sur les builds multi-étapes, consultezcréation de builds en plusieurs étapes.

Analyser vos images à la recherche de vulnérabilités

À l'instar de leurs homologues de machines virtuelles, les images de conteneur peuvent contenir des binaires et des bibliothèques d'applications présentant des vulnérabilités ou développer des vulnérabilités au fil du temps. La meilleure façon de vous protéger contre les exploits est de numériser régulièrement vos images à l'aide d'un scanner d'images. Les images stockées dans Amazon ECR peuvent être numérisées en mode push ou à la demande (une fois toutes les 24 heures). Amazon ECR utilise actuellementClair, une solution open source de numérisation d'images. Une fois une image numérisée, les résultats sont enregistrés dans le flux d'événements Amazon ECR dans Amazon EventBridge. Vous pouvez également voir les résultats d'une analyse à partir de la console Amazon ECR ou en appelant leDescribeImageScanFactsAPI. Images avec unHIGHouCRITICALdoit être supprimée ou reconstruite. Si une image déployée développe une vulnérabilité, elle doit être remplacée dès que possible.

Docker Desktop Edge version 2.3.6.0ou version ultérieure peutscanimages locales. Les scans sont alimentés parSnyk, un service de sécurité des applications. Lorsque des vulnérabilités sont découvertes, Snyk identifie les couches et les dépendances avec la vulnérabilité dans Dockerfile. Il recommande également des alternatives sûres comme l'utilisation d'une image de base plus mince avec moins de vulnérabilités ou la mise à niveau d'un paquet particulier vers une version plus récente. En utilisant Docker scan, les développeurs peuvent résoudre des problèmes de sécurité potentiels avant de transférer leurs images dans le registre.

• Automatisation de la conformité des images à l'aide d'Amazon ECR etAWS Security Hubexplique comment afficher les informations de vulnérabilité d'Amazon ECR dansAWS Security Hubet automatisez la correction en bloquant l'accès aux images vulnérables.

Supprimer les autorisations spéciales de vos images

Les drapeaux des droits d'accèssetuidandsetgidpermettent d'exécuter un exécutable avec les autorisations du propriétaire ou du groupe de l'exécutable. Supprimez tous les fichiers binaires dotés de ces droits d'accès de votre image car ces fichiers binaires peuvent être utilisés pour augmenter les privilèges. Envisagez de supprimer tous les shells et utilitaires commencandcurlqui peuvent être utilisés à des fins malveillantes. Vous pouvez trouver les fichiers avecsetuidandsetgidÀ l'aide de la commande suivante.

find / -perm /6000 -type f -exec ls -ld {} \;

Pour supprimer ces autorisations spéciales de ces fichiers, ajoutez la directive suivante à votre image de conteneur.

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Créer un ensemble d'images sélectionnées

Plutôt que de permettre aux développeurs de créer leurs propres images, créez un ensemble d'images vérifiées pour les différentes piles d'applications de votre organisation. Ce faisant, les développeurs peuvent renoncer à apprendre à composer Dockerfiles et se concentrer sur l'écriture de code. Au fur et à mesure que les modifications sont fusionnées dans votre base de code, un pipeline CI/CD peut compiler automatiquement l'actif, puis le stocker dans un référentiel d'artefacts. Enfin, copiez l'artefact dans l'image appropriée avant de le pousser dans un registre Docker tel qu'Amazon ECR. Au moins, vous devriez créer un ensemble d'images de base que les développeurs de chapeau peuvent créer leurs propres Dockerfiles à partir de. Évitez de tirer des images depuis Docker Hub. Vous ne savez pas toujours ce qu'il y a dans l'image et environ un cinquième des 1000 premières images présentent des vulnérabilités. Vous trouverez une liste de ces images et de leurs vulnérabilités à l'adressehttps://vulnerablecontainers.org/.

Analyser les paquets d'applications et les bibliothèques pour détecter les vulnérabilités

L'utilisation de bibliothèques open source est maintenant courante. Comme pour les systèmes d'exploitation et les packages de systèmes d'exploitation, ces bibliothèques peuvent présenter des vulnérabilités. Dans le cadre du cycle de développement, ces bibliothèques doivent être analysées et mises à jour lorsque des vulnérabilités critiques sont détectées.

Docker Desktop effectue des analyses locales à l'aide de Snyk. Il peut également être utilisé pour trouver des vulnérabilités et des problèmes potentiels de licence dans les bibliothèques open source. Il peut être intégré directement dans les flux de travail des développeurs, ce qui vous permet d'atténuer les risques posés par les bibliothèques open source. Pour de plus amples informations, consultez les rubriques suivantes :

• Outils de sécurité des applications Open Sourceinclut une liste d'outils permettant de détecter les vulnérabilités dans les applications.

• Feuille de triche de numérisation Docker

Effectuer une analyse de code statique

Vous devez effectuer une analyse de code statique avant de créer une image de conteneur. Il est exécuté avec votre code source et est utilisé pour identifier les erreurs de codage et le code qui pourraient être exploités par un acteur malveillant, comme les injections de défauts. SonarQubeest une option populaire pour les tests de sécurité des applications statiques (SAST), avec la prise en charge d'une variété de langages de programmation différents.

Exécuter des conteneurs en tant qu'utilisateur non root

Vous devez exécuter des conteneurs en tant qu'utilisateur non-racine. Par défaut, les conteneurs s'exécutent en tant querootà moins que l'utilisateurUSERest incluse dans votre Dockerfile. Les fonctionnalités Linux par défaut attribuées par Docker restreignent les actions qui peuvent être exécutées en tant queroot, mais seulement marginalement. Par exemple, un conteneur s'exécutant en tant querootn'est toujours pas autorisé à accéder aux appareils.

Dans le cadre de votre pipeline CI/CD, vous devriez pelucher Dockerfiles pour rechercher leUSERet échoue la construction si elle est manquante. Pour de plus amples informations, consultez les rubriques suivantes :

• Dockerfileest un outil open source de RedHat qui peut être utilisé pour vérifier si le fichier est conforme aux meilleures pratiques.

• Hadolintest un autre outil permettant de créer des images Docker conformes aux meilleures pratiques.

Utiliser un système de fichiers racine en lecture seule

Vous devez utiliser un système de fichiers racine en lecture seule. Le système de fichiers racine d'un conteneur est accessible en écriture par défaut. Lorsque vous configurez un conteneur avec unRO(lecture seule), il vous oblige à définir explicitement où les données peuvent être conservées. Cela réduit votre surface d'attaque car le système de fichiers du conteneur ne peut pas être écrit à moins que des autorisations ne soient spécifiquement accordées.

Note

Le fait d'avoir un système de fichiers racine en lecture seule peut provoquer des problèmes avec certains packages du système d'exploitation qui s'attendent à pouvoir écrire sur le système de fichiers. Si vous envisagez d'utiliser des systèmes de fichiers racine en lecture seule, testez soigneusement au préalable.

Configurer les tâches avec des limites de CPU et de mémoire (Amazon EC2)

Vous devez configurer les tâches avec des limites de CPU et de mémoire pour minimiser les risques suivants. Les limites de ressources d'une tâche définissent une limite supérieure pour la quantité de CPU et de mémoire qui peut être réservée par tous les conteneurs d'une tâche. Si aucune limite n'est définie, les tâches ont accès au processeur et à la mémoire de l'hôte. Cela peut provoquer des problèmes dans lesquels les tâches déployées sur un hôte partagé peuvent affamer d'autres tâches de ressources système.

Note

Amazon ECS surAWS Fargatenécessitent que vous spécifiez des limites de CPU et de mémoire car il utilise ces valeurs à des fins de facturation. Une tâche qui bloque toutes les ressources système n'est pas un problème pour Amazon ECS Fargate, car chaque tâche est exécutée sur sa propre instance dédiée. Si vous ne spécifiez pas de limite de mémoire, Amazon ECS alloue au moins 4 Mo à chaque conteneur. De même, si aucune limite de CPU n'est définie pour la tâche, l'agent de conteneur Amazon ECS lui attribue un minimum de 2 CPU.

Utiliser des balises immuables avec Amazon ECR

Avec Amazon ECR, vous pouvez et devez utiliser configurer des images avec des balises immuables. Cela empêche d'envoyer une version modifiée ou mise à jour d'une image dans votre référentiel d'images avec une balise identique. Cela protège contre un attaquant qui pousse une version compromise d'une image sur votre image avec la même balise. En utilisant des balises immuables, vous vous forcez effectivement à pousser une nouvelle image avec une balise différente pour chaque changement.

Évitez d'utiliser des conteneurs comme privilégiés (Amazon EC2)

Vous devez éviter d'exécuter des conteneurs comme privilégiés. En arrière-plan, les conteneurs s'exécutent en tant queprivilegedsont exécutés avec des privilèges étendus sur l'hôte. Cela signifie que le conteneur hérite de toutes les fonctionnalités Linux assignées àrootsur l'hôte. Son utilisation devrait être strictement restreinte ou interdite. Nous vous recommandons de définir la variable d'environnement Amazon ECS Container AgentECS_DISABLE_PRIVILEGEDsurtruepour empêcher les conteneurs de s'exécuter en tant queprivilegedsur des hôtes particuliers siprivilegedn'est pas nécessaire. Vous pouvez également utiliserAWS Lambdapour analyser vos définitions de tâches en vue de l'utilisation de l'outilprivileged  Paramètre .

Note

Exécuter un conteneur en tant queprivilegedn'est pas pris en charge sur Amazon ECS surAWS Fargate.

Suppression des fonctionnalités Linux inutiles du conteneur

Voici une liste des fonctionnalités Linux par défaut attribuées aux conteneurs Docker. Pour plus d'informations concernant chaque fonctionnalité, consultezPrésentation des capacités Linux.

CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL,
CAP_SETGID, CAP_SETUID, CAP_SETPCAP, CAP_NET_BIND_SERVICE, 
CAP_NET_RAW, CAP_SYS_CHROOT, CAP_MKNOD, CAP_AUDIT_WRITE, 
CAP_SETFCAP

Si un conteneur ne nécessite pas toutes les capacités kernales Docker répertoriées ci-dessus, envisagez de les retirer du conteneur. Pour plus d'informations sur chaque capacité Kernal Docker, consultezCapacités du noyau. Vous pouvez déterminer quelles fonctionnalités sont utilisées en procédant comme suit :

• Installez le package OSlibcap-nget exécutez lepscappour répertorier les fonctionnalités que chaque processus utilise.

• Vous pouvez également utilisercapshpour déchiffrer les capacités qu'un processus utilise.

• Reportez-vous àCapacités de Linux 101Pour plus d'informations, consultez.

Utiliser une clé gérée par le client (CMK) pour chiffrer les images transmises à Amazon ECR

Vous devez utiliser une clé gérée par le client (CMK) pour encruster les images qui sont transmises à Amazon ECR. Les images qui sont transmises à Amazon ECR sont automatiquement cryptées au repos avec unAWS Key Management Service(AWS KMS). Si vous préférez utiliser votre propre clé, Amazon ECR prend désormais en chargeAWS KMSchiffrement avec les clés gérées par le client (CMK). Avant d'activer le chiffrement côté serveur avec un CMK, consultez les considérations répertoriées dans la documentation surChiffrement au repos.