Groupes de sécurité pour Pods

Pour déployer des groupes de sécurité pour les Pods

Si vous utilisez des groupes de sécurité pour les Pods Fargate uniquement et que vous n'avez aucun nœud Amazon EC2 dans votre cluster, passez à l'Déployer un exemple d'application.

1. Vérifiez la version actuelle de Amazon VPC CNI plugin for Kubernetes à l'aide de la commande suivante :

   kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
   

   L'exemple qui suit illustre un résultat.

   v1.7.6

   Si la version de votre Amazon VPC CNI plugin for Kubernetes est antérieure à 1.7.7, mettez à jour le plugin vers la version 1.7.7 ou ultérieure. Pour plus d’informations, consultez Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS.

2. Ajoutez la politique IAM gérée AmazonEKSVPCResourceController au rôle de cluster qui est associé à votre cluster Amazon EKS. La politique permet au rôle de gérer les interfaces réseau, leurs adresses IP privées, leur attachement et leur détachement vers et depuis les instances réseau.

   1. Récupérez le nom de votre rôle IAM de cluster et stockez-le dans une variable. Remplacez my-cluster par le nom de votre cluster.

      cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
      

   2. Attachez la stratégie au rôle.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
      

3. Activez le module complémentaire Amazon VPC CNI pour gérer les interfaces réseau pour les Pods en définissant la variable ENABLE_POD_ENI sur true dans le DaemonSet aws-node. Une fois que ce paramètre est défini sur true, le module complémentaire crée pour chaque nœud du cluster une ressource personnalisée cninode. Le contrôleur de ressources VPC crée et attache une interface réseau spéciale appelée interface réseau de tronc avec la description aws-k8s-trunk-eni.

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

   Note

   L'interface réseau de tronc est incluse dans le nombre maximal d'interfaces réseau prises en charge par le type d'instance. Pour obtenir la liste du nombre maximal d'interfaces réseau prises en charge par chaque type d'instance, consultez la section Adresses IP par interface réseau et par type d'instance dans le guide de l'utilisateur Amazon EC2. Si votre nœud a déjà le nombre maximal d'interfaces réseau standard qui lui sont attachées, le contrôleur de ressources VPC réservera un espace. Vous devrez réduire suffisamment vos Pods en cours d'exécution pour que le contrôleur puisse détacher et supprimer une interface réseau standard, créer l'interface réseau de tronc et l'attacher à l'instance.

4. Vous pouvez voir quels nœuds ont une ressource personnalisée CNINode avec la commande suivante. Si le message No resources found est renvoyé, attendez plusieurs secondes et réessayez. L'étape précédente nécessite le redémarrage des Pods Amazon VPC CNI plugin for Kubernetes, qui prend plusieurs secondes.

   $ kubectl get cninode -A
        NAME FEATURES
        ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
        ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]

   Si vous utilisez des versions CNI VPC antérieures à 1.15, les étiquettes de nœud ont été utilisées à la place de la ressource personnalisée CNINode. Vous pouvez voir quels nœuds ont l'étiquette de nœud aws-k8s-trunk-eni définis sur true avec la commande suivante. Si le message No resources found est renvoyé, attendez plusieurs secondes et réessayez. L'étape précédente nécessite le redémarrage des Pods Amazon VPC CNI plugin for Kubernetes, qui prend plusieurs secondes.

   kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
   -
   

   Une fois l'interface réseau de tronc créée, les Pods son assignés aux adresses IP secondaires à partir des interfaces réseau standard ou de connexion. L'interface de tronc est automatiquement supprimée si le nœud est supprimé.

   Lorsque vous déployez un groupe de sécurité pour un Pod dans une étape ultérieure, le contrôleur de ressources VPC crée une interface réseau spéciale appelée interface réseau de branche avec une description de aws-k8s-branch-eni et y associe les groupes de sécurité. Les interfaces réseau de branche sont créées en plus des interfaces réseau standard et de tronc attachées au nœud.

   Si vous utilisez des sondes de liveness ou de disponibilité, vous devez également désactiver le démux précoce TCP, de sorte que kubelet peut se connecter à des Pods sur des interfaces réseau de branche via TCP. Pour désactiver le démux précoce TCP, exécutez la commande suivante :

   kubectl patch daemonset aws-node -n kube-system \
     -p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
   

   Note

   Si vous utilisez la version 1.11.0 ou ultérieure du module complémentaire Amazon VPC CNI plugin for Kubernetes et définir sur POD_SECURITY_GROUP_ENFORCING_MODE=standard, comme décrit à l'étape suivante, vous n'avez pas besoin d'exécuter la commande précédente.

5. Si votre cluster utilise NodeLocal DNSCache, ou si vous souhaitez utiliser la politique réseau Calico avec vos Pods qui ont leurs propres groupes de sécurité, ou si vous avez des services Kubernetes de type NodePort et LoadBalancer utilisant des cibles d'instance avec un paramètre externalTrafficPolicy défini sur Local pour les Pods que vous souhaitez attribuer à des groupes de sécurité, alors vous devez utiliser une version 1.11.0 ou ultérieure du module complémentaire Amazon VPC CNI plugin for Kubernetes et vous devez activer le paramètre suivant :

   kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
   

   Important

   • Les règles de groupe de sécurité de Pod ne sont pas appliquées au trafic entre les Pods ou entre les Pods et les services, comme kubelet ou nodeLocalDNS, qui se trouvent sur le même nœud. Les pods utilisant différents groupes de sécurité sur le même nœud ne peuvent pas communiquer, car ils sont configurés dans des sous-réseaux différents et le routage est désactivé entre ces sous-réseaux.

   • Le trafic sortant des Pods vers des adresses situées en dehors du VPC est l'adresse réseau traduite en adresse IP de l'interface réseau principale de l'instance (sauf si vous avez également défini AWS_VPC_K8S_CNI_EXTERNALSNAT=true). Pour ce trafic, les règles des groupes de sécurité de l'interface réseau principale sont utilisées, plutôt que les règles des groupes de sécurité de Pod's.

   • Pour que ce paramètre s'applique aux Pods existants, vous devez redémarrer les Pods ou les nœuds sur lesquels les Pods s'exécutent.

Pour déployer un exemple de Pod avec un groupe de sécurité

1. Créez un espace de noms Kubernetes vers lequel déployer les ressources. Vous pouvez remplacer my-namespace par le nom d'un espace de nom que vous voulez utiliser.

   kubectl create namespace my-namespace
   

2. Déployez une politique SecurityGroupPolicy Amazon EKS sur votre cluster.

   1. Copiez les contenus suivants sur votre appareil. Vous pouvez remplacer podSelector par serviceAccountSelector si vous préférez sélectionner des Pods en fonction des labels de compte de service. Vous devez spécifier un sélecteur ou l'autre. Un podSelector vide (par exemple : podSelector: {}) sélectionne tous les Pods de l'espace de noms. Vous pouvez remplacer my-role par le nom de votre rôle. Un serviceAccountSelector vide sélectionne tous les comptes de service dans l'espace de noms. Vous pouvez remplacer my-security-group-policy par un nom pour votre SecurityGroupPolicy et my-namespace par le nom de l'espace de noms dans lequel vous voulez créer la SecurityGroupPolicy.

      Vous devez remplacer my_pod_security_group_id par l'ID d'un groupe de sécurité existant. Si vous n'avez pas de groupe de sécurité existant, vous devez en créer un. Pour plus d'informations, veuillez consulter la section Amazon EC2 security groups for Linux instances (français non garanti) dans le Guide de l'utilisateur Amazon EC2. Vous pouvez spécifier 1 à 5 ID de groupe de sécurité. Si vous spécifiez plusieurs ID, la combinaison de toutes les règles de tous les groupes de sécurité est effective pour les Pods sélectionnés.

      cat >my-security-group-policy.yaml <<EOF
      apiVersion: vpcresources.k8s.aws/v1beta1
      kind: SecurityGroupPolicy
      metadata:
        name: my-security-group-policy
        namespace: my-namespace
      spec:
        podSelector: 
          matchLabels:
            role: my-role
        securityGroups:
          groupIds:
            - my_pod_security_group_id
      EOF
      

      Important

      Le ou les groupes de sécurité que vous spécifiez pour vos Pod doivent répondre aux critères suivants :

      • Ils doivent exister. S'ils n'existent pas, lorsque vous déployez un Pod correspondant au sélecteur, votre Pod reste bloqué dans le processus de création. Si vous décrivez le Pod, vous verrez un message d'erreur similaire à ce qui suit : An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist.

      • Ils doivent autoriser les communications entrantes du groupe de sécurité appliqué à vos nœuds (pour kubelet) sur tous les ports pour lesquels vous avez configuré des sondes.

      • Ils doivent autoriser les communications sortantes sur les ports TCP et UDP 53 vers un groupe de sécurité attribué aux Pods (ou aux nœuds sur lesquels les Pods sont exécutés) exécutant CoreDNS. Le groupe de sécurité pour vos Pods CoreDNS doit autoriser le trafic entrant des ports TCP et UDP 53 du groupe de sécurité que vous spécifiez.

      • Ils doivent disposer des règles entrantes et sortantes nécessaires pour communiquer avec d'autres Pods avec qui ils doivent communiquer.

      • Ils doivent avoir des règles qui permettent aux Pods de communiquer avec le plan de contrôle Kubernetes si vous utilisez le groupe de sécurité avec Fargate. La façon la plus simple de le faire est de spécifier le groupe de sécurité de cluster comme l'un des groupes de sécurité.

      Les politiques de groupe de sécurité s'appliquent uniquement aux Pods nouvellement planifiés. Elles n'affectent pas les Pods en cours d'exécution.

   2. Déployez la politique.

      kubectl apply -f my-security-group-policy.yaml
      

3. Déployez un exemple d'application avec une étiquette correspondant à la valeur my-role pour podSelector que vous avez spécifié à l'étape précédente.

   1. Copiez les contenus suivants sur votre appareil. Remplacez les exemples de valeur par les vôtres, puis exécutez la commande modifiée. Si vous remplacez my-role, assurez-vous qu'il est identique à la valeur que vous avez spécifiée pour le sélecteur dans une étape précédente.

      cat >sample-application.yaml <<EOF
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: my-deployment
        namespace: my-namespace
        labels:
          app: my-app
      spec:
        replicas: 4
        selector:
          matchLabels:
            app: my-app
        template:
          metadata:
            labels:
              app: my-app
              role: my-role
          spec:
            terminationGracePeriodSeconds: 120
            containers:
            - name: nginx
              image: public.ecr.aws/nginx/nginx:1.23
              ports:
              - containerPort: 80
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: my-app
        namespace: my-namespace
        labels:
          app: my-app
      spec:
        selector:
          app: my-app
        ports:
          - protocol: TCP
            port: 80
            targetPort: 80
      EOF
      

   2. Pour déployer l'application, exécutez la commande suivante. Lorsque vous déployez l'application, le plugin Amazon VPC CNI plugin for Kubernetes correspond au label role et les groupes de sécurité que vous avez spécifiés à l'étape précédente sont appliqués au Pod.

      kubectl apply -f sample-application.yaml
      

4. Affichez les Pods déployés avec l'exemple d'application. Pour le reste de ce sujet, ce terminal est appelé TerminalA.

   kubectl get pods -n my-namespace -o wide
   

   L'exemple qui suit illustre un résultat.

   NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE                                            NOMINATED NODE   READINESS GATES
   my-deployment-5df6f7687b-4fbjm   1/1     Running   0          7m51s   192.168.53.48    ip-192-168-33-28.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-j9fl4   1/1     Running   0          7m51s   192.168.70.145   ip-192-168-92-33.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-rjxcz   1/1     Running   0          7m51s   192.168.73.207   ip-192-168-92-33.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-zmb42   1/1     Running   0          7m51s   192.168.63.27    ip-192-168-33-28.region-code.compute.internal   <none>           <none>

   Note

   • Si des Pods sont bloqués à l'état Waiting, exécutez kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace. Si vous voyez Insufficient permissions: Unable to create Elastic Network Interface., vérifiez que vous avez ajouté la politique IAM au rôle de cluster IAM dans une étape précédente.

   • Si des Pods sont bloqués à l'état Pending, vérifiez que votre type d'instance de nœud est répertorié dans limits.go et que le produit du nombre maximal d'interfaces réseau de branche pris en charge par le type d'instance multiplié par le nombre de nœuds de votre groupe de nœuds n'a pas encore été atteint. Par exemple, une instance m5.large prend en charge neuf interfaces réseau de branche. Si votre groupe de nœuds comporte cinq nœuds, un maximum de 45 interfaces réseau de branche peut être créé pour le groupe de nœuds. Le 46e Pod que vous tentez de déployer sera installé dans l'état Pending jusqu'à ce qu'un autre Pod ayant des groupes de sécurité associés soit supprimé.

   Si vous exécutez kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace et recevez un message similaire au message suivant, il peut être ignoré en toute sécurité. Ce message peut s'afficher lorsque Amazon VPC CNI plugin for Kubernetes tente de configurer les réseaux de l'hôte et échoue pendant la création de l'interface réseau. Le plugin journalise cet événement jusqu'à ce que l'interface réseau soit créée.

   Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
   cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container

   Vous ne pouvez pas dépasser le nombre maximal de Pods pouvant être exécutés sur le type d'instance. Pour obtenir la liste du nombre maximal de Pods que vous pouvez exécuter sur chaque type d'instance, consultez eni-max-pods.txt sur GitHub. Lorsque vous supprimez un Pod qui a des groupes de sécurité associés ou que vous supprimez le nœud sur lequel le Pod s'exécute, le contrôleur de ressources VPC supprime l'interface réseau de branche. Si vous supprimez un cluster avec des Pods utilisant des Pods pour les groupes de sécurité, le contrôleur ne supprime pas les interfaces réseau de branche et vous devez donc les supprimer vous-même. Pour plus d'informations sur la suppression d'interfaces réseau, consultez Supprimer une interface réseau dans le guide de l'utilisateur Amazon EC2.

5. Dans un terminal séparé, placez-vous dans l'un des Pods. Pour le reste de ce sujet, ce terminal est appelé TerminalB. Remplacez 5df6f7687b-4fbjm par l'ID d'un des Pods renvoyés dans votre sortie de l'étape précédente.

   kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
   

6. À partir du shell dans TerminalB, confirmez que l'exemple d'application fonctionne.

   curl my-app
   

   L'exemple qui suit illustre un résultat.

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   [...]

   Vous avez reçu la sortie, car tous les Pods exécutant l'application sont associés au groupe de sécurité que vous avez créé. Ce groupe contient une règle qui autorise tout le trafic entre tous les Pods auxquels le groupe de sécurité est associé. Le trafic DNS est autorisé à partir de ce groupe de sécurité vers le groupe de sécurité du cluster associé à vos nœuds. Les nœuds exécutent les Pods CoreDNS, sur lesquels vos Pods ont effectué une recherche de nom.

7. À partir du TerminalA, supprimez les règles de groupe de sécurité qui autorisent la communication DNS au groupe de sécurité du cluster de votre groupe de sécurité. Si vous n'avez pas ajouté les règles DNS au groupe de sécurité du cluster lors d'une étape précédente, remplacez $my_cluster_security_group_id par l'ID du groupe de sécurité dans lequel vous avez créé les règles.

   aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
   aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
   

8. À partir du TerminalB, essayez de nouveau d'accéder à l'application.

   curl my-app
   

   L'exemple qui suit illustre un résultat.

   curl: (6) Could not resolve host: my-app

   La tentative échoue, car le Pod n'est plus en mesure d'accéder aux Pods CoreDNS, auxquels le groupe de sécurité du cluster est associé. Le groupe de sécurité du cluster ne dispose plus des règles de groupe de sécurité qui autorisent la communication DNS à partir du groupe de sécurité associé à votre Pod.

   Si vous tentez d'accéder à l'application à l'aide des adresses IP renvoyées pour l'un des Pods dans une étape précédente, vous recevez toujours une réponse, car tous les ports sont autorisés entre les Pods auxquels le groupe de sécurité est associé et une recherche de nom n'est pas requise.

9. Une fois l'expérimentation terminée, vous pouvez supprimer l'exemple de politique de groupe de sécurité, l'application et le groupe de sécurité que vous avez créés. Exécutez les commandes suivantes à partir du TerminalA.

   kubectl delete namespace my-namespace
   aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
   wait
   sleep 45s 
   aws ec2 delete-security-group --group-id $my_pod_security_group_id