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á.
Grupos de segurança por pod
dica
Explore as
Um grupo de segurança da AWS atua como um firewall virtual para instâncias do EC2 para controlar o tráfego de entrada e saída. Por padrão, o CNI do Amazon VPC usará grupos de segurança associados à ENI primária no nó. Mais especificamente, cada ENI associada à instância terá os mesmos grupos de segurança do EC2. Assim, cada pod em um nó compartilha os mesmos grupos de segurança do nó em que é executado.
Conforme mostrado 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 dos nós). Os grupos de segurança são muito grosseiros 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 segurança do EC2 e aplicados a cargas de trabalho com APIs nativas do Kubernetes. A imagem abaixo mostra os grupos de segurança aplicados no nível do pod e como eles simplificam a implantação de aplicativos e a arquitetura de nós. Agora, o Pod pode acessar o banco de dados do Amazon RDS.
Você pode ativar grupos de segurança para pods configurando o VPC ENABLE_POD_ENI=true CNI. Depois de ativado, o VPC Resource Controller em 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 SecurityGroupPolicy
A capacidade da interface de filial é adicional aos limites existentes de tipos de instância para endereços IP secundários. Os pods que usam grupos de segurança não são contabilizados na fórmula de pods máximos e, ao usar grupos de segurança para pods, é preciso considerar aumentar o valor de pods máximos ou aceitar executar menos pods do que o nó realmente pode suportar.
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 no máximo de pods. Consulte o guia do usuário do EKS para obter instruções sobre como alterar os pods máximos dos 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 a pods em interfaces de rede filiais 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ções da AWS.
Os grupos de segurança facilitam a restrição do acesso à rede aos recursos da VPC, como bancos de dados RDS ou instâncias do EC2. Uma vantagem clara dos grupos de segurança por pod é a oportunidade de reutilizar os recursos existentes dos grupos 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 a pods usando ENIs de filiais. Considere usar grupos de segurança para pods se você estiver transferindo aplicativos de instâncias do EC2 para o EKS e limitar 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 plugin CNI do Amazon VPC adicionou uma nova configuração chamada POD_SECURITY_GROUP_ENFORCING_MODE (“modo de imposição”). O modo de imposição controla quais grupos de segurança se aplicam ao pod e se o NAT de origem está ativado. Você pode especificar o modo de imposição como estrito ou padrão. Strict é o padrão, refletindo o comportamento anterior do VPC CNI com ENABLE_POD_ENI definido como. true
No Modo Estrito, somente os grupos de segurança ENI da filial 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 ramificada (associada ao pod) são aplicados. O tráfego de rede deve estar em conformidade com os dois grupos de segurança.
Atenção
Qualquer mudança de modo afetará apenas os pods recém-lançados. Os pods existentes usarão o modo que foi configurado quando o pod foi criado. Os clientes precisarão reciclar os pods existentes com grupos de segurança se quiserem mudar o comportamento do tráfego.
Modo de imposição: use o modo estrito para isolar o tráfego de pods e nós:
Por padrão, os grupos de segurança dos 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 filial possam ser usados.
Atenção
Quando o modo estrito está ativado, todo o tráfego de saída de um pod sai do nó e entra na rede VPC. O tráfego entre pods no mesmo nó passará pela VPC. Isso aumenta o tráfego de VPC e limita os recursos baseados em nós. O NodeLocal DNSCache não é suportado no modo estrito.
Modo de imposição: 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 configurar POD_SECURITY_GROUP_ENFORCING_MODE parastandard. Os serviços do Kubernetes oferecem suporte externo TrafficPolicy = local para apoiar a preservação do IP de origem do cliente (cluster de tipo padrão). Agora você pode executar serviços Kubernetes do tipo NodePort e LoadBalancer usar destinos de instância com um TrafficPolicy conjunto externo como Local no modo padrão. Localpreserva o IP de origem do cliente e evita um segundo salto para LoadBalancer e NodePort digite Serviços.
Implantando NodeLocal o DNSCache
Ao usar grupos de segurança para pods, configure o modo padrão para oferecer suporte a pods que usam NodeLocal DNSCache.
NodeLocal O DNSCache não é suportado no modo estrito, pois todo o tráfego da rede, até mesmo para o nó, entra na VPC.
Suporte à política de rede Kubernetes
Recomendamos usar o modo de imposição padrão ao usar a política de rede com pods que têm 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 pods dentro de um cluster, geralmente conhecido como East/West tráfego.
Identifique incompatibilidades com grupos de segurança por pod
Windows-based e instâncias 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 devem 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 RDS, considere usar SGs para pods. Embora existam mecanismos de política que permitem especificar um nome CIDR ou DNS, eles são uma opção menos ideal ao se comunicar com serviços da AWS que têm endpoints que residem em uma VPC.
Em contraste, as políticas de rede do Kubernetes
O Amazon EKS permite que você use mecanismos de política de rede, como Calico
Marque um único grupo de segurança para usar o AWS Loadbalancer Controller
Quando muitos grupos de segurança são alocados para um pod, o Amazon EKS recomenda marcar um único grupo de segurança como kubernetes.io/cluster/$name compartilhado 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 atribuído 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 o NAT para tráfego de saída
O NAT de origem está desativado para tráfego de saída de pods atribuídos a grupos de segurança. Para pods que usam grupos de segurança que exigem acesso à Internet, inicie os nós de trabalho em sub-redes privadas configuradas com um gateway ou instância NAT e habilite o SNAT externo no 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.
Verificar rescisão GracePeriodSeconds no arquivo de especificação do pod
Certifique-se de que terminationGracePeriodSeconds seja diferente de zero no arquivo de especificação do pod (padrão 30 segundos). Isso é essencial para que o Amazon VPC CNI exclua a rede Pod do node de trabalho. Quando definido como zero, o plug-in CNI não remove a rede Pod do host e a ramificação ENI não é limpa de forma eficaz.
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 executados nos nós de trabalho do EC2. 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 pods Fargate quando você não atribui explicitamente a a a um SecurityGroupPolicy pod Fargate. Para simplificar, você pode querer adicionar o grupo de segurança do cluster a um Fagate Pod, SecurityGroupPolicy caso contrário, você terá que 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 o 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 os 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 pod Fargate.
kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.fargate\.amazonaws\.com/pod-sg}{"\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 example-app. 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
