Usar uma política para grupos de segurança em um Pod do Amazon EKS

Para usar grupos de segurança em Pods, é necessário ter um grupo de segurança existente. As etapas seguintes mostram como utilizar a política de grupo de segurança para um Pod: A menos que indicado de outra forma, conclua todas as etapas no mesmo terminal, pois são utilizadas nas etapas a seguir variáveis que não persistem entre terminais.

Se você tiver um Pod com instâncias do Amazon EC2, deverá configurar o plug-in antes de usar esse procedimento. Para ter mais informações, consulte Configurar o Amazon VPC CNI plugin for Kubernetes de grupos de segurança para Pods do Amazon EKS.

Crie um namespace do Kubernetes no qual implantar recursos. Você pode substituir my-namespace pelo nome de um namespace que deseje usar.
```
kubectl create namespace my-namespace
```
Implante uma SecurityGroupPolicy do Amazon EKS no cluster.
1. Copie o conteúdo a seguir para o seu dispositivo. Você pode substituir podSelector por serviceAccountSelector se preferir selecionar Pods com base em rótulos de conta de serviço. É preciso especificar um seletor ou outro. Uma podSelector vazia (exemplo: podSelector: {}) seleciona todos os Pods no namespace. Você pode alterar my-role para o nome do seu perfil. Uma serviceAccountSelector vazia seleciona todas as contas de serviço no namespace. Você pode substituir my-security-group-policy por um nome para a SecurityGroupPolicy e my-namespace pelo namespace no qual você deseja criar a SecurityGroupPolicy.
  
  Você deve substituir my_pod_security_group_id pelo ID de um grupo de segurança existente. Se você ainda não tiver um grupo de segurança, deverá criar um. Para obter mais informações, consulte Grupos de segurança do Amazon EC2 para instâncias do Linux no Guia do usuário do Amazon EC2. Você deve especificar de 1 a 5 IDs de grupo de segurança. Se você especificar mais de um ID, a combinação de todas as regras em todos os grupos de segurança será efetiva para os Pods selecionados.
```
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
  O grupo ou grupos de segurança que você especificar para o Pods deve atender aos seguintes critérios:
  
  Eles devem existir. Se eles não existirem, então, quando você implantar um Pod que corresponda ao seletor, o Pod permanecerá preso no processo de criação. Se você descrever o Pod, verá uma mensagem de erro semelhante à seguinte: An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist.
  
  Eles devem permitir comunicação de entrada do grupo de segurança aplicado aos nós (para kubelet) por todas as portas para as quais você configurou sondagens.
  
  Eles devem permitir comunicação de saída pelas portas TCP e UDP 53 com um grupo de segurança atribuído aos Pods (ou nós em que os Pods são executados) sendo executados no CoreDNS. O grupo de segurança dos Pods CoreDNS devem permitir tráfego de entrada na porta TCP e UDP 53 do grupo de segurança que você especificar.
  
  Eles devem ter regras de entrada e saída necessárias para comunicação com outros Pods com os quais precisam se comunicar.
  
  Eles devem ter regras que permitam que os Pods se comuniquem com o ambiente de gerenciamento do Kubernetes se você estiver usando esse grupo de segurança com o Fargate. A maneira mais fácil de fazer isso é especificar o grupo de segurança de cluster como um dos grupos de segurança.
  
  As políticas de grupo de segurança só se aplicam a pods recém-agendados Pods. Eles não afetam os Pods em execução.
2. Implante a política.
```
kubectl apply -f my-security-group-policy.yaml
```

Implante uma aplicação de amostra com um rótulo que corresponda ao valor my-role para podSelector que você especificou em uma etapa anterior.

Copie o conteúdo a seguir para o seu dispositivo. Substitua os exemplos de valor pelos seus próprios e execute o comando modificado. Se você substituir my-role, certifique-se de que seja o mesmo valor que você especificou para o seletor em uma etapa anterior.


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

Implante a aplicação com o comando a seguir. Quando você implanta a aplicação, Amazon VPC CNI plugin for Kubernetes corresponde à etiqueta role e os grupos de segurança especificados na etapa anterior são aplicados ao Pod.
```
kubectl apply -f sample-application.yaml
```

Visualizar os Pods Implantados com a aplicação de amostra. Para o restante do tópico, esse terminal é indicado como TerminalA.
```
kubectl get pods -n my-namespace -o wide
```
Veja um exemplo de saída abaixo.
```
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
Experimente essas dicas se houver Pods presos.
- Se houver Pods travados no estado Waiting, execute kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace. Se você observar Insufficient permissions: Unable to create Elastic Network Interface., confirme se adicionou a política do IAM à função de cluster do IAM em uma etapa anterior.
- Se houver Pods presos no estado Pending, confirme se o tipo de instância do nó está listado em limits.go e se o número máximo de interfaces de rede de ramificação aceito pelo o tipo de instância multiplicado pelo número de nós do grupo de nós ainda não foi atingido. Por exemplo, um m5.large suporta nove interfaces de rede de ramificação. Se o grupo de nós tiver cinco nós, um máximo de 45 interfaces de rede de ramificação poderá ser criado para o grupo de nós. O 46º Pod que você tentar implantar ficará no estado Pending até que outro Pod que tenha grupos de segurança associados seja excluído.
Se você executar kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace e ver uma mensagem semelhante à seguinte, ela pode ser ignorada com segurança: Essa mensagem pode aparecer quando o Amazon VPC CNI plugin for Kubernetes tenta configurar a rede de host e falha enquanto a interface de rede está sendo criada. O plugin CNI registra esse evento até que a interface de rede seja criada.
```
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
```
Você não pode exceder o número máximo de Pods que podem ser executados no tipo de instância. Para obter uma lista do número máximo de Pods que você pode executar em cada tipo de instância, consulte eni-max-pods.txt no GitHub. Quando você exclui um Pod que tenha grupos de segurança associados ou exclui o nó em que o Pod está sendo executado, o controlador de recursos da VPC exclui a interface de rede da ramificação. Se você excluir um cluster com Pods usando Pods para grupos de segurança, o controlador não excluirá as interfaces de rede da ramificação, portanto, você precisará excluí-las você mesmo. Para obter mais informações sobre como excluir interfaces de rede, consulte Interfaces de rede elásticas no Guia do usuário do Amazon EC2.
Em um terminal à parte, faça shell em um dos Pods. Para o restante do tópico, esse terminal é indicado como TerminalB. Substitua 5df6f7687b-4fbjm pelo ID de um dos Pods retornados em sua saída da etapa anterior.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
No shell em TerminalB, confirme se a aplicação de amostra funciona.
```
curl my-app
```
Veja um exemplo de saída abaixo.
```
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]
```
Você recebeu a saída porque todos Pods que executam a aplicação estão associados ao grupo de segurança que você criou. Esse grupo contém uma regra que permite todo o tráfego entre todos Pods aos quais o grupo de segurança está associado. O tráfego DNS pode sair desse grupo de segurança para o grupo de segurança do cluster, que está associado aos seus nós. Os nós estão executando os Pods CoreDNS, para os quais seus Pods fizeram uma pesquisa de nome.
No TerminalA, remova as regras de grupo de segurança que permitem a comunicação DNS com o grupo de segurança de cluster do grupo de segurança. Se você não tiver adicionado as regras de DNS ao grupo de segurança de cluster em uma etapa anterior, substitua $my_cluster_security_group_id pelo ID do grupo de segurança no qual as regras foram criadas.
```
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
```
No TerminalB, tente acessar a aplicação novamente.
```
curl my-app
```
Veja um exemplo de saída abaixo.
```
curl: (6) Could not resolve host: my-app
```
A tentativa falha porque o Pod não é mais capaz de acessar os Pods CoreDNS, que têm o grupo de segurança de cluster associado. O grupo de segurança do cluster não tem mais as regras de grupo de segurança que permitem a comunicação DNS do grupo de segurança associado ao Pod.

Se você tentar acessar a aplicação utilizando os endereços IP retornados para um dos Pods em uma etapa anterior, ainda receberá uma resposta, pois todas as portas são permitidas entre Pods que têm o grupo de segurança associado a eles, e uma pesquisa de nome não é necessária.

Quando você terminar os testes, poderá remover o exemplo de política de grupo de segurança, a aplicação e o grupo de segurança criados. Execute os comandos a seguir no 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

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Configurar o Amazon VPC CNI plugin for Kubernetes de grupos de segurança para Pods do Amazon EKS

Anexar várias interfaces de rede para Pods com o Multus

Usar uma política para grupos de segurança em um Pod do Amazon EKS

Importante

nota