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.
Groupes de sécurité par pod
Astuce
Découvrez les
Un groupe de sécurité AWS agit comme un pare-feu virtuel pour les instances EC2 afin de contrôler le trafic entrant et sortant. Par défaut, Amazon VPC CNI utilisera les 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 de sécurité EC2. 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'application fonctionnant sur des nœuds de travail auront accès au service de base de données RDS (étant donné que RDS Inbound 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 fournissent une segmentation du réseau pour les charges de travail, ce qui constitue un élément essentiel d'une bonne stratégie de défense en profondeur.
Grâce aux groupes de sécurité pour Pods, vous pouvez améliorer l'efficacité de calcul en exécutant des applications présentant 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 les groupes de sécurité EC2 et appliqués aux charges de travail à l'aide des API natives de Kubernetes. 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 ENABLE_POD_ENI=true configurant VPC CNI. Une fois activé, le contrôleur de ressources VPC 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-k8s-branch-eni » et les associe à l'interface de jonction. Un groupe de sécurité est attribué aux pods à l'aide de la ressource SecurityGroupPolicy
La capacité de l'interface de branche s'ajoute aux limites de type d'instance 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 les pods, vous devez envisager d'augmenter la valeur max-pods ou accepter d'exécuter moins de pods que ce que le nœud peut réellement prendre en charge.
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 nombre maximum de pods. Consultez le guide de l'utilisateur d'EKS pour savoir comment modifier les max-pods pour les nœuds.
Lorsque les groupes de sécurité pour les pods sont utilisés en combinaison avec une mise en réseau personnalisée, le groupe de sécurité défini dans les groupes de sécurité pour les pods est utilisé plutôt que le groupe de sécurité spécifié dans l'ENIconfig. Par conséquent, lorsque la mise en réseau personnalisée est activée, évaluez soigneusement l'ordre des groupes de sécurité tout en utilisant des groupes de sécurité par pod.
Recommandations
Désactiver le démultiplexage anticipé TCP pour Liveness Probe
Si vous utilisez des sondes Liveness ou Readiness, vous devez également désactiver le démultiplexage anticipé 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 pour true.
Utilisez Security Group For Pods pour tirer parti des investissements existants dans la configuration AWS.
Les groupes de sécurité permettent de restreindre plus facilement l'accès réseau aux ressources VPC, telles que les bases de données RDS ou les instances EC2. L'un des avantages évidents des groupes de sécurité par pod est la possibilité de réutiliser les ressources existantes des groupes de sécurité AWS. 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 à l'aide des ENI de branche. Envisagez d'utiliser des groupes de sécurité pour les pods si vous transférez des applications d'instances EC2 vers EKS et limitez l'accès à d'autres services AWS à l'aide de groupes de sécurité.
Configurer le mode d'application du groupe de sécurité Pod
La version 1.11 du plug-in 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 les groupes de sécurité qui s'appliquent au pod et si le NAT source est activé. Vous pouvez spécifier le mode d'application comme strict ou standard. Strict est la valeur par défaut, reflétant le comportement précédent du VPC CNI ENABLE_POD_ENI défini sur. true
En mode strict, seuls les groupes de sécurité ENI des branches 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é.
Avertissement
Tout changement de mode n'aura d'impact que sur les Pods récemment lancés. Les Pods existants utiliseront le mode configuré lors de la création du Pod. Les clients devront recycler les pods existants avec des groupes de sécurité s'ils souhaitent modifier le comportement du trafic.
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 les Pods sont définis en « mode strict ». Utilisez ce paramètre si vous devez séparer complètement 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.
Avertissement
Lorsque le mode strict est activé, tout le trafic sortant d'un pod quitte le nœud et entre dans le réseau VPC. Le trafic entre les pods d'un même nœud transitera par le VPC. Cela augmente le trafic VPC et limite les fonctionnalités basées sur les nœuds. Le NodeLocal DNSCache n'est pas pris en charge en mode strict.
Mode d'application : utilisez le mode standard dans les situations suivantes
Adresse IP source du client visible par les conteneurs du Pod
Si vous souhaitez 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 external TrafficPolicy =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 en utilisant des cibles d'instance avec un paramètre externe TrafficPolicy défini 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 de NodeLocal DNSCache
Lorsque vous utilisez des groupes de sécurité pour les pods, configurez le mode standard pour prendre en charge les pods qui utilisent NodeLocal DNSCache
NodeLocal DNSCache n'est pas pris en charge en mode strict car tout le trafic réseau, même vers le nœud, entre dans le VPC.
Soutenir la politique réseau de Kubernetes
Nous vous recommandons d'utiliser le mode d'application standard lorsque vous utilisez la politique réseau avec des pods associés à des groupes de sécurité.
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 appelé East/West trafic.
Identifier les incompatibilités avec les groupes de sécurité par pod
Windows-based et les instances autres que Nitro ne prennent pas en charge les groupes de sécurité pour les Pods. Pour utiliser les groupes de sécurité avec les 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 au sein du cluster EKS doit communiquer avec une autre ressource du VPC, par exemple une base de données RDS, envisagez d'utiliser des SG pour les pods. Bien que certains moteurs de politique 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 résident dans un VPC.
En revanche, les politiques réseau de Kubernetes
Amazon EKS vous permet d'utiliser des moteurs de politique réseau tels que Calico
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é en indiquant qu'il est kubernetes.io/cluster/$name partagé ou détenu. La balise permet à AWS Loadbalancer Controller 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'un tag est facultative. Les autorisations définies dans un groupe de sécurité s'additionnent. Par conséquent, le balisage d'un seul groupe de sécurité est suffisant pour que le contrôleur Loadbalancer 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é sont attribués. Pour les pods utilisant des groupes de sécurité qui nécessitent d'accéder à 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 attribués doivent être exécutés sur des nœuds déployés sur des sous-réseaux privés. Notez que les pods auxquels des groupes de sécurité sont assignés et déployés sur des sous-réseaux publics ne pourront pas accéder à Internet.
Vérification résiliation GracePeriodSeconds dans le fichier de spécifications du pod
Assurez-vous que cette valeur terminationGracePeriodSeconds est différente de zéro dans le fichier de spécification 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 sur des nœuds de travail EC2. Par exemple, vous devez créer le groupe de sécurité avant de le référencer dans le fichier 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'attribuez pas explicitement un SecurityGroupPolicy à un Fargate Pod. Par souci de simplicité, vous pouvez ajouter le groupe de sécurité du cluster à 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 du groupe 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 depuis et vers 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 des images de conteneurs depuis Amazon ECR ou d'autres registres de conteneurs tels que. DockerHub Pour plus d'informations, consultez la section Plages d'adresses IP AWS dans la référence générale AWS.
Vous pouvez utiliser les commandes ci-dessous pour rechercher les groupes de sécurité appliqués à un Fargate Pod.
kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.fargate\.amazonaws\.com/pod-sg}{"\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é soient 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
