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
Un groupe AWS de sécurité agit comme un pare-feu virtuel pour les EC2 instances afin de contrôler le trafic entrant et sortant. Par défaut, Amazon VPC CNI utilisera des groupes de sécurité associés au principal ENI sur le nœud. Plus précisément, tous les groupes ENI associés à l'instance auront 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 RDS base de données (si l'on considère que l'RDSentrée 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 Pod-to-External AWS services, 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 RDS base de données Amazon.
Vous pouvez activer les groupes de sécurité pour les pods en configurant ENABLE_POD_ENI=true pour VPCCNI. Une fois activé, le contrôleur de VPC ressourcesAmazonEKSVPCResourceController gérée au rôle de cluster associé à votre EKS cluster Amazon.
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 SecurityGroupPolicy
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 le nombre de pods utilisant des groupes de sécurité dans le calcul du nombre maximum de pods. Consultez le guide de EKS l'utilisateur 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 leENIConfig. Par conséquent, lorsque la mise en réseau personnalisée est activée, évaluez soigneusement l'ordre des groupes de sécurité lors de l'utilisation de groupes de sécurité par pod.
Recommandations
Désactiver le démultiplexage TCP anticipé pour Liveness Probe
Si vous utilisez des sondes Liveness ou Readiness, vous devez également désactiver le démultiplexage TCP anticipé, 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 AWS de configuration existants.
Les groupes de sécurité facilitent la restriction de l'accès réseau aux VPC ressources, telles que les RDS bases de données ou EC2 les instances. L'un des avantages évidents des groupes de sécurité par pod est la possibilité de réutiliser les ressources des groupes AWS de sécurité existants. Si vous utilisez des groupes de sécurité comme pare-feu réseau pour limiter l'accès à vos AWS services, nous vous proposons d'appliquer des groupes de sécurité aux pods utilisant une brancheENIs. Envisagez d'utiliser des groupes de sécurité pour les pods si vous transférez des applications depuis des EC2 instances vers d'autres services dotés de groupes de sécurité EKS et si vous limitez l'accès à d'autres AWS services dotés de groupes de sécurité.
Configurer le mode d'application du groupe de sécurité Pod
La version 1.11 du VPC CNI plugin Amazon 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 module et si la source NAT est activée. 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 VPC CNI with ENABLE_POD_ENI set totrue.
En mode strict, seuls les groupes ENI de sécurité des succursales sont appliqués. La source NAT est également désactivée.
En mode standard, les groupes de sécurité associés à la fois au serveur principal ENI et à la branche ENI (associés au module) 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 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, la source NAT est désactivée afin que les groupes de sécurité ENI sortants des branches 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 VPC réseau. Le trafic entre les pods d'un même nœud passera par leVPC. Cela augmente le VPC trafic et limite les fonctionnalités basées sur les nœuds. Le n' NodeLocal DNSCacheest pas pris en charge avec le mode strict.
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 DNSCachen'est pas pris en charge en mode strict car tout le trafic réseau, même à destination du nœud, entre dans leVPC.
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 AWS services 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 les 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 AWS service interne ou externe au vôtreVPC.
Utilisez des groupes de sécurité par pod pour contrôler efficacement le trafic vers les AWS services
Si une application exécutée au sein du EKS cluster doit communiquer avec une autre ressource au sein du clusterVPC, par exemple une RDS base de données, envisagez d'utiliser SGs for pods. Bien qu'il existe des moteurs de politiques qui vous permettent de spécifier un CIDR ou un DNS nom, ils constituent un choix moins optimal lorsque vous communiquez avec AWS des services dont les points de terminaison se trouvent dans unVPC.
En revanche, les politiques réseau
Amazon vous EKS permet d'utiliser des moteurs de politique réseau tels que Calico
Marquer un seul groupe de sécurité pour utiliser le 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/$name
Configuration NAT pour le trafic sortant
NATLa source est désactivée 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 NAT passerelle ou une instance et activez l'option externe SNAT dans leCNI.
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 auxquels des groupes de sécurité ont été assignés et 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 que cette valeur terminationGracePeriodSeconds est différente de zéro dans le fichier de spécifications de votre Pod (30 secondes par défaut). Cela est essentiel pour qu'Amazon puisse VPC CNI supprimer le réseau Pod du nœud de travail. Lorsqu'il est réglé sur zéro, le CNI plug-in ne supprime pas le réseau Pod de l'hôte et la branche n'ENIest 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 la commande 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 Core. DNS 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 votreVPC. En outre, vous devez inclure des règles permettant à Fargate d'extraire des images de conteneurs d'ECRAmazon ou d'autres registres de conteneurs tels que. DockerHub Pour plus d'informations, consultez la section Plages d'adresses AWS IP dans le manuel de référence AWS général.
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 eniId commande 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
📝 Modifiez cette page sur GitHub
