Bonnes pratiques relatives à la sécurité des ECS tâches et des conteneurs Amazon

Vous devez considérer l'image du 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 procéder comme suit pour atténuer le risque que cela se produise.

Nous vous recommandons d'effectuer les opérations suivantes lorsque vous configurez vos tâches et conteneurs.

Créez un minimum d'images ou utilisez des images sans distribution

Commencez par retirer tous les fichiers binaires superflus de l'image de conteneur. Si vous utilisez une image inconnue provenant d'Amazon ECR Public Gallery, inspectez-la pour faire référence au contenu de chacune des couches du conteneur. Pour ce faire, vous pouvez utiliser une application telle que Dive.

Vous pouvez également utiliser des images sans distribution qui incluent uniquement votre application et ses dépendances d'exécution. Elles ne contiennent pas de gestionnaires de packages ou de shells. Les images sans distribution améliorent le « rapport signal/bruit émis par les scanners et réduisent la charge liée à l'établissement de la provenance à ce dont vous avez besoin ». Pour plus d'informations, consultez la GitHub documentation sur distroless.

Docker dispose d'un mécanisme permettant de créer des images à partir d'une image minimale réservée connue sous le nom de scratch. Pour plus d'informations, veuillez consulter Création d'une image parent simple à l'aide de scratch dans la documentation Docker (langue française non garantie). Avec des langages tels que Go, vous pouvez créer un fichier binaire lié statique et le référencer dans votre Dockerfile. L'exemple suivant montre comment procéder.

############################
# 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 suivant montre également un exemple de construction à plusieurs étapes. Ces types de constructions sont intéressants du point de vue de la sécurité, car vous pouvez les utiliser pour réduire la taille de l'image finale envoyée à votre registre de conteneurs. Les images de conteneur dépourvues d'outils de construction et d'autres fichiers binaires superflus améliorent votre niveau de sécurité en réduisant la surface d'attaque de l'image. Pour plus d'informations sur les constructions à plusieurs étapes, veuillez consulter Création de constructions à plusieurs étapes (langue française non garantie).

Analysez vos images pour détecter les vulnérabilités

À l'instar de leurs homologues machines virtuelles, les images de conteneur peuvent contenir des fichiers binaires et des bibliothèques d'applications présentant des vulnérabilités ou développer des vulnérabilités au fil du temps. Le meilleur moyen de se prémunir contre les attaques est d'analyser régulièrement vos images à l'aide d'un analyseur d'images.

Les images stockées sur Amazon ECR peuvent être numérisées en mode push ou à la demande (une fois toutes les 24 heures). Amazon ECR Basic Scanning utilise Clair, une solution de numérisation d'images open source. Le scan ECR amélioré d'Amazon utilise Amazon Inspector. Une fois qu'une image est numérisée, les résultats sont enregistrés dans le flux ECR d'événements Amazon sur Amazon EventBridge. Vous pouvez également consulter les résultats d'un scan depuis la ECR console Amazon ou en appelant le DescribeImageScanFindingsAPI. Les images présentant une vulnérabilité HIGH ou CRITICAL doivent être supprimées ou reconstruites. 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.0 ou ultérieure peut analyser des images locales. Les analyses sont fournies par Snyk, un service de sécurité des applications. Lorsque des vulnérabilités sont découvertes, Snyk identifie les couches et les dépendances contenant la vulnérabilité dans le Dockerfile. Il recommande également des alternatives sûres, telles que l'utilisation d'une image de base plus fine présentant moins de vulnérabilités ou la mise à niveau d'un package particulier vers une version plus récente. En utilisant l'analyse Docker, les développeurs peuvent résoudre les problèmes de sécurité potentiels avant de transférer leurs images dans le registre.

• Automatisez la conformité des images à l'aide d'Amazon ECR et AWS Security Hub explique comment intégrer les informations relatives aux vulnérabilités provenant d'Amazon AWS Security Hub et automatiser la correction ECR en bloquant l'accès aux images vulnérables.

Supprimez les autorisations spéciales associées à vos images

Les indicateurs des droits d'accès setuid et setgid autorisent l'exécution d'un exécutable avec les autorisations du propriétaire ou du groupe de l'exécutable. Supprimez de votre image tous les fichiers binaires dotés de ces droits d'accès, car ils peuvent être utilisés pour escalader les privilèges. Envisagez de supprimer tous les shells et utilitaires comme nc ou curl susceptibles d'être utilisés à des fins malveillantes. Vous pouvez trouver les fichiers avec les droits d'accès setuid et setgid à 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éez 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 validées pour les différentes piles d'applications de votre organisation. Ce faisant, les développeurs peuvent renoncer à apprendre à composer des 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 automatiquement compiler la ressource, puis la stocker dans un référentiel d'artefacts. Enfin, copiez l'artefact dans l'image appropriée avant de le transférer vers un registre Docker tel qu'Amazon. ECR Vous devez créer au minimum un ensemble d'images de base à partir desquelles les développeurs peuvent créer leurs propres Dockerfiles. Vous devez éviter d'extraire des images depuis Docker Hub. Vous ne savez pas toujours ce que contient l'image : environ un cinquième des 1 000 images principales présente des vulnérabilités. Une liste de ces images et de leurs vulnérabilités est disponible sur https://vulnerablecontainers.org/.

Analysez les packages d'applications et les bibliothèques pour détecter les vulnérabilités

L'utilisation de bibliothèques open source est désormais courante. Comme 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 détecter des vulnérabilités et des problèmes de licence potentiels 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 plus d’informations, consultez les rubriques suivantes :

• La page outils de sécurité des applications open source inclut une liste d'outils permettant de détecter les vulnérabilités des applications.

Effectuez une analyse de code statique

Vous devez effectuer une analyse de code statique avant de créer une image de conteneur. Celle-ci est effectuée sur votre code source et est utilisée pour identifier les erreurs de codage et le code susceptible d'être utilisé par un acteur malveillant, comme les injections d'erreurs. Vous pouvez utiliser Amazon Inspector. Pour plus d'informations, consultez la section Numérisation d'images de ECR conteneurs Amazon avec Amazon Inspector dans le guide de l'utilisateur d'Amazon Inspector.

Exécutez les conteneurs en tant qu'utilisateur non root

Vous devez exécuter les conteneurs en tant qu'utilisateur non root. Par défaut, les conteneurs s'exécutent en tant qu'utilisateur root, sauf si la directive USER est incluse dans votre Dockerfile. Les fonctionnalités Linux par défaut attribuées par Docker limitent les actions qui peuvent être exécutées en tant que root, mais seulement de manière marginale. Par exemple, un conteneur s'exécutant en tant que root n'est toujours pas autorisé à accéder aux appareils.

Dans le cadre de votre pipeline CI/CD, vous devez vérifier les Dockerfiles pour rechercher la directive USER et faire échouer la compilation si elle est manquante. Pour plus d’informations, consultez les rubriques suivantes :

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

• Hadolint est un autre outil permettant de créer des images Docker conformes aux bonnes pratiques.

Utilisez 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 un système de fichiers racine RO (en lecture seule), cela 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 disponible en écriture à 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 entraîner des problèmes avec certains packages du système d'exploitation qui devraient pouvoir écrire dans le système de fichiers. Si vous prévoyez d'utiliser des systèmes de fichiers racine en lecture seule, effectuez des tests approfondis au préalable.

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

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

Note

Amazon ECS on AWS Fargate Tasks vous demande de spécifier CPU des limites de mémoire car Amazon utilise ces valeurs à des fins de facturation. Une tâche monopolisant toutes les ressources du 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 un minimum de 4 Mo à chaque conteneur. De même, si aucune CPU limite n'est définie pour la tâche, l'agent de ECS conteneur Amazon lui en attribue un minimum de 2CPUs.

Utilisez des balises immuables avec Amazon ECR

Avec AmazonECR, vous pouvez et devez utiliser des images configurées avec des balises immuables. Cela empêche de transférer une version modifiée ou mise à jour d'une image vers votre référentiel d'images avec une balise identique. Cela permet d'éviter qu'un attaquant ne diffuse une version compromise d'une image sur votre image portant la même balise. En utilisant des balises immuables, vous vous forcez efficacement à envoyer une nouvelle image avec une balise différente pour chaque modification.

Évitez de gérer les conteneurs en tant que privilégiés (AmazonEC2)

Vous devez éviter d'exécuter des conteneurs dotés de privilèges. En effet, les conteneurs s'exécutant comme privileged sont 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 attribuées à root sur l'hôte. Son utilisation doit être strictement restreinte ou interdite. Nous vous conseillons de définir la variable d'environnement de l'agent de ECS conteneur Amazon sur ECS_DISABLE_PRIVILEGED true pour empêcher les conteneurs de s'exécuter comme privileged sur des hôtes particuliers si cela privileged n'est pas nécessaire. Vous pouvez également AWS Lambda analyser vos définitions de tâches afin d'utiliser le privileged paramètre.

Note

L'exécution d'un conteneur privileged n'est pas prise en charge ECS sur Amazon le AWS Fargate.

Supprimez les 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 sur chaque fonctionnalité, veuillez consulter Présentation des fonctionnalités de Linux (langue française non garantie).

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 fonctionnalités de noyau Docker répertoriées ci-dessus, pensez à les supprimer du conteneur. Pour plus d'informations sur les fonctionnalités de chaque noyau Docker, consultez KernelCapabilities. Vous pouvez déterminer les fonctionnalités utilisées en procédant ainsi :

• Installez le package du système d'exploitation libcap-ng et exécutez l'utilitaire pscap pour répertorier les fonctionnalités utilisées par chaque processus.

• Vous pouvez également utiliser capsh pour déchiffrer les fonctionnalités utilisées par un processus.

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

Vous devez utiliser une clé gérée par le client (CMK) pour chiffrer les images transmises à AmazonECR. Les images transmises à Amazon ECR sont automatiquement chiffrées au repos à l'aide d'une clé gérée AWS Key Management Service (AWS KMS). Si vous préférez utiliser votre propre clé, Amazon prend ECR désormais en charge le AWS KMS chiffrement avec des clés gérées par le client (CMK). Avant d'activer le chiffrement côté serveur avec unCMK, consultez les considérations répertoriées dans la documentation sur le chiffrement au repos.