Grupos de segurança por pod

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Um grupo de segurança da AWS atua como um firewall virtual para que EC2 as instâncias controlem o tráfego de entrada e saída. Por padrão, a CNI da Amazon VPC usará grupos de segurança associados à ENI primária no nó. Mais especificamente, cada ENI associada à instância terá os mesmos grupos EC2 de segurança. Assim, cada pod em um nó compartilha os mesmos grupos de segurança do nó em que é executado.

Conforme visto na imagem abaixo, todos os pods de aplicativos que operam nos nós de trabalho terão acesso ao serviço de banco de dados do RDS (considerando que a entrada do RDS permite o grupo de segurança do nó). Os grupos de segurança são muito granulados porque se aplicam a todos os pods em execução em um nó. Os grupos de segurança para pods fornecem segmentação de rede para cargas de trabalho, o que é uma parte essencial de uma boa estratégia de defesa em profundidade.

Com grupos de segurança para pods, você pode melhorar a eficiência computacional executando aplicativos com diferentes requisitos de segurança de rede em recursos computacionais compartilhados. Vários tipos de regras de segurança, como Pod-to-Pod serviços da Pod-to-External AWS, podem ser definidos em um único local com grupos de EC2 segurança e aplicados a cargas de trabalho com o Kubernetes nativo. APIs A imagem abaixo mostra grupos de segurança aplicados no nível do pod e como eles simplificam a implantação do aplicativo e a arquitetura do nó. O Pod agora pode acessar o banco de dados do Amazon RDS.

Você pode ativar grupos de segurança para pods configurando ENABLE_POD_ENI=true para VPC CNI. Depois de ativado, o VPC Resource Controller executado no plano de controle (gerenciado pelo EKS) cria e anexa uma interface de tronco chamada “`aws-k8 “`s-trunk-eniao nó. A interface de tronco atua como uma interface de rede padrão conectada à instância. Para gerenciar interfaces de tronco, você deve adicionar a política AmazonEKSVPCResourceController gerenciada à função de cluster que acompanha seu cluster Amazon EKS.

O controlador também cria interfaces de ramificação chamadas “aws-k8s-branch-eni" e as associa à interface de tronco. Os pods recebem um grupo de segurança usando o recurso SecurityGroupPolicypersonalizado e são associados a uma interface de ramificação. Como os grupos de segurança são especificados com interfaces de rede, agora podemos programar pods que exigem grupos de segurança específicos nessas interfaces de rede adicionais. Consulte a seção do Guia do usuário do EKS sobre grupos de segurança para pods, incluindo os pré-requisitos de implantação.

A capacidade da interface de filial é adicional aos limites de tipo de instância existentes para endereços IP secundários. Os pods que usam grupos de segurança não são contabilizados na fórmula max-pods e, ao usar o grupo de segurança para pods, é necessário considerar aumentar o valor de max-pods ou aceitar a execução de menos pods do que o nó realmente suporta.

Um m5.large pode ter até 9 interfaces de rede de filiais e até 27 endereços IP secundários atribuídos às suas interfaces de rede padrão. Conforme mostrado no exemplo abaixo, o máximo de pods padrão para um m5.large é 29, e o EKS conta os pods que usam grupos de segurança em relação ao máximo de pods. Consulte o guia do usuário do EKS para obter instruções sobre como alterar os max-pods para nós.

Quando grupos de segurança para pods são usados em combinação com redes personalizadas, o grupo de segurança definido nos grupos de segurança para pods é usado em vez do grupo de segurança especificado no. ENIConfig Como resultado, quando a rede personalizada estiver ativada, avalie cuidadosamente a ordem dos grupos de segurança ao usar grupos de segurança por pod.

Recomendações

Desative o TCP Early Demux para Liveness Probe

Se você estiver usando sondas de vivacidade ou prontidão, também precisará desativar o TCP early demux, para que o kubelet possa se conectar aos pods nas interfaces de rede da filial via TCP. Isso só é necessário no modo estrito. Para fazer isso, execute o seguinte comando:

kubectl edit daemonset aws-node -n kube-system

Na initContainer seção, altere o valor de DISABLE_TCP_EARLY_DEMUX para true.

Use o Security Group For Pods para aproveitar o investimento existente em configuração da AWS.

Os grupos de segurança facilitam a restrição do acesso à rede aos recursos da VPC, como bancos de dados ou instâncias do RDS. EC2 Uma vantagem clara dos grupos de segurança por pod é a oportunidade de reutilizar os recursos existentes do grupo de segurança da AWS. Se você estiver usando grupos de segurança como um firewall de rede para limitar o acesso aos seus serviços da AWS, propomos aplicar grupos de segurança aos pods usando o branch ENIs. Considere usar grupos de segurança para pods se você estiver transferindo aplicativos de EC2 instâncias para o EKS e limite o acesso a outros serviços da AWS com grupos de segurança.

Configurar o modo de imposição do grupo de segurança do Pod

A versão 1.11 do plug-in CNI da Amazon VPC adicionou uma nova configuração chamada POD_SECURITY_GROUP_ENFORCING_MODE (“modo de aplicação”). O modo de imposição controla quais grupos de segurança se aplicam ao pod e se o NAT de origem está habilitado. Você pode especificar o modo de imposição como estrito ou padrão. Rigoroso é o padrão, refletindo o comportamento anterior da VPC CNI ENABLE_POD_ENI com definido como. true

No Modo Estrito, somente os grupos de segurança ENI da ramificação são aplicados. O NAT de origem também está desativado.

No Modo Padrão, os grupos de segurança associados à ENI primária e à ENI de ramificação (associada ao pod) são aplicados. O tráfego de rede deve estar em conformidade com os dois grupos de segurança.

Modo de aplicação: use o modo estrito para isolar o tráfego de pods e nós:

Por padrão, os grupos de segurança para pods estão definidos como “modo estrito”. Use essa configuração se precisar separar completamente o tráfego do pod do resto do tráfego do nó. No modo estrito, o NAT de origem é desativado para que os grupos de segurança de saída ENI da ramificação possam ser usados.

Modo obrigatório: use o modo Padrão nas seguintes situações

IP de origem do cliente visível para os contêineres no pod

Se você precisar manter o IP de origem do cliente visível para os contêineres no pod, considere POD_SECURITY_GROUP_ENFORCING_MODE configurar comostandard. Os serviços do Kubernetes suportam externalTrafficPolicy =local para suportar a preservação do IP de origem do cliente (tipo padrão de cluster). Agora você pode executar serviços do Kubernetes do tipo NodePort e LoadBalancer usando destinos de instância com um externalTrafficPolicy definido como Local no modo padrão. Localpreserva o IP de origem do cliente e evita um segundo salto para LoadBalancer e NodePort digite os Serviços.

Implantando NodeLocal DNSCache

Ao usar grupos de segurança para pods, configure o modo padrão para suportar pods que usam. NodeLocal DNSCache NodeLocal DNSCache melhora o desempenho do Cluster DNS executando um agente de cache de DNS nos nós do cluster como a. DaemonSet Isso ajudará os pods que têm os mais altos requisitos de DNS QPS a consultar o Kube-DNS/CoreDNS local com um cache local, o que melhorará a latência.

NodeLocal DNSCache não é suportado no modo estrito, pois todo o tráfego de rede, até mesmo para o nó, entra na VPC.

Apoiando a política de rede Kubernetes

Recomendamos usar o modo de imposição padrão ao usar a política de rede com pods que tenham grupos de segurança associados.

É altamente recomendável utilizar grupos de segurança para pods para limitar o acesso em nível de rede aos serviços da AWS que não fazem parte de um cluster. Considere políticas de rede para restringir o tráfego de rede entre os pods dentro de um cluster, geralmente conhecido como tráfego leste/oeste.

Identifique incompatibilidades com grupos de segurança por pod

Instâncias baseadas em Windows e não nitro não oferecem suporte a grupos de segurança para pods. Para utilizar grupos de segurança com pods, as instâncias precisam ser marcadas com isTrunkingEnabled. Use políticas de rede para gerenciar o acesso entre pods em vez de grupos de segurança se seus pods não dependerem de nenhum serviço da AWS dentro ou fora da sua VPC.

Use grupos de segurança por pod para controlar com eficiência o tráfego para os serviços da AWS

Se um aplicativo em execução no cluster EKS precisar se comunicar com outro recurso dentro da VPC, por exemplo, um banco de dados do RDS, considere usar SGs para pods. Embora existam mecanismos de política que permitem especificar um CIDR ou um nome DNS, eles são uma opção menos ideal para se comunicar com serviços da AWS que têm endpoints que residem em uma VPC.

Por outro lado, as políticas de rede do Kubernetes fornecem um mecanismo para controlar o tráfego de entrada e saída dentro e fora do cluster. As políticas de rede do Kubernetes devem ser consideradas se seu aplicativo tiver dependências limitadas de outros serviços da AWS. Você pode configurar políticas de rede que especifiquem regras de saída com base em intervalos de CIDR para limitar o acesso aos serviços da AWS, em oposição à semântica nativa da AWS, como. SGs Você pode usar as políticas de rede do Kubernetes para controlar o tráfego de rede entre os pods (geralmente chamado de tráfego leste/oeste) e entre os pods e serviços externos. As políticas de rede do Kubernetes são implementadas nos níveis 3 e 4 do OSI.

O Amazon EKS permite que você use mecanismos de política de rede, como Calico e Cilium. Por padrão, os mecanismos de política de rede não estão instalados. Consulte os respectivos guias de instalação para obter instruções sobre como configurar. Para obter mais informações sobre como usar a política de rede, consulte as melhores práticas de segurança do EKS. O recurso de nomes de host DNS está disponível nas versões corporativas dos mecanismos de política de rede, o que pode ser útil para controlar o tráfego entre serviços/pods do Kubernetes e recursos executados fora da AWS. Além disso, você pode considerar o suporte de nome de host DNS para serviços da AWS que não oferecem suporte a grupos de segurança por padrão.

Marque um único grupo de segurança para usar o AWS Loadbalancer Controller

Quando vários grupos de segurança são alocados em um pod, o Amazon EKS recomenda marcar um único grupo de segurança como kubernetes.io/cluster/$namecompartilhado ou próprio. A tag permite que o AWS Loadbalancer Controller atualize as regras dos grupos de segurança para rotear o tráfego para os pods. Se apenas um grupo de segurança for fornecido a um pod, a atribuição de uma tag é opcional. As permissões definidas em um grupo de segurança são aditivas, portanto, marcar um único grupo de segurança é suficiente para que o controlador do balanceador de carga localize e reconcilie as regras. Também ajuda a aderir às cotas padrão definidas pelos grupos de segurança.

Configurar NAT para tráfego de saída

O NAT de origem está desativado para tráfego de saída de pods aos quais são atribuídos grupos de segurança. Para pods que usam grupos de segurança que exigem acesso aos nós de trabalho de inicialização da Internet em sub-redes privadas configuradas com um gateway ou instância NAT e habilite o SNAT externo na CNI.

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

Implante pods com grupos de segurança em sub-redes privadas

Os pods atribuídos a grupos de segurança devem ser executados em nós implantados em sub-redes privadas. Observe que os pods com grupos de segurança atribuídos implantados em sub-redes públicas não conseguirão acessar a Internet.

Verifique os terminationGracePeriodsegundos no arquivo de especificação do pod

Certifique-se de que terminationGracePeriodSeconds seja diferente de zero no arquivo de especificação do seu pod (30 segundos padrão). Isso é essencial para que o Amazon VPC CNI exclua a rede Pod do nó de trabalho. Quando definido como zero, o plug-in CNI não remove a rede Pod do host e a ENI da ramificação não é efetivamente limpa.

Usando grupos de segurança para pods com o Fargate

Os grupos de segurança para pods executados no Fargate funcionam de forma muito semelhante aos pods EC2 executados em nós de trabalho. Por exemplo, você precisa criar o grupo de segurança antes de referenciá-lo no que SecurityGroupPolicy você associa ao seu Fargate Pod. Por padrão, o grupo de segurança do cluster é atribuído a todos os Fargate Pods quando você não atribui explicitamente um a um Fargate Pod. SecurityGroupPolicy Para simplificar, talvez você queira adicionar o grupo de segurança do cluster ao Fagate Pod, SecurityGroupPolicy caso contrário, você precisará adicionar as regras mínimas do grupo de segurança ao seu grupo de segurança. Você pode encontrar o grupo de segurança do cluster usando a 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

As regras mínimas do grupo de segurança estão listadas aqui. Essas regras permitem que os Fargate Pods se comuniquem com serviços no cluster, como kube-apiserver, kubelet e CoreDNS. Você também precisa adicionar regras para permitir conexões de entrada e saída de e para seu Fargate Pod. Isso permitirá que seu pod se comunique com outros pods ou recursos em sua VPC. Além disso, você precisa incluir regras para que o Fargate extraia imagens de contêineres do Amazon ECR ou de outros registros de contêineres, como. DockerHub Para obter mais informações, consulte Intervalos de endereços IP da AWS na Referência geral da AWS.

Você pode usar os comandos abaixo para encontrar os grupos de segurança aplicados a um Fargate Pod.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Anote o comando eNIID acima.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

Os pods Fargate existentes devem ser excluídos e recriados para que novos grupos de segurança sejam aplicados. Por exemplo, o comando a seguir inicia a implantação do aplicativo de exemplo. Para atualizar pods específicos, você pode alterar o namespace e o nome da implantação no comando abaixo.

kubectl rollout restart -n example-ns deployment example-pod