Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Utiliser une politique de groupe de sécurité pour un Amazon EKS Pod

Pour utiliser des groupes de sécurité pour les pods, vous devez disposer d'un groupe de sécurité existant. Les étapes suivantes vous montrent comment utiliser la politique de groupe de sécurité pour un Pod. Sauf indication contraire, effectuez toutes les étapes à partir du même terminal, car les variables utilisées dans les étapes suivantes ne sont pas conservées d'un terminal à l'autre.

Si vous possédez un Pod avec EC2 des instances Amazon, vous devez configurer le plugin avant d'utiliser cette procédure. Pour de plus amples informations, veuillez consulter Configurer le plug-in Amazon VPC CNI pour Kubernetes pour les groupes de sécurité pour Amazon EKS Pods.

Créez un espace de noms Kubernetes vers lequel déployer les ressources . Vous pouvez le my-namespace remplacer par le nom de l'espace de noms que vous souhaitez utiliser.
```
kubectl create namespace my-namespace
```
Déployez une politique SecurityGroupPolicy Amazon EKS sur votre cluster.
1. Copiez les contenus suivants sur votre appareil. Vous pouvez les podSelector remplacer par serviceAccountSelector si vous préférez sélectionner des pods en fonction des étiquettes des comptes de service. Vous devez spécifier un sélecteur ou l'autre. Un champ vide podSelector (exemple :podSelector: {}) sélectionne tous les pods de l'espace de noms. Vous pouvez my-role modifier le nom de votre rôle. Un serviceAccountSelector vide sélectionne tous les comptes de service dans l'espace de noms. Vous pouvez le my-security-group-policy remplacer par un nom pour votre nom SecurityGroupPolicy et my-namespace par l'espace de noms SecurityGroupPolicy dans lequel vous souhaitez le créer.
  
  Vous devez le my_pod_security_group_id remplacer 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, consultez les groupes EC2 de sécurité Amazon pour les instances Linux dans le guide de EC2 l'utilisateur Amazon. Vous pouvez spécifier un groupe IDs de sécurité de 1 à 5. Si vous spécifiez plusieurs identifiants, 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 pods 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 au suivant :An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist.
  
  Ils doivent autoriser les communications entrantes depuis le groupe de sécurité appliqué à vos nœuds (pourkubelet) via tous les ports pour lesquels vous avez configuré des sondes.
  
  Ils doivent autoriser les communications sortantes via TCP les UDP ports 53 vers un groupe de sécurité attribué aux Pods (ou aux nœuds sur lesquels les Pods s'exécutent) exécutant CoreDNS. Le groupe de sécurité de vos pods CoreDNS doit autoriser le trafic TCP entrant UDP et le trafic du port 53 en provenance du groupe de sécurité que vous spécifiez.
  
  Ils doivent disposer des règles d'entrée et de sortie nécessaires pour communiquer avec les autres pods avec lesquels ils doivent communiquer.
  
  Ils doivent disposer de règles permettant 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 relatives aux groupes de sécurité ne s'appliquent qu'aux nouveaux pods planifiés. Ils n'affectent pas le fonctionnement des Pods.
2. Déployez la politique.
```
kubectl apply -f my-security-group-policy.yaml
```

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.

Copiez les contenus suivants sur votre appareil. Remplacez le example values par le vôtre, puis exécutez la commande modifiée. Si vous remplacezmy-role, assurez-vous qu'elle est identique à la valeur que vous avez spécifiée pour le sélecteur à l'é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

Pour déployer l'application, exécutez la commande suivante. Lorsque vous déployez l'application, le plugin Amazon VPC CNI pour Kubernetes correspond à l'roleétiquette 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
```

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
Suivez ces conseils si des pods sont bloqués.
- Si des pods sont bloqués dans Waiting cet état, exécutez-leskubectl 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, vérifiez que Pending le type d'instance de votre nœud est répertorié dans limits.go et que le produit du nombre maximum d'interfaces réseau de succursales prises en charge par le type d'instance multiplié par le nombre de nœuds de votre groupe de nœuds n'est pas déjà 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 restera en Pending état jusqu'à ce qu'un autre pod associé à des groupes de sécurité 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 le plug-in Amazon VPC CNI pour Kubernetes tente de configurer le réseau hôte et échoue lors de 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 maximum 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 on GitHub. Lorsque vous supprimez un pod auquel des groupes de sécurité sont associés, ou que vous supprimez le nœud sur lequel le pod est exécuté, le contrôleur de ressources VPC supprime l'interface réseau de la succursale. Si vous supprimez un cluster contenant des pods en utilisant des pods pour les groupes de sécurité, le contrôleur ne supprime pas les interfaces réseau des succursales. Vous devrez 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 EC2 l'utilisateur Amazon.
Dans un terminal séparé, décochez l'un des pods. Pour le reste de ce sujet, ce terminal est appelé TerminalB. 5df6f7687b-4fbjmRemplacez-le par l'ID de l'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
```
À 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 le résultat 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, dont le nom a été recherché par vos pods.
À 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, $my_cluster_security_group_id remplacez-les 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
```
À 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 les communications DNS depuis le groupe de sécurité associé à votre Pod.

Si vous tentez d'accéder à l'application en utilisant les adresses IP renvoyées pour l'un des pods lors d'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 aucune recherche de nom n'est requise.

Une fois l'expérimentation terminée, vous pouvez supprimer les exemples de politique de groupe de sécurité, d'application et de 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

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configuration

Interfaces multiples

Utiliser une politique de groupe de sécurité pour un Amazon EKS Pod

Important

Note