**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Considerações de segurança sobre o Amazon Elastic Kubernetes Service
A seguir estão algumas considerações sobre a segurança da nuvem, pois elas afetam o Amazon EKS.
**Topics**
+ [Segurança da infraestrutura no Amazon EKS](infrastructure-security.md)
+ [Entenda a resiliência nos clusters do Amazon EKS](disaster-recovery-resiliency.md)
+ [Prevenção do problema de confused deputy entre serviços no Amazon EKS](cross-service-confused-deputy-prevention.md)
# Segurança da infraestrutura no Amazon EKS
Como um serviço gerenciado, o Amazon Elastic Kubernetes Service é protegido pela segurança de rede global da AWS. Para obter informações sobre serviços de segurança da AWS e como a AWS protege a infraestrutura, consulte [Segurança na Nuvem AWS](https://aws.amazon.com/security/). Para projetar seu ambiente da AWS usando as práticas recomendadas de segurança da infraestrutura, consulte [Proteção de Infraestrutura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) em *Pilar de Segurança: AWS Estrutura bem arquitetada*.
Você usa chamadas à API publicadas pela AWS para acessar o Amazon EKS por meio da rede. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Ou você pode usar o [serviço de token de segurança da AWS (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) para gerar credenciais de segurança temporárias para assinar solicitações.
Ao criar um cluster do Amazon EKS, você especifica as sub-redes da VPC para uso do cluster. O Amazon EKS exige sub-redes em, pelo menos, duas zonas de disponibilidade. Recomendamos uma VPC com sub-redes públicas e privadas a fim de que o Kubernetes possa criar balanceadores de carga públicos nas sub-redes públicas que fazem o balanceamento de carga do tráfego para pods em execução nos nós localizados em sub-redes privadas.
Para obter mais informações sobre as considerações da VPC, consulte [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md).
Se você criar os grupos de nós e VPCs com os modelos do AWS CloudFormation fornecidos no passo a passo Introdução ao [Amazon EKS](getting-started.md), os grupos de segurança do ambiente de gerenciamento e dos nós serão configurados com nossas definições recomendadas.
Para obter mais informações sobre considerações de grupos de segurança, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md).
Quando você cria um cluster, o Amazon EKS cria um endpoint para o servidor gerenciado de API do Kubernetes usado para se comunicar com o cluster (usando as ferramentas de gerenciamento do Kubernetes, como `kubectl`). Por padrão, esse endpoint do servidor de API é público para a internet, e o acesso ao servidor de API é protegido usando uma combinação do AWS Identity and Access Management (IAM) e do [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) nativo do Kubernetes.
Você pode habilitar o acesso privado ao servidor de API do Kubernetes para que todas as comunicações entre os nós e o servidor de API fiquem na VPC. Você pode limitar os endereços IP que podem acessar o servidor de API pela Internet ou desativar completamente o acesso à Internet para o servidor de API.
Para obter mais informações sobre como modificar o acesso do endpoint do cluster, consulte [Modificar o acesso ao endpoint do cluster](cluster-endpoint.md#modify-endpoint-access):
Você pode implementar *políticas de rede* do Kubernetes com a CNI da Amazon VPC ou com ferramentas de terceiros, como o [Project Calico](https://docs.tigera.io/calico/latest/about/). Para obter mais informações sobre o uso do Amazon VPC CNI para políticas de rede, consulte [Limitar o tráfego do pod com políticas de rede do Kubernetes](cni-network-policy.md). O Project Calico é um projeto de código-fonte aberto de terceiros. Para obter mais informações, consulte a [documentação do Project Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Acessar o Amazon EKS usando o AWS PrivateLink
Você pode usar o AWS PrivateLink para criar uma conexão privada entre seu VPC e o Amazon Elastic Kubernetes Service. Você pode acessar o Amazon EKS como se ele estivesse em sua VPC, sem o uso de um gateway de Internet, dispositivo NAT, conexão VPN ou conexão AWS Direct Connect. As instâncias na VPC não precisam de endereços IP públicos para acessar o Amazon EKS.
Você estabelece essa conexão privada criando um endpoint de interface alimentado pelo AWS PrivateLink. Criaremos um endpoint de interface de rede em cada sub-rede que você habilitar para o endpoint de interface. Essas são interfaces de rede gerenciadas pelo solicitante que servem como ponto de entrada para o tráfego destinado ao Amazon EKS.
Para obter mais informações, consulte [Acessar serviços da AWS por meio do AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) no *Guia do AWS PrivateLink*.
## Antes de começar
Antes de começar, certifique-se de ter realizado as seguintes tarefas:
+ Revise [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) no *Guia do AWS PrivateLink*
## Considerações
+ **Suporte e limitações**: os endpoints da interface do Amazon EKS permitem acesso seguro a todas as ações da API do Amazon EKS da sua VPC, mas vêm com limitações específicas: eles não oferecem suporte ao acesso às APIs do Kubernetes, pois estas têm um endpoint privado separado. Você não pode configurar o Amazon EKS para ser acessível somente por meio do endpoint da interface.
+ **Preços**: o uso de endpoints de interface para o Amazon EKS gera cobranças padrão do AWS PrivateLink: cobranças por hora para cada endpoint provisionado em cada zona de disponibilidade e cobranças de processamento de dados do tráfego pelo endpoint. Para saber mais, consulte [Preço do AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
+ **Segurança e controle de acesso**: recomendamos aprimorar a segurança e controlar o acesso com estas configurações adicionais: use políticas de endpoints da VPC para controlar o acesso ao Amazon EKS por meio do endpoint da interface, associe grupos de segurança a interfaces de rede de endpoints para gerenciar tráfego e use logs de fluxo da VPC para capturar e monitorar o tráfego IP de e para os endpoints da interface, com logs publicáveis no Amazon CloudWatch ou no Amazon S3. Para saber mais, consulte [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) e [Como registrar tráfego IP em log com logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Opções de conectividade**: os endpoints de interface oferecem opções flexíveis de conectividade usando **acesso on-premises** (conecte seu data center on-premises a uma VPC com o endpoint de interface usando o AWS Direct Connect ou o AWS Site-to-Site VPN) ou via **conectividade entre VPCs** (use o AWS Transit Gateway ou o emparelhamento da VPC para conectar outras VPCs à VPC com o endpoint de interface, mantendo o tráfego na rede da AWS).
+ **Suporte para a versão IP**: endpoints criados antes de agosto de 2024 são compatíveis somente com o IPv4 usando eks.region.amazonaws.com. Novos endpoints criados após agosto de 2024 são compatíveis com o IPv4 e IPv6 de pilha dupla (por exemplo, eks.region.amazonaws.com, eks.region.api.aws).
+ **Disponibilidade regional**: o AWS PrivateLink para a API do EKS não está disponível nas regiões Ásia-Pacífico (Malásia) (ap-southeast-5), Ásia-Pacífico (Tailândia) (ap-southeast-7), México (Centro) (mx-central-1) e Ásia-Pacífico (Taipei) (ap-east-2). O suporte do AWS PrivateLink para o eks-auth (Identidade de Pods do EKS) está disponível na região Ásia-Pacífico (Malásia) (ap-southeast-5).
## Criar um endpoint de interface de VPC para o Amazon EKS
Você pode criar um endpoint de interface para o Amazon EKS usando o console do Amazon VPC ou a interface de linha de comando AWS (AWS CLI). Para obter mais informações, consulte [Criar um endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) no * AWS PrivateLink Guide*.
Crie um endpoint de interface para o Amazon EKS usando os seguintes nomes de serviço:
### API do EKS
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (para endpoints compatíveis com FIPS)
### API de autenticação do EKS (Identidade de Pods do EKS)
+ com.amazonaws.region-code.eks-auth
## Recurso de DNS privado para endpoints de interface do Amazon EKS
O recurso de DNS privado, habilitado por padrão para endpoints de interface do Amazon EKS e outros serviços da AWS, viabiliza solicitações de API seguras e privadas usando nomes de DNS regionais padrão. Esse recurso garante que as chamadas de API sejam roteadas pelo endpoint de interface pela rede privada da AWS, aprimorando a segurança e a performance.
O recurso de DNS privado é ativado automaticamente quando você cria um endpoint de interface para o Amazon EKS ou outros serviços da AWS. Para habilitar, você precisa configurar sua VPC corretamente definindo atributos específicos:
+ **enableDnsHostnames**: permite que as instâncias dentro da VPC tenham nomes de host DNS.
+ **enableDnsSupport**: habilita a resolução de DNS em toda a VPC.
Para obter instruções passo a passo para verificar ou modificar essas configurações, consulte [Visualizar e atualizar atributos de DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### Nomes de DNS e tipos de endereço IP
Com o recurso de DNS privado habilitado, você pode usar nomes DNS específicos para se conectar ao Amazon EKS, e essas opções evoluem com o tempo:
+ **eks.region.amazonaws.com**: o nome DNS tradicional, resolvido apenas para endereços IPv4 antes de agosto de 2024. Para endpoints existentes atualizados para pilha dupla, esse nome resolve para endereços IPv4 e IPv6.
+ **eks.region.api.aws**: disponível para novos endpoints criados após agosto de 2024, esse nome DNS de pilha dupla resolve para endereços IPv4 e IPv6.
Depois de agosto de 2024, os novos endpoints de interface vêm com dois nomes DNS, e você pode optar pelo tipo de endereço IP de pilha dupla. Para endpoints existentes, a atualização para pilha dupla modifica **eks.region.amazonaws.com** para ser compatível tanto com IPv4 quanto com IPv6.
### Como usar o recurso DNS privado
Depois de configurado, o recurso de DNS privado pode ser integrado aos seus fluxos de trabalho, oferecendo os seguintes recursos:
+ **Solicitações de API**: use os nomes DNS regionais padrão, `eks.region.amazonaws.com` ou `eks.region.api.aws`, com base na configuração do seu endpoint para fazer solicitações de API para o Amazon EKS.
+ **Compatibilidade de aplicações**: suas aplicações existentes que chamam as APIs do EKS não precisam de alterações para aproveitar esse recurso.
+ ** AWS CLI com pilha dupla**: para usar os endpoints de pilha dupla com a AWS CLI, consulte a configuração de [endpoints de pilha dupla e FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) no *Guia de referência de ferramentas e SDKs da AWS*.
+ **Roteamento automático**: qualquer chamada para o endpoint de serviço padrão do Amazon EKS é automaticamente direcionada pelo endpoint de interface, garantindo conectividade privada e segura.
# Entenda a resiliência nos clusters do Amazon EKS
A infraestrutura global da AWS é criada com base em regiões da AWS e zonas de disponibilidade. As regiões da AWS As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, as quais são conectadas com baixa latência, alto throughput e redes altamente redundantes. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
O Amazon EKS executa e escala planos de controle do Kubernetes em várias zonas de disponibilidade da AWS para garantir a alta disponibilidade. O Amazon EKS escala automaticamente instâncias do ambiente de gerenciamento baseadas em carga, detecta e substitui instâncias não íntegras do ambiente de gerenciamento e aplica patches automaticamente ao ambiente de gerenciamento. Depois de iniciar uma atualização de versão, o Amazon EKS atualiza seu ambiente de gerenciamento para você, mantendo a alta disponibilidade do ambiente de gerenciamento durante a atualização.
Esse ambiente de gerenciamento consiste em pelo menos duas instâncias de servidor de API e três instâncias de `etcd` que são executadas em três zonas de disponibilidade em uma região AWS. Amazon EKS:
+ Monitora ativamente a carga nas instâncias do plano de controle e as escala automaticamente para garantir alta performance.
+ Detecta e substitui automaticamente instâncias não íntegras do plano de controle, reiniciando-as nas zonas de disponibilidade da região da AWS, conforme a necessidade.
+ Aproveita a arquitetura de Regiões da AWS a fim de manter alta disponibilidade. Por isso, o Amazon EKS é capaz de oferecer um [SLA para disponibilidade do endpoint do servidor de API](https://aws.amazon.com/eks/sla).
Para obter mais informações sobre regiões e zonas de disponibilidade da AWS, consulte [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
# Prevenção do problema de confused deputy entre serviços no Amazon EKS
O problema de confused deputy é uma questão de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executar a ação. Na AWS, a personificação entre serviços pode resultar no problema do ‘confused deputy’. A personificação entre serviços pode ocorrer quando um serviço (o *serviço de chamada*) chama outro serviço (o *serviço chamado*). O serviço de chamada pode ser manipulado a usar suas permissões para atuar nos recursos de outro cliente de modo a não ter permissão de acesso. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta.
Recomendamos o uso das chaves de contexto de condição global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) em políticas de recursos para limitar as permissões que o Amazon Elastic Kubernetes Service (Amazon EKS) concede para o recurso a outro serviço.
`aws:SourceArn`
Use `aws:SourceArn` se quiser associar apenas um recurso ao acesso entre serviços.
`aws:SourceAccount`
Use `aws:SourceAccount` se quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços.
A maneira mais eficaz de se proteger contra o problema do confused deputy é usar a chave de contexto de condição global `aws:SourceArn` com o ARN completo do recurso. Se você não souber o ARN completo do recurso ou especificar vários recursos, use a chave de condição de contexto global `aws:SourceArn` com caracteres curinga (\$1) para as partes desconhecidas do ARN. Por exemplo, ` arn:aws::*:<123456789012>:*`.
Se o valor do `aws:SourceArn` não contiver o ID da conta, como um ARN de bucket do Amazon S3, você deverá usar ambos, a `aws:SourceAccount` e o `aws:SourceArn` para limitar as permissões.
## Prevenção contra o problema confused deputy entre serviços no perfil do cluster do Amazon EKS
É necessário um perfil do IAM de cluster do Amazon EKS para cada cluster. Os clusters do Kubernetes gerenciados pelo Amazon EKS usam esse perfil para gerenciar nós, e o [provedor de nuvem legado](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) usa esse perfil para criar balanceadores de carga com o Elastic Load Balancing para serviços. Essas ações de cluster só podem afetar a mesma conta; portanto, recomendamos que você limite cada perfil de cluster a esse cluster e a essa conta. Essa é uma aplicação específica da AWS recomendação de seguir o *princípio do privilégio mínimo* em sua conta.
**Formato do ARN de origem**
O valor `aws:SourceArn` deve ser o ARN de um cluster do EKS no formato ` arn:aws:eks:region:account:cluster/cluster-name `. Por exemplo, ., ` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster` .
**Formato de política de confiança para perfis de cluster do EKS**
O exemplo a seguir mostra como é possível usar as chaves de contexto de condição global `aws:SourceArn` e `aws:SourceAccount` no Amazon EKS, a fim de evitar o problema de confused deputy.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```