Protection de l'infrastructure (hôtes) - Amazon EKS
RecommandationsSolutions de rechangeOutils et ressources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Protection de l'infrastructure (hôtes)

Dans la mesure où il est important de sécuriser les images de vos conteneurs, il est tout aussi important de protéger l'infrastructure qui les gère. Cette section explore différentes manières d'atténuer les risques liés aux attaques lancées directement contre l'hôte. Ces directives doivent être utilisées conjointement avec celles décrites dans la section Runtime Security.

Recommandations

Utiliser un système d'exploitation optimisé pour exécuter des conteneurs

Envisagez d'utiliser Flatcar Linux, Project Atomic, RancherOS et Bottlerocket, un système d'exploitation spécial d'AWS conçu pour exécuter des conteneurs Linux. Cela inclut une surface d'attaque réduite, une image disque vérifiée au démarrage et des limites d'autorisation imposées à l'aide de SELinux.

Vous pouvez également utiliser l'AMI optimisée pour EKS pour vos nœuds de travail Kubernetes. L'AMI optimisée pour EKS est publiée régulièrement et contient un ensemble minimal de packages de système d'exploitation et de fichiers binaires nécessaires pour exécuter vos charges de travail conteneurisées.

Reportez-vous à la spécification de construction RHEL de l'AMI Amazon EKS pour un exemple de script de configuration qui peut être utilisé pour créer une AMI Amazon EKS personnalisée exécutée sur Red Hat Enterprise Linux à l'aide de Hashicorp Packer. Ce script peut être davantage exploité pour créer un EKS personnalisé conforme aux STIG. AMIs

Maintenez le système d'exploitation de votre nœud de travail à jour

Que vous utilisiez un système d'exploitation hôte optimisé pour les conteneurs tel que Bottlerocket ou un système Amazon Machine Image plus grand, mais néanmoins minimaliste, comme l'EKS optimisé AMIs, il est recommandé de maintenir ces images de système d'exploitation hôte à jour avec les derniers correctifs de sécurité.

Pour optimiser l'EKS AMIs, consultez régulièrement le CHANGELOG et/ou le canal des notes de version et automatisez le déploiement des images de nœuds de travail mises à jour dans votre cluster.

Traitez votre infrastructure comme immuable et automatisez le remplacement de vos nœuds de travail

Plutôt que d'effectuer des mises à niveau sur place, remplacez vos employés lorsqu'un nouveau correctif ou une nouvelle mise à jour est disponible. Cela peut être abordé de plusieurs manières. Vous pouvez soit ajouter des instances à un groupe de mise à l'échelle automatique existant à l'aide de la dernière AMI, en bouclant et en vidant les nœuds de manière séquentielle jusqu'à ce que tous les nœuds du groupe soient remplacés par la dernière AMI. Vous pouvez également ajouter des instances à un nouveau groupe de nœuds tout en bouclant et en vidant séquentiellement les nœuds de l'ancien groupe de nœuds jusqu'à ce que tous les nœuds aient été remplacés. Les groupes de nœuds gérés par EKS utilisent la première approche et affichent un message dans la console pour mettre à niveau vos travailleurs lorsqu'une nouvelle AMI sera disponible. eksctldispose également d'un mécanisme permettant de créer des groupes de nœuds avec l'AMI la plus récente et de boucler et de vidanger les pods des groupes de nœuds avant la fermeture des instances. Si vous décidez d'utiliser une autre méthode pour remplacer vos nœuds de travail, il est vivement recommandé d'automatiser le processus afin de minimiser la supervision humaine, car vous devrez probablement remplacer les travailleurs régulièrement au fur et à mesure que de nouveaux nœuds seront updates/patches publiés et lorsque le plan de contrôle sera mis à niveau.

Avec EKS Fargate, AWS met automatiquement à jour l'infrastructure sous-jacente au fur et à mesure que des mises à jour sont disponibles. Cela peut souvent se faire sans problème, mais il peut arriver qu'une mise à jour entraîne le report de votre pod. Nous vous recommandons donc de créer des déploiements avec plusieurs répliques lorsque vous exécutez votre application en tant que pod Fargate.

Exécutez régulièrement kube-bench pour vérifier la conformité aux benchmarks CIS pour Kubernetes

kube-bench est un projet open source d'Aqua qui évalue votre cluster par rapport aux benchmarks CIS pour Kubernetes. Le benchmark décrit les meilleures pratiques pour sécuriser les clusters Kubernetes non gérés. Le CIS Kubernetes Benchmark englobe le plan de contrôle et le plan de données. Amazon EKS fournissant un plan de contrôle entièrement géré, toutes les recommandations du CIS Kubernetes Benchmark ne sont pas applicables. Pour s'assurer que cette portée reflète la manière dont Amazon EKS est implémenté, AWS a créé le CIS Amazon EKS Benchmark. Le benchmark EKS hérite de CIS Kubernetes Benchmark avec des contributions supplémentaires de la communauté avec des considérations de configuration spécifiques pour les clusters EKS.

Lorsque vous exécutez kube-bench sur un cluster EKS, suivez les instructions d'Aqua Security. Pour plus d'informations, voir Présentation du benchmark Amazon EKS du CIS.

Minimiser l'accès aux nœuds de travail

Au lieu d'activer l'accès SSH, utilisez le gestionnaire de session SSM lorsque vous devez vous connecter à distance à un hôte. Contrairement aux clés SSH qui peuvent être perdues, copiées ou partagées, le gestionnaire de session vous permet de contrôler l'accès aux EC2 instances à l'aide d'IAM. En outre, il fournit une piste d'audit et un journal des commandes exécutées sur l'instance.

Depuis le 19 août 2020, les groupes de nœuds gérés prennent en charge les modèles personnalisés AMIs et de EC2 lancement. Cela vous permet d'intégrer l'agent SSM dans l'AMI ou de l'installer pendant le démarrage du nœud de travail. Si vous préférez ne pas modifier l'AMI optimisée ou le modèle de lancement de l'ASG, vous pouvez installer l'agent SSM avec un DaemonSet as dans cet exemple.

Politique IAM minimale pour l'accès SSH basé sur SSM

La politique gérée par AmazonSSMManagedInstanceCore AWS contient un certain nombre d'autorisations qui ne sont pas requises pour le gestionnaire de session SSM/SSM RunCommand si vous souhaitez simplement éviter l'accès SSH. Ce qui est particulièrement préoccupant, c'est la question des * autorisations ssm:GetParameter(s) qui permettraient au rôle d'accéder à tous les paramètres du Parameter Store (y compris SecureStrings lorsque la clé KMS gérée par AWS est configurée).

La politique IAM suivante contient l'ensemble minimal d'autorisations pour permettre l'accès aux nœuds via SSM Systems Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Une fois cette politique en place et le plug-in Session Manager installé, vous pouvez ensuite exécuter

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

pour accéder au nœud.

Note

Vous pouvez également envisager d'ajouter des autorisations pour activer la journalisation du gestionnaire de session.

Déployer des employés sur des sous-réseaux privés

En déployant des employés sur des sous-réseaux privés, vous minimisez leur exposition à Internet, d'où proviennent souvent les attaques. À compter du 22 avril 2020, l'attribution d'adresses IP publiques aux nœuds d'un groupe de nœuds gérés sera contrôlée par le sous-réseau sur lequel ils sont déployés. Auparavant, une adresse IP publique était automatiquement attribuée aux nœuds d'un groupe de nœuds gérés. Si vous choisissez de déployer vos nœuds de travail sur des sous-réseaux publics, mettez en œuvre des règles restrictives relatives aux groupes de sécurité AWS afin de limiter leur exposition.

Exécutez Amazon Inspector pour évaluer l'exposition des hôtes, les vulnérabilités et les écarts par rapport aux meilleures pratiques

Vous pouvez utiliser Amazon Inspector pour vérifier l'absence d'accès réseau involontaire à vos nœuds et les vulnérabilités des EC2 instances Amazon sous-jacentes.

Amazon Inspector peut fournir des données sur les vulnérabilités et les expositions communes (CVE) pour vos EC2 instances Amazon uniquement si l'agent Amazon EC2 Systems Manager (SSM) est installé et activé. Cet agent est préinstallé sur plusieurs Amazon Machine Images (AMIs), y compris Amazon Linux AMIs optimisé pour EKS. Quel que soit le statut de l'agent SSM, toutes vos EC2 instances Amazon sont analysées pour détecter les problèmes d'accessibilité au réseau. Pour plus d'informations sur la configuration des scans pour Amazon EC2, consultez Scanning Amazon EC2 instances.

Important

Inspector ne peut pas être exécuté sur l'infrastructure utilisée pour exécuter les pods Fargate.

Solutions de rechange

Courir SELinux

Note

Disponible sur Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket et Amazon Linux 2023

SELinux fournit un niveau de sécurité supplémentaire pour isoler les conteneurs les uns des autres et de l'hôte. SELinux permet aux administrateurs d'appliquer des contrôles d'accès obligatoires (MAC) pour chaque utilisateur, application, processus et fichier. Considérez-le comme un filet de sécurité qui limite les opérations pouvant être effectuées sur des ressources spécifiques en fonction d'un ensemble d'étiquettes. Sur EKS, il SELinux peut être utilisé pour empêcher les conteneurs d'accéder aux ressources des autres.

Les SELinux politiques de conteneur sont définies dans le package container-selinux. Docker CE nécessite ce package (ainsi que ses dépendances) afin que les processus et les fichiers créés par Docker (ou d'autres environnements d'exécution de conteneurs) s'exécutent avec un accès système limité. Les conteneurs tirent parti de l'container_tétiquette qui est un alias desvirt_lxc_net_t. Ces politiques empêchent efficacement les conteneurs d'accéder à certaines fonctionnalités de l'hôte.

Lorsque vous configurez SELinux pour Docker, Docker étiquette automatiquement les charges de travail container_t par type et attribue à chaque conteneur un niveau MCS unique. Cela permettra d'isoler les conteneurs les uns des autres. Si vous avez besoin de restrictions plus souples, vous pouvez créer votre propre profil SElinux qui accorde à un conteneur des autorisations sur des zones spécifiques du système de fichiers. Ceci est similaire PSPs au fait que vous pouvez créer différents profils pour différents conteneurs/pods. Par exemple, vous pouvez avoir un profil pour les charges de travail générales avec un ensemble de contrôles restrictifs et un autre pour les éléments nécessitant un accès privilégié.

SELinux for Containers dispose d'un ensemble d'options qui peuvent être configurées pour modifier les restrictions par défaut. Les SELinux booléens suivants peuvent être activés ou désactivés en fonction de vos besoins :

Booléen Par défaut Description

container_connect_any

off

Autorisez les conteneurs à accéder aux ports privilégiés de l'hôte. Par exemple, si vous avez un conteneur qui doit mapper les ports vers 443 ou 80 sur l'hôte.

container_manage_cgroup

off

Autoriser les conteneurs à gérer la configuration des groupes de groupes. Par exemple, un conteneur exécutant systemd devra être activé.

container_use_cephfs

off

Autoriser les conteneurs à utiliser un système de fichiers ceph.

Par défaut, les conteneurs sont autorisés à lire read/execute /usr et à lire la majeure partie du contenu/etc. Les fichiers se trouvent sous /var/lib/docker et /var/lib/containers portent l'étiquettecontainer_var_lib_t. Pour afficher la liste complète des libellés par défaut, consultez le fichier container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

Les fichiers étiquetés avec container_file_t sont les seuls fichiers accessibles en écriture par les conteneurs. Si vous souhaitez qu'un montage de volume soit inscriptible, vous devez spécifier :z ou :Z à la fin.

  • :zréétiquettera les fichiers afin que le conteneur puisse lire/écrire

  • :Zréétiquettera les fichiers afin que seul le conteneur puisse lire/écrire

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

Dans Kubernetes, le réétiquetage est légèrement différent. Plutôt que de laisser Docker réétiqueter automatiquement les fichiers, vous pouvez spécifier une étiquette MCS personnalisée pour exécuter le pod. Les volumes compatibles avec le réétiquetage seront automatiquement réétiquetés afin d'être accessibles. Les pods dotés d'une étiquette MCS correspondante pourront accéder au volume. Si vous avez besoin d'une isolation stricte, définissez une étiquette MCS différente pour chaque pod.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

Dans cet exemple, cela s0:c144:c154 correspond à une étiquette MCS attribuée à un fichier auquel le conteneur est autorisé à accéder.

Sur EKS, vous pouvez créer des politiques qui permettent l'exécution de conteneurs privilégiés, comme FluentD, et créer SELinux une politique pour lui permettre de lire depuis /var/log sur l'hôte sans avoir à renommer le répertoire hôte. Les pods portant le même label pourront accéder aux mêmes volumes hôtes.

Nous avons implémenté un exemple AMIs pour Amazon EKS SELinux configuré sur CentOS 7 et RHEL 7. Ils AMIs ont été développés pour démontrer des exemples de mises en œuvre répondant aux exigences de clients hautement réglementés.

Avertissement

SELinux ignorera les conteneurs dont le type n'est pas confiné.

Outils et ressources