Usa una policy di gruppo di sicurezza per un Amazon EKS Pod

Per utilizzare i gruppi di sicurezza per Pods, devi disporre di un gruppo di sicurezza esistente. I passaggi seguenti mostrano come utilizzare la politica del gruppo di sicurezza per un Pod. Salvo diversa indicazione, completa tutti i passaggi dallo stesso terminale perché nei passaggi seguenti vengono utilizzate variabili che non persistono tra i terminali.

Se disponi di un Pod con EC2 istanze Amazon, devi configurare il plug-in prima di utilizzare questa procedura. Per ulteriori informazioni, consulta Configura il plug-in Amazon VPC CNI per Kubernetes per gruppi di sicurezza per Amazon EKS Pods.

1. Crea uno spazio dei nomi Kubernetes in cui distribuire le risorse . Puoi sostituirlo my-namespace con il nome di uno spazio dei nomi che desideri utilizzare.

   kubectl create namespace my-namespace

2. Implementa una SecurityGroupPolicy Amazon EKS nel cluster.

   1. Copia i seguenti contenuti sul dispositivo. Puoi sostituirlo podSelector con serviceAccountSelector se preferisci selezionare i Pod in base alle etichette degli account di servizio. É necessario specificare uno selettore. Un campo vuoto podSelector (esempio:podSelector: {}) seleziona tutti i Pod nel namespace. Puoi cambiare il my-role nome del tuo ruolo. Un serviceAccountSelector vuoto seleziona tutti gli account di servizio nello spazio dei nomi. Puoi sostituirlo my-security-group-policy con un nome per te SecurityGroupPolicy e my-namespace con lo spazio dei nomi in cui desideri crearlo. SecurityGroupPolicy

      È necessario sostituirlo my_pod_security_group_id con l'ID di un gruppo di sicurezza esistente. Se non disponi di un gruppo di sicurezza esistente, devi crearne uno. Per ulteriori informazioni, consulta i gruppi EC2 di sicurezza Amazon per le istanze Linux nella Amazon EC2 User Guide. Puoi specificare da 1 a 5 gruppi di sicurezza. IDs Se si specifica più di un ID, la combinazione di tutte le regole in tutti i gruppi di sicurezza ha effetto per i Pod selezionati.

      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

      Importante

      Il gruppo o i gruppi di sicurezza specificati per i tuoi Pod devono soddisfare i seguenti criteri:

      • Devono essere esistenti. Se non esistono, allora, quando installi un Pod che corrisponde al selettore, il Pod rimane bloccato nel processo di creazione. Se descrivi il Pod, vedrai un messaggio di errore simile al seguente:. An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist

      • Devono consentire la comunicazione in entrata dal gruppo di sicurezza applicato ai tuoi nodi (forkubelet) su tutte le porte per le quali hai configurato le sonde.

      • Devono consentire la comunicazione in uscita attraverso le UDP porte 53 TCP e verso un gruppo di sicurezza assegnato ai Pod (o ai nodi su cui vengono eseguiti i Pod) che eseguono CoredNS. Il gruppo di sicurezza per i tuoi CoredNS Pods deve consentire il traffico TCP in entrata UDP e sulla porta 53 dal gruppo di sicurezza specificato.

      • Devono disporre delle regole in entrata e in uscita necessarie per comunicare con gli altri Pod con cui devono comunicare.

      • Devono avere regole che consentano ai Pod di comunicare con il piano di controllo di Kubernetes se utilizzi il gruppo di sicurezza con Fargate. Il modo più semplice per eseguire questa operazione consiste nello specificare il gruppo di sicurezza del cluster come uno dei gruppi di sicurezza.

      Le politiche dei gruppi di sicurezza si applicano solo ai Pod appena pianificati. Non influiscono sull'esecuzione dei Pod.

   2. Implementare la policy.

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

3. Implementa un'applicazione di esempio con un'etichetta che corrisponda al valore my-role per podSelector specificato nel passaggio precedente.

   1. Copia i seguenti contenuti sul dispositivo. Sostituiscilo example values con il tuo e poi esegui il comando modificato. Se lo sostituiscimy-role, assicurati che sia uguale al valore specificato per il selettore nel passaggio precedente.

      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. Implementare l'applicazione con il seguente comando. Quando distribuisci l'applicazione, il plug-in Amazon VPC CNI per Kubernetes corrisponde role all'etichetta e i gruppi di sicurezza specificati nel passaggio precedente vengono applicati al Pod.

      kubectl apply -f sample-application.yaml

4. Visualizza i Pod distribuiti con l'applicazione di esempio. Nella parte restante di questo argomento, questo terminale è indicato come TerminalA.

   kubectl get pods -n my-namespace -o wide

   Di seguito viene riportato un output di esempio:

   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>

   Nota

   Prova questi suggerimenti se qualche Pod è bloccato.

   • Se qualche Pod è bloccato nello Waiting stato, allora scappa. kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace Se visualizzi Insufficient permissions: Unable to create Elastic Network Interface., verifica di avere aggiunto la policy IAM al ruolo cluster IAM in un passaggio precedente.

   • Se alcuni Pod sono bloccati nello Pending stato, verifica che il tipo di istanza del nodo sia elencato in limits.go e che il risultato ottenuto dal numero massimo di interfacce di rete di filiale supportate dal tipo di istanza moltiplicato per il numero di nodi nel gruppo di nodi non sia già stato raggiunto. Ad esempio, una istanza m5.large supporta nove interfacce di rete di filiali. Se il gruppo di nodi dispone di cinque nodi, è possibile creare un massimo di 45 interfacce di rete di filiali per il gruppo di nodi. Il 46° Pod che tenti di implementare rimarrà in Pending stato finché non verrà eliminato un altro Pod con gruppi di sicurezza associati.

   Se si esegue kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace e si visualizza un messaggio simile al seguente, può essere ignorato in modo sicuro. Questo messaggio potrebbe apparire quando il plug-in Amazon VPC CNI per Kubernetes tenta di configurare la rete host e non riesce durante la creazione dell'interfaccia di rete. Il plug-in registra questo evento fino a quando non viene creata l'interfaccia di rete.

   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

   Non puoi superare il numero massimo di Pod che possono essere eseguiti sul tipo di istanza. Per un elenco del numero massimo di Pod che puoi eseguire su ogni tipo di istanza, consulta eni-max-pods.txt su. GitHub Quando si elimina un Pod a cui sono associati gruppi di sicurezza o si elimina il nodo su cui è in esecuzione il Pod, il controller di risorse VPC elimina l'interfaccia di rete della filiale. Se elimini un cluster con Pod utilizzando i Pod per i gruppi di sicurezza, il controller non elimina le interfacce di rete della filiale, quindi dovrai eliminarle tu stesso. Per informazioni su come eliminare le interfacce di rete, consulta Delete a network interface nella Amazon EC2 User Guide.

5. In un terminale separato, accedi a uno dei Pod. Nella parte restante di questo argomento, questo terminale è indicato come TerminalB. Sostituiscilo 5df6f7687b-4fbjm con l'ID di uno dei Pod restituiti nell'output del passaggio precedente.

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

6. Confermare il funzionamento dell'applicazione di esempio dalla shell in TerminalB.

   curl my-app

   Di seguito viene riportato un output di esempio:

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

   Hai ricevuto l'output perché tutti i Pod che eseguono l'applicazione sono associati al gruppo di sicurezza che hai creato. Tale gruppo contiene una regola che consente tutto il traffico tra tutti i Pod a cui è associato il gruppo di sicurezza. Il traffico DNS è consentito in uscita da tale gruppo di sicurezza al gruppo di sicurezza del cluster associato ai nodi. I nodi eseguono i CoredNS Pods, ai quali i tuoi Pod hanno cercato il nome.

7. Da TerminalA, rimuovere le regole del gruppo di sicurezza che consentono la comunicazione DNS dal gruppo di sicurezza al gruppo di sicurezza del cluster. Se non hai aggiunto le regole DNS al gruppo di sicurezza del cluster in un passaggio precedente, sostituiscile $my_cluster_security_group_id con l'ID del gruppo di sicurezza in cui hai creato le regole.

   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. Tentare di accedere nuovamente all'applicazione da TerminalB.

   curl my-app

   Di seguito viene riportato un output di esempio:

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

   Il tentativo fallisce perché il Pod non è più in grado di accedere ai CoredNS Pods, a cui è associato il gruppo di sicurezza del cluster. Il gruppo di sicurezza del cluster non dispone più delle regole del gruppo di sicurezza che consentono la comunicazione DNS dal gruppo di sicurezza associato al Pod.

   Se tenti di accedere all'applicazione utilizzando gli indirizzi IP restituiti per uno dei Pod in un passaggio precedente, riceverai comunque una risposta perché tutte le porte sono consentite tra i Pod a cui è associato il gruppo di sicurezza e non è richiesta la ricerca del nome.

9. Una volta terminata la sperimentazione, puoi rimuovere la politica del gruppo di sicurezza, l'applicazione e il gruppo di sicurezza di esempio che hai creato. Esegui i comandi seguenti da 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