Groupes de sécurité par pod

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.

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.

Un groupe de sécurité AWS agit comme un pare-feu virtuel pour les EC2 instances afin de contrôler le trafic entrant et sortant. Par défaut, le CNI Amazon VPC utilisera des groupes de sécurité associés à l'ENI principal sur le nœud. Plus précisément, chaque ENI associée à l'instance aura les mêmes groupes EC2 de sécurité. Ainsi, chaque pod d'un nœud partage les mêmes groupes de sécurité que le nœud sur lequel il s'exécute.

Comme le montre l'image ci-dessous, tous les pods d'applications fonctionnant sur des nœuds de travail auront accès au service de base de données RDS (si l'on considère que le RDS entrant autorise le groupe de sécurité des nœuds). Les groupes de sécurité sont trop grossiers car ils s'appliquent à tous les pods exécutés sur un nœud. Les groupes de sécurité pour Pods permettent de segmenter le réseau pour les charges de travail, élément essentiel d'une bonne stratégie de défense en profondeur.

Avec les groupes de sécurité pour Pods, vous pouvez améliorer l'efficacité du calcul en exécutant des applications répondant à des exigences de sécurité réseau variables sur des ressources informatiques partagées. Plusieurs types de règles de sécurité, tels que Pod-to-Pod les services Pod-to-External AWS, peuvent être définis en un seul endroit avec des groupes de EC2 sécurité et appliqués aux charges de travail avec Kubernetes native. APIs L'image ci-dessous montre les groupes de sécurité appliqués au niveau du Pod et montre comment ils simplifient le déploiement de vos applications et l'architecture de vos nœuds. Le Pod peut désormais accéder à la base de données Amazon RDS.

Vous pouvez activer les groupes de sécurité pour les pods en configurant ENABLE_POD_ENI=true le VPC CNI. Une fois activé, le contrôleur de ressources VPC exécuté sur le plan de contrôle (géré par EKS) crée et attache une interface de liaison appelée « aws-k8 s-trunk-eni » au nœud. L'interface de jonction agit comme une interface réseau standard attachée à l'instance. Pour gérer les interfaces de liaison, vous devez ajouter la politique AmazonEKSVPCResourceController gérée au rôle de cluster associé à votre cluster Amazon EKS.

Le contrôleur crée également des interfaces de branche nommées « aws-k8 s-branch-eni » et les associe à l'interface de jonction. Un groupe de sécurité est attribué aux pods à l'aide de la ressource SecurityGroupPolicypersonnalisée et sont associés à une interface de branche. Les groupes de sécurité étant spécifiés à l'aide d'interfaces réseau, nous sommes désormais en mesure de planifier des pods nécessitant des groupes de sécurité spécifiques sur ces interfaces réseau supplémentaires. Consultez la section du guide de l'utilisateur EKS sur les groupes de sécurité pour les pods, y compris les conditions préalables au déploiement.

La capacité de l'interface des succursales s'ajoute aux limites de types d'instances existantes pour les adresses IP secondaires. Les pods qui utilisent des groupes de sécurité ne sont pas pris en compte dans la formule max-pods et lorsque vous utilisez un groupe de sécurité pour des pods, vous devez envisager d'augmenter la valeur max-pods ou accepter d'exécuter moins de pods que le nœud ne peut réellement en supporter.

Un m5.large peut avoir jusqu'à 9 interfaces réseau de succursales et jusqu'à 27 adresses IP secondaires attribuées à ses interfaces réseau standard. Comme le montre l'exemple ci-dessous, le nombre maximum de pods par défaut pour un m5.large est de 29, et EKS compte les pods qui utilisent des groupes de sécurité dans le calcul du nombre maximum de pods. Consultez le guide de l'utilisateur d'EKS pour savoir comment modifier les max-pods pour les nœuds.

Lorsque des groupes de sécurité pour Pods sont utilisés en combinaison avec un réseau personnalisé, le groupe de sécurité défini dans les groupes de sécurité pour Pods est utilisé plutôt que le groupe de sécurité spécifié dans le ENIConfig. Par conséquent, lorsque le réseau personnalisé est activé, évaluez soigneusement l'ordre des groupes de sécurité lorsque vous utilisez des groupes de sécurité par pod.

Recommandations

Désactiver le démultiplexage précoce TCP pour Liveness Probe

Si vous utilisez des sondes Liveness ou Readiness, vous devez également désactiver le démultiplexage précoce TCP, afin que le kubelet puisse se connecter aux pods sur les interfaces réseau des succursales via TCP. Cela n'est requis qu'en mode strict. Pour ce faire, exécutez la commande suivante :

kubectl edit daemonset aws-node -n kube-system

Dans la initContainer section, modifiez la valeur DISABLE_TCP_EARLY_DEMUX de true.

Utilisez Security Group For Pods pour tirer parti des investissements existants dans la configuration AWS.

Les groupes de sécurité facilitent la restriction de l'accès réseau aux ressources VPC, telles que les bases de données ou les instances RDS. EC2 L'un des avantages évidents des groupes de sécurité par pod est la possibilité de réutiliser les ressources des groupes de sécurité AWS existantes. Si vous utilisez des groupes de sécurité comme pare-feu réseau pour limiter l'accès à vos services AWS, nous vous proposons d'appliquer des groupes de sécurité aux pods utilisant une branche ENIs. Envisagez d'utiliser des groupes de sécurité pour les pods si vous transférez des applications d' EC2 instances vers EKS et si vous limitez l'accès à d'autres services AWS dotés de groupes de sécurité.

Configurer le mode d'application du groupe de sécurité Pod

La version 1.11 du plugin Amazon VPC CNI a ajouté un nouveau paramètre nommé POD_SECURITY_GROUP_ENFORCING_MODE (« mode d'application »). Le mode d'application contrôle à la fois quels groupes de sécurité s'appliquent au pod et si le NAT source est activé. Vous pouvez définir le mode d'application comme strict ou standard. Strict est la valeur par défaut, reflétant le comportement précédent du CNI VPC défini sur. ENABLE_POD_ENI true

En mode strict, seuls les groupes de sécurité ENI des succursales sont appliqués. Le NAT source est également désactivé.

En mode standard, les groupes de sécurité associés à la fois à l'ENI principal et à l'ENI de branche (associé au pod) sont appliqués. Le trafic réseau doit respecter les deux groupes de sécurité.

Mode d'application : utilisez le mode strict pour isoler le trafic des pods et des nœuds :

Par défaut, les groupes de sécurité pour Pods sont définis sur le « mode strict ». Utilisez ce paramètre si vous devez complètement séparer le trafic du pod du reste du trafic du nœud. En mode strict, le NAT source est désactivé afin que les groupes de sécurité sortants ENI de la branche puissent être utilisés.

Mode d'application : utilisez le mode standard dans les situations suivantes

IP source du client visible par les conteneurs du Pod

Si vous devez que l'adresse IP source du client reste visible pour les conteneurs du Pod, pensez POD_SECURITY_GROUP_ENFORCING_MODE à la définir surstandard. Les services Kubernetes prennent en charge externalTrafficPolicy =local pour permettre la préservation de l'adresse IP source du client (cluster de type par défaut). Vous pouvez désormais exécuter des services Kubernetes de type NodePort et LoadBalancer utiliser des cibles d'instance externalTrafficPolicy définies sur Local en mode standard. Localpréserve l'adresse IP source du client et évite un second saut pour LoadBalancer et NodePort type Services.

Déploiement NodeLocal DNSCache

Lorsque vous utilisez des groupes de sécurité pour les pods, configurez le mode standard pour prendre en charge les pods qui les utilisent NodeLocal DNSCache. NodeLocal DNSCache améliore les performances du DNS du cluster en exécutant un agent de mise en cache DNS sur les nœuds du cluster en tant DaemonSet que. Cela aidera les pods ayant les exigences les plus élevées en matière de QPS DNS à interroger les Kube-DNS/CoreDNS locaux ayant un cache local, ce qui améliorera la latence.

NodeLocal DNSCache n'est pas pris en charge en mode strict car tout le trafic réseau, même à destination du nœud, entre dans le VPC.

Soutenir la politique réseau Kubernetes

Nous recommandons d'utiliser le mode d'application standard lorsque vous utilisez la politique réseau avec des pods auxquels des groupes de sécurité sont associés.

Nous vous recommandons vivement d'utiliser des groupes de sécurité pour les pods afin de limiter l'accès au niveau du réseau aux services AWS qui ne font pas partie d'un cluster. Envisagez des politiques réseau pour restreindre le trafic réseau entre les pods au sein d'un cluster, souvent connu sous le nom de trafic Est/Ouest.

Identifier les incompatibilités avec les groupes de sécurité par pod

Les instances basées sur Windows et autres que Nitro ne prennent pas en charge les groupes de sécurité pour les pods. Pour utiliser des groupes de sécurité avec des pods, les instances doivent être étiquetées avec isTrunkingEnabled. Utilisez des politiques réseau pour gérer l'accès entre les pods plutôt que les groupes de sécurité si vos pods ne dépendent d'aucun service AWS au sein ou en dehors de votre VPC.

Utilisez des groupes de sécurité par pod pour contrôler efficacement le trafic vers les services AWS

Si une application exécutée dans le cluster EKS doit communiquer avec une autre ressource du VPC, par exemple une base de données RDS, envisagez d'utiliser SGs for pods. Bien que certains moteurs de politiques vous permettent de spécifier un CIDR ou un nom DNS, ils constituent un choix moins optimal lorsque vous communiquez avec des services AWS dont les points de terminaison se trouvent au sein d'un VPC.

En revanche, les politiques réseau de Kubernetes fournissent un mécanisme permettant de contrôler le trafic entrant et sortant à la fois à l'intérieur et à l'extérieur du cluster. Les politiques réseau Kubernetes doivent être prises en compte si les dépendances de votre application vis-à-vis d'autres services AWS sont limitées. Vous pouvez configurer des politiques réseau qui spécifient des règles de sortie basées sur des plages d'adresses CIDR afin de limiter l'accès aux services AWS, par opposition à la sémantique native d'AWS telle que. SGs Vous pouvez utiliser les politiques réseau de Kubernetes pour contrôler le trafic réseau entre les pods (souvent appelé trafic est/ouest) et entre les pods et les services externes. Les politiques réseau Kubernetes sont mises en œuvre aux niveaux OSI 3 et 4.

Amazon EKS vous permet d'utiliser des moteurs de politique réseau tels que Calico et Cilium. Par défaut, les moteurs de politique réseau ne sont pas installés. Consultez les guides d'installation respectifs pour obtenir des instructions de configuration. Pour plus d'informations sur l'utilisation de la politique réseau, consultez les meilleures pratiques de sécurité d'EKS. La fonctionnalité des noms d'hôte DNS est disponible dans les versions d'entreprise des moteurs de politique réseau, ce qui peut être utile pour contrôler le trafic entre les services/pods Kubernetes et les ressources exécutées en dehors d'AWS. Vous pouvez également envisager de prendre en charge les noms d'hôte DNS pour les services AWS qui ne prennent pas en charge les groupes de sécurité par défaut.

Marquez un seul groupe de sécurité pour utiliser AWS Loadbalancer Controller

Lorsque de nombreux groupes de sécurité sont alloués à un pod, Amazon EKS recommande de baliser un seul groupe de sécurité avec la mention « kubernetes.io/cluster/$namepartagé » ou « possédé ». La balise permet au contrôleur AWS Loadbalancer de mettre à jour les règles des groupes de sécurité afin d'acheminer le trafic vers les Pods. Si un seul groupe de sécurité est attribué à un Pod, l'attribution d'une balise est facultative. Les autorisations définies dans un groupe de sécurité sont additives. Il suffit donc de baliser un seul groupe de sécurité pour que le contrôleur d'équilibrage de charge localise et réconcilie les règles. Cela permet également de respecter les quotas par défaut définis par les groupes de sécurité.

Configurer le NAT pour le trafic sortant

Le NAT source est désactivé pour le trafic sortant provenant des pods auxquels des groupes de sécurité ont été affectés. Pour les pods utilisant des groupes de sécurité qui nécessitent un accès à Internet, lancez des nœuds de travail sur des sous-réseaux privés configurés avec une passerelle ou une instance NAT et activez le SNAT externe dans le CNI.

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

Déployer des pods avec des groupes de sécurité sur des sous-réseaux privés

Les pods auxquels des groupes de sécurité sont affectés doivent être exécutés sur des nœuds déployés sur des sous-réseaux privés. Notez que les pods dotés de groupes de sécurité assignés déployés sur des sous-réseaux publics ne pourront pas accéder à Internet.

Vérifier les terminationGracePeriodsecondes dans le fichier de spécifications du pod

Assurez-vous qu'il terminationGracePeriodSeconds n'est pas nul dans le fichier de spécifications de votre Pod (30 secondes par défaut). Cela est essentiel pour qu'Amazon VPC CNI puisse supprimer le réseau Pod du nœud de travail. Lorsqu'il est réglé sur zéro, le plug-in CNI ne supprime pas le réseau Pod de l'hôte et la branche ENI n'est pas nettoyée efficacement.

Utilisation de groupes de sécurité pour les pods avec Fargate

Les groupes de sécurité pour les pods qui s'exécutent sur Fargate fonctionnent de manière très similaire aux pods qui s'exécutent EC2 sur des nœuds de travail. Par exemple, vous devez créer le groupe de sécurité avant de le référencer dans celui que SecurityGroupPolicy vous associez à votre Fargate Pod. Par défaut, le groupe de sécurité du cluster est attribué à tous les Fargate Pods lorsque vous n'en attribuez pas explicitement un SecurityGroupPolicy à un Fargate Pod. Pour des raisons de simplicité, vous pouvez ajouter le groupe de sécurité du cluster à celui d'un Fagate Pod SecurityGroupPolicy , sinon vous devrez ajouter les règles de groupe de sécurité minimales à votre groupe de sécurité. Vous pouvez trouver le groupe de sécurité du cluster à l'aide de l'API describe-cluster.

 aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'

cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-fargate-sg-policy
  namespace: my-fargate-namespace
spec:
  podSelector:
    matchLabels:
      role: my-fargate-role
  securityGroups:
    groupIds:
      - cluster_security_group_id
      - my_fargate_pod_security_group_id
EOF

Les règles minimales relatives aux groupes de sécurité sont répertoriées ici. Ces règles permettent aux Fargate Pods de communiquer avec des services intégrés au cluster tels que kube-apiserver, kubelet et CoreDNS. Vous devez également ajouter des règles pour autoriser les connexions entrantes et sortantes à destination et en provenance de votre Fargate Pod. Cela permettra à votre pod de communiquer avec d'autres pods ou ressources de votre VPC. En outre, vous devez inclure des règles permettant à Fargate d'extraire les images de conteneurs d'Amazon ECR ou d'autres registres de conteneurs tels que. DockerHub Pour plus d'informations, consultez les plages d'adresses IP AWS dans le manuel de référence général AWS.

Vous pouvez utiliser les commandes ci-dessous pour trouver les groupes de sécurité appliqués à un Fargate Pod.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Notez la commande eNIid ci-dessus.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

Les pods Fargate existants doivent être supprimés et recréés pour que de nouveaux groupes de sécurité puissent être appliqués. Par exemple, la commande suivante lance le déploiement de l'application d'exemple. Pour mettre à jour des pods spécifiques, vous pouvez modifier l'espace de noms et le nom du déploiement dans la commande ci-dessous.

kubectl rollout restart -n example-ns deployment example-pod