**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. # Segurança no Amazon EKS A segurança da nuvem na AWS é a nossa maior prioridade. Como cliente da AWS, você contará com um data center e uma arquitetura de rede criados para atender aos requisitos das organizações com as maiores exigências de segurança. A segurança é uma responsabilidade compartilhada entre a AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isto como segurança *da* nuvem e segurança *na* nuvem: + **Segurança da nuvem** – a AWS é responsável por proteger a infraestrutura que executa os serviços da AWS na Nuvem AWS. Para o Amazon EKS, a AWS é responsável pelo plano de controle do Kubernetes, que inclui os nós do plano de controle e o banco de dados `etcd`. Auditores de terceiros testam e verificam regularmente a eficácia da nossa segurança como parte dos [programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Para saber mais sobre os programas de conformidade que se aplicam ao Amazon EKS, consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). + **Segurança na nuvem**: sua responsabilidade inclui as seguintes áreas: + A configuração de segurança do plano de dados, incluindo a configuração dos grupos de segurança que permitem que o tráfego passe do plano de controle do Amazon EKS para a VPC do cliente + A configuração dos nós e dos contêineres + O sistema operacional do nó (incluindo atualizações e patches de segurança) + Outros softwares de aplicações associadas: + Configurar e gerenciar os controles de rede, como regras de firewall + Administrar o gerenciamento de acesso e identidade no nível da plataforma, com ou além do IAM. + A confidencialidade dos dados, os requisitos da sua empresa e as leis e regulamentos aplicáveis O Amazon EKS é certificado por vários programas de conformidade para aplicações regulamentadas e confidenciais. O Amazon EKS está em conformidade com [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/), e é um serviço qualificado para [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). Para obter mais informações, consulte [Saiba como o controle de acesso funciona no Amazon EKS](cluster-auth.md). Esta documentação ajuda a entender como aplicar o modelo de responsabilidade compartilhada ao usar o Amazon EKS. Os tópicos a seguir mostram como configurar o Amazon EKS para atender aos seus objetivos de segurança e de conformidade. Saiba também como usar outros serviços da AWS que ajudam você a monitorar e proteger os recursos do Amazon EKS. **nota** Os contêineres Linux são compostos de grupos de controle (cgroups) e namespaces que ajudam a limitar o que um contêiner pode acessar, mas todos os contêineres compartilham o mesmo kernel Linux que a instância host do Amazon EC2. Executar um contêiner como usuário raiz (UID 0) ou conceder acesso a um contêiner aos recursos do host ou namespaces, como a rede host ou o namespace PID do host são fortemente desencorajados, pois isso reduz a eficácia do isolamento fornecido pelos contêineres. **Topics** + [Proteger os clusters do Amazon EKS com as práticas recomendadas](security-best-practices.md) + [Analisar vulnerabilidades no Amazon EKS](configuration-vulnerability-analysis.md) + [Validação de conformidade para clusters do Amazon EKS](compliance.md) + [Considerações de segurança sobre o Amazon Elastic Kubernetes Service](security-eks.md) + [Considerações de segurança para o Kubernetes](security-k8s.md) + [Considerações de segurança sobre o Modo Automático do Amazon EKS](auto-security.md) + [Considerações sobre segurança para funcionalidades do EKS](capabilities-security.md) + [Identity and Access Management para o Amazon EKS](security-iam.md) # Proteger os clusters do Amazon EKS com as práticas recomendadas As práticas recomendadas de segurança do Amazon EKS estão em [Práticas recomendadas de segurança](https://docs.aws.amazon.com/eks/latest/best-practices/security.html), no *Guia de práticas recomendadas do Amazon EKS*. # Analisar vulnerabilidades no Amazon EKS A segurança é uma consideração essencial para configurar e manter clusters e aplicações do Kubernetes. A seguir são listados recursos para você analisar a configuração de segurança dos seus clusters do EKS, recursos para verificar vulnerabilidades e integrações com serviços da AWS que podem fazer essa análise para você. ## Referência do Center for Internet Security (CIS) para Amazon EKS O [Kubernetes Benchmark do Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/) fornece orientação para as configurações de segurança do Amazon EKS. O parâmetro de referência: + É aplicável aos nós do Amazon EC2 (gerenciados e autogerenciados) nos quais você é responsável pelas configurações de segurança dos componentes do Kubernetes. + Fornece uma maneira padrão aprovada pela comunidade de garantir que você configurou seu cluster e nós do Kubernetes com segurança ao usar o Amazon EKS. + Consiste em quatro seções: configuração de log de plano de controle, configurações de segurança do nó, políticas e serviços gerenciados. + Oferece suporte a todas as versões do Kubernetes atualmente disponíveis no Amazon EKS e podem ser executadas usando [kube-bench](https://github.com/aquasecurity/kube-bench), uma ferramenta de código aberto padrão para verificar a configuração usando o benchmark do CIS em clusters do Kubernetes. Para saber mais, consulte[Apresentando o CIS Amazon EKS Benchmark](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark). Para obter um pipeline `aws-sample` automatizado para atualizar o grupo de nós com uma AMI de referência da CIS, consulte [EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates). ## Versões da plataforma do Amazon EKS As *versões da plataforma* do Amazon EKS representam os recursos do ambiente de gerenciamento do cluster, incluindo quais sinalizadores do servidor de API do Kubernetes estão habilitados e a versão de patch atual do Kubernetes. Novos clusters são implantados com a versão mais recente da plataforma. Para obter detalhes, consulte as [versões da plataforma do EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html). Você pode [atualizar um cluster do Amazon EKS](update-cluster.md) para versões mais recentes do Kubernetes. Conforme novas versões do Kubernetes são disponibilizadas no Amazon EKS, recomendamos que você atualize proativamente seus clusters para usarem a versão mais recente disponível. Para obter mais informações sobre as versões do Kubernetes no EKS, consulte [Versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). ## Lista de vulnerabilidades do sistema operacional ### Lista de vulnerabilidades do AL2023 Rastreie eventos de segurança ou privacidade para o Amazon Linux 2023 no [Centro de segurança do Amazon Linux](https://alas.aws.amazon.com/alas2023.html) ou assine o [feed RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associado. Eventos de segurança e privacidade incluem uma visão geral do problema afetado, pacotes e instruções para atualizar suas instâncias para corrigir o problema. ### Lista de vulnerabilidades do Amazon Linux 2 Rastreie eventos de segurança ou privacidade para o Amazon Linux 2 no [Centro de segurança do Amazon Linux](https://alas.aws.amazon.com/alas2.html) ou assine o [feed RSS](https://alas.aws.amazon.com/AL2/alas.rss) associado. Eventos de segurança e privacidade incluem uma visão geral do problema afetado, pacotes e instruções para atualizar suas instâncias para corrigir o problema. ## Detecção de nós com o Amazon Inspector É possível usar o [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) para verificar a acessibilidade de rede não intencional dos nós e as vulnerabilidades nessas instâncias do Amazon EC2. ## Detecção de clusters e nós com o Amazon GuardDuty O Amazon GuardDuty é um serviço de detecção de ameaças que ajuda a proteger contas, contêineres, workloads e dados no ambiente da AWS. Entre outros recursos, o GuardDuty oferece os dois recursos a seguir que detectam possíveis ameaças aos seus clusters do EKS: *Proteção do EKS* e *Monitoramento de runtime.* Para obter mais informações, consulte [Detectar ameaças com o Amazon GuardDuty](integration-guardduty.md). # Validação de conformidade para clusters do Amazon EKS Para saber se um serviço AWS está dentro do escopo de programas de conformidade específicos, consulte [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) e escolha o programa de conformidade do seu interesse. Para obter informações gerais, consulte [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Você pode fazer download de relatórios de auditoria de terceiros usando o AWS Artifact. Para obter mais informações, consulte [Fazer o download de Relatórios no AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Sua responsabilidade com relação à conformidade ao usar os serviços da AWS é determinada pela confidencialidade dos dados, pelos objetivos de conformidade da empresa e pelos regulamentos e leis aplicáveis. A AWS fornece os seguintes recursos para ajudar com a conformidade: + [Governança e conformidade de segurança](https://aws.amazon.com/solutions/security/security-compliance-governance/): esses guias de implementação de solução abordam considerações sobre a arquitetura e fornecem etapas para implantar recursos de segurança e conformidade. + [Referência de serviços qualificados para HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/): lista os serviços qualificados para HIPAA. Nem todos os serviços da AWS são qualificados para a HIPAA. + [Recursos de compatibilidade da AWS](https://aws.amazon.com/compliance/resources/) – Esta coleção de guias e pastas de trabalho pode ser aplicada ao seu setor e local. + [Guias de conformidade do cliente da AWS](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf): entenda o modelo de responsabilidade compartilhada sob a ótica da conformidade. Os guias resumem as práticas recomendadas para proteger os serviços do AWS e mapeiam as orientações para os controles de segurança em várias estruturas (incluindo National Institute of Standards and Technology (NIST), Payment Card Industry Security Standards Council (PCI) e International Organization for Standardization (ISO)). + [Avaliação de recursos com regras](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) no * AWS Config Developer Guide* - O serviço AWS Config avalia a conformidade das configurações do seus recursos com as práticas internas, as diretrizes do setor e as normas. + [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) - Esse serviço AWS fornece uma visão abrangente do seu estado de segurança em AWS. O Security Hub usa controles de segurança para avaliar os recursos da AWS e verificar a conformidade com os padrões e as práticas recomendadas do setor de segurança. Para obter uma lista dos serviços e controles aceitos, consulte a [Referência de controles do Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html). + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) - Este serviço AWS detecta possíveis ameaças às suas contas AWS, workloads, contêineres e dados, monitorando seu ambiente em busca de atividades suspeitas e mal-intencionadas. O GuardDuty pode ajudar você a atender a diversos requisitos de conformidade, como o PCI DSS, com o cumprimento dos requisitos de detecção de intrusões requeridos por determinadas estruturas de conformidade. + [Audit Manager da AWS](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html): esse serviço da AWS ajuda a auditar continuamente o uso da AWS para simplificar a forma como você gerencia os riscos e a conformidade com regulamentos e padrões do setor. # 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" } } } ] } ``` # Considerações de segurança para o Kubernetes Veja abaixo algumas considerações sobre a segurança na nuvem, pois elas afetam o Kubernetes nos clusters do Amazon EKS. Para uma análise mais aprofundada dos controles e práticas de segurança no Kubernetes, consulte [Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) na documentação do Kubernetes. **Topics** + [Proteger workloads com certificados do Kubernetes](cert-signing.md) + [Entender as funções e os usuários do RBAC criados pelo Amazon EKS](default-roles-users.md) + [Criptografar segredos do Kubernetes com o KMS em clusters existentes](enable-kms.md) + [Uso dos segredos do AWS Secrets Manager com os pods do Amazon EKS](manage-secrets.md) + [Criptografia envelopada padrão para todos os dados de API do Kubernetes](envelope-encryption.md) # Proteger workloads com certificados do Kubernetes A API Certificates do Kubernetes automatiza o provisionamento de credenciais [X.509](https://www.itu.int/rec/T-REC-X.509). Ela tem uma interface de linha de comandos para os clientes de APIs do Kubernetes solicitarem e receberem [certificados X.509](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) de uma autoridade de certificação (CA). Você pode usa o recurso `CertificateSigningRequest` (CSR) para solicitar que um signatário indicado assine o certificado. Suas solicitações são aprovadas ou negadas antes de serem assinadas. O Kubernetes é compatível com signers incorporados e personalizados com comportamentos bem definidos. Dessa maneira, os clientes podem prever o que acontece com suas CSRs. Para saber mais sobre assinatura de certificados, consulte [solicitações de assinatura](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/). Um dos signatários integrados é `kubernetes.io/legacy-unknown`. A API `v1beta1` do recurso CSR respeitou esse signatário legacy-unknown. Porém, a API estável `v1` de CSR não permite que o `signerName` seja definido como `kubernetes.io/legacy-unknown`. Se você desejar usar a CA do Amazon EKS para gerar certificados em seus clusters, deverá usar um signatário personalizado. Para usar a versão `v1` da API de CSR e gerar um novo certificado, você deverá migrar todos os manifestos e clientes de API existentes. Certificados existentes criados com a API `v1beta1` existente são válidos e funcionarão até o certificado expirar. Essa transmissão inclui o seguinte: + Distribuição de confiança: nada. Não há confiança ou distribuição padrão para esse signer em um cluster do Kubernetes. + Requerentes permitidos: qualquer + Extensões x509 permitidas: respeita subjectAltName e extensões de uso de chaves e descarta outras extensões + Usos de chaves permitidos: não deve incluir usos além de ["criptografia de chaves”, “assinatura digital”, “autenticação de servidor"] **nota** A assinatura de certificados de clientes não é possível. + Vida útil de expiração/certificado: um ano (padrão e máximo) + Bit de CA permitido/proibido: não permitido ## Exemplo de geração de CSR com signerName Estas etapas mostram como gerar um certificado de serviço para o nome de DNS `myserver.default.svc` usando `signerName: beta.eks.amazonaws.com/app-serving`. Use isso como orientação para seu próprio ambiente. 1. Execute o comando `openssl genrsa -out myserver.key 2048` para gerar uma chave RSA privada. ``` openssl genrsa -out myserver.key 2048 ``` 1. Use o seguinte comando para gerar uma solicitação de certificado: ``` openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc" ``` 1. Gere um valor em `base64` para a solicitação de CSR e armazene-o em uma variável para uso em uma etapa posterior. ``` base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ") ``` 1. Execute o seguinte comando para criar um arquivo chamado `mycsr.yaml`. No exemplo a seguir, `beta.eks.amazonaws.com/app-serving` é `signerName`. ``` cat >mycsr.yaml < myserver.crt ``` # Entender as funções e os usuários do RBAC criados pelo Amazon EKS Quando você cria um cluster do Kubernetes, várias identidades padrão do Kubernetes são criadas nesse cluster para o funcionamento adequado do Kubernetes. O Amazon EKS cria identidades do Kubernetes para cada um de seus componentes padrão. As identidades fornecem controle de autorização baseado em perfil (RBAC) do Kubernetes para os componentes do cluster. Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes. Quando você instala [complementos](eks-add-ons.md) opcionais no cluster, identidades adicionais do Kubernetes talvez sejam adicionadas a ele. Para obter mais informações sobre as identidades não abordadas neste tópico, consulte a documentação do complemento. Você pode ver a lista de identidades do Kubernetes criadas pelo Amazon EKS no cluster usando o Console de gerenciamento da AWS ou a ferramenta de linha de comandos do `kubectl`. Todas as identidades de usuário aparecem nos logs de auditoria do `kube`, disponíveis a você por meio do Amazon CloudWatch. ## Console de gerenciamento da AWS ### Pré-requisito A [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que você usar deve ter as permissões descritas em [Permissões necessárias](view-kubernetes-resources.md#view-kubernetes-resources-permissions). ### Para visualizar as identidades criadas pelo Amazon EKS usando o Console de gerenciamento da AWS 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Na lista **Clusters**, escolha o cluster que contém as identidades do que você deseja visualizar. 1. Escolha a guia **Recursos**. 1. Em **Resource types** (Tipos de recursos), escolha **Authorization** (Autorização). 1. Escolha **ClusterRoles**, **ClusterRoleBindings**, **Roles** ou **RoleBindings**. Todos os recursos prefaciados com **eks** são criados pelo Amazon EKS. Outros recursos de identidade criados pelo Amazon EKS são: + O **ClusterRole** e o **ClusterRoleBinding** denominados **aws-node**. Os recursos **aws-node** são compatíveis com o [plug-in CNI da Amazon VPC para Kubernetes](managing-vpc-cni.md), que o Amazon EKS instala em todos os clusters. + Um **ClusterRole** denominado **vpc-resource-controller-role** e um **ClusterRoleBinding** denominado **vpc-resource-controller-rolebinding**. Esses recursos são compatíveis com o [controlador de recursos da Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que o Amazon EKS instala em todos os clusters. Além dos recursos que você vê no console, as seguintes identidades de usuário especiais existem no cluster, embora não estejam visíveis na sua configuração: + ** `eks:cluster-bootstrap` **: usado para operações `kubectl` durante a inicialização do cluster. + ** `eks:support-engineer` ** – usado para operações de gerenciamento de cluster. 1. Escolha um recurso específico para visualizar detalhes sobre ele. Por padrão, as informações são mostradas na **visualização estruturada**. No canto superior direito da página de detalhes, você pode escolher **Raw view** (Visualização bruta) para ver todas as informações sobre o recurso. ## Kubectl ### Pré-requisito A entidade que você usa (AWS Identity and Access Management [IAM] ou OpenID Connect [OIDC]) para listar os recursos do Kubernetes no cluster deve ser autenticada pelo IAM ou pelo seu provedor de identidade OIDC. A entidade deve receber permissões para usar os verbos `get` e `list` do Kubernetes para os recursos `Role`, `ClusterRole`, `RoleBinding` e `ClusterRoleBinding` no cluster com o qual você deseja que a entidade trabalhe. Para obter mais informações sobre conceder às entidades do IAM acesso ao cluster, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md). Para obter mais informações sobre conceder às entidades autenticadas por seu próprio provedor OIDC acesso ao cluster, consulte [Conceder aos usuários acesso ao Kubernetes com um provedor OIDC externo](authenticate-oidc-identity-provider.md). ### Para visualizar as identidades criadas pelo Amazon EKS usando o `kubectl` Execute o comando para o tipo de recurso que você deseja ver. Todos os recursos retornados precedidos por **eks** são criados pelo Amazon EKS. Além dos recursos que retornados na saída dos comandos, as seguintes identidades de usuário especiais existem no cluster, embora não estejam visíveis na sua configuração: + ** `eks:cluster-bootstrap` **: usado para operações `kubectl` durante a inicialização do cluster. + ** `eks:support-engineer` ** – usado para operações de gerenciamento de cluster. **ClusterRoles**: `ClusterRoles` estão no escopo do cluster, portanto, qualquer permissão concedida a um perfil se aplicará aos recursos em qualquer namespace do Kubernetes no cluster. O comando a seguir retorna todos os `ClusterRoles` do Kubernetes criados pelo Amazon EKS no cluster. ``` kubectl get clusterroles | grep eks ``` Além dos `ClusterRoles` retornados na saída que são precedidos por eks, existem os `ClusterRoles` a seguir. + ** `aws-node` **: este `ClusterRole` é compatível com o [plug-in CNI da Amazon VPC para Kubernetes](managing-vpc-cni.md), que o Amazon EKS instala em todos os clusters. + ** `vpc-resource-controller-role` ** este `ClusterRole` é compatível com o [controlador de recursos do Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que o Amazon EKS instala em todos os clusters. Para ver a especificação de um `ClusterRole`, substitua *eks:k8s-metrics* no comando a seguir por um `ClusterRole` retornado na saída do comando anterior. O exemplo a seguir retorna a especificação para `ClusterRole` *eks:k8s-metrics*. ``` kubectl describe clusterrole eks:k8s-metrics ``` Veja um exemplo de saída abaixo. ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [/metrics] [] [get] endpoints [] [] [list] nodes [] [] [list] pods [] [] [list] deployments.apps [] [] [list] ``` **ClusterRoleBindings**: `ClusterRoleBindings` estão no escopo do cluster. O comando a seguir retorna todos os `ClusterRoleBindings` do Kubernetes criados pelo Amazon EKS no cluster. ``` kubectl get clusterrolebindings | grep eks ``` Além dos `ClusterRoleBindings` retornados na saída, existem os `ClusterRoleBindings` a seguir. + ** `aws-node` **: este `ClusterRoleBinding` é compatível com o [plug-in CNI da Amazon VPC para Kubernetes](managing-vpc-cni.md), que o Amazon EKS instala em todos os clusters. + ** `vpc-resource-controller-rolebinding` ** este `ClusterRoleBinding` é compatível com o [controlador de recursos do Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que o Amazon EKS instala em todos os clusters. Para ver a especificação de um `ClusterRoleBinding`, substitua *eks:k8s-metrics* no comando a seguir por um `ClusterRoleBinding` retornado na saída do comando anterior. O exemplo a seguir retorna a especificação para `ClusterRoleBinding` *eks:k8s-metrics*. ``` kubectl describe clusterrolebinding eks:k8s-metrics ``` Veja abaixo um exemplo de saída. ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: ClusterRole Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` **Perfis**: `Roles` estão no escopo de um namespace do Kubernetes. Todos os `Roles` criados pelo Amazon EKS estão no escopo do namespace do `kube-system`. O comando a seguir retorna todos os `Roles` do Kubernetes criados pelo Amazon EKS no cluster. ``` kubectl get roles -n kube-system | grep eks ``` Para ver a especificação de um `Role`, substitua *eks:k8s-metrics* no comando a seguir pelo nome de um `Role` retornado na saída do comando anterior. O exemplo a seguir retorna a especificação para `Role` *eks:k8s-metrics*. ``` kubectl describe role eks:k8s-metrics -n kube-system ``` Veja abaixo um exemplo de saída. ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- daemonsets.apps [] [aws-node] [get] deployments.apps [] [vpc-resource-controller] [get] ``` **RoleBindings**: `RoleBindings` estão no escopo de um namespace do Kubernetes. Todos os `RoleBindings` criados pelo Amazon EKS estão no escopo do namespace do `kube-system`. O comando a seguir retorna todos os `RoleBindings` do Kubernetes criados pelo Amazon EKS no cluster. ``` kubectl get rolebindings -n kube-system | grep eks ``` Para ver a especificação de um `RoleBinding`, substitua *eks:k8s-metrics* no comando a seguir por um `RoleBinding` retornado na saída do comando anterior. O exemplo a seguir retorna a especificação para `RoleBinding` *eks:k8s-metrics*. ``` kubectl describe rolebinding eks:k8s-metrics -n kube-system ``` Veja um exemplo de saída abaixo. ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: Role Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` # Criptografar segredos do Kubernetes com o KMS em clusters existentes **Importante** Este procedimento se aplica somente aos clusters do EKS que executam o Kubernetes versão 1.27 ou mais antiga. Se você estiver executando o Kubernetes versão 1.28 ou mais recente, os segredos do Kubernetes serão protegidos com criptografia envelopada por padrão. Para obter mais informações, consulte [Criptografia envelopada padrão para todos os dados de API do Kubernetes](envelope-encryption.md). Se você habilitar a [criptografia de segredos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), os segredos do Kubernetes serão criptografados usando a chave do AWS KMS selecionada. A chave do KMS deve atender às seguintes condições: + Simétrica + Pode criptografar e descriptografar dados + Criado na mesma região AWS que o cluster + Se a chave do KMS tiver sido criada em uma conta diferente, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) deverá ter acesso à chave do KMS. Para obter mais informações, consulte [Como permitir que as entidades principais do IAM em outras contas usem uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) no * [ Guia do desenvolvedor do serviço de gerenciamento de chaves AWS](https://docs.aws.amazon.com/kms/latest/developerguide/) *. **Atenção** Não é possível desativar a criptografia de segredos depois de habilitá-la. Essa ação é irreversível. eksctl Este procedimento se aplica somente aos clusters do EKS que executam o Kubernetes versão 1.27 ou mais antiga. Para obter mais informações, consulte [Criptografia envelopada padrão para todos os dados de API do Kubernetes](envelope-encryption.md). É possível ativar a criptografia de duas formas: + Adicione criptografia ao cluster com um único comando. Para recriptografar seus segredos automaticamente, execute o comando a seguir. ``` eksctl utils enable-secrets-encryption \ --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key ``` Para optar por não recriptografar seus segredos automaticamente, execute o comando a seguir. ``` eksctl utils enable-secrets-encryption --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key \ --encrypt-existing-secrets=false ``` + Adicione criptografia ao cluster com um arquivo `kms-cluster.yaml`. ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code secretsEncryption: keyARN: arn:aws:kms:region-code:account:key/key ``` Para que seus segredos sejam recriptografados automaticamente, execute o comando a seguir. ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml ``` Para optar por não recriptografar seus segredos automaticamente, execute o comando a seguir. ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false ``` Console de gerenciamento da AWS 1. Este procedimento se aplica somente aos clusters do EKS que executam o Kubernetes versão 1.27 ou mais antiga. Para obter mais informações, consulte [Criptografia envelopada padrão para todos os dados de API do Kubernetes](envelope-encryption.md). 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Escolha o cluster ao qual você deseja adicionar a criptografia do KMS. 1. Escolha a guia **Overview** (Visão geral) (selecionada por padrão). 1. Role para baixo até **Secrets encryption** (Criptografia de segredos) e escolha **Enable** (Habilitar). 1. Selecione uma chave na lista suspenso e escolha **Enable** (Habilitar). Se nenhuma chave estiver listada, primeiro você deve criar uma. Para obter mais informações, consulte [Criar chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) 1. Escolha o botão **Confirm** (Confirmar) para usar a chave escolhida. AWS CLI 1. Este procedimento se aplica somente aos clusters do EKS que executam o Kubernetes versão 1.27 ou mais antiga. Para obter mais informações, consulte [Criptografia envelopada padrão para todos os dados de API do Kubernetes](envelope-encryption.md). 1. Associe a configuração [de criptografia de segredos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) ao seu cluster usando o seguinte comando da CLI AWS. Substitua os valores de exemplo pelos seus próprios. ``` aws eks associate-encryption-config \ --cluster-name my-cluster \ --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]' ``` Veja abaixo um exemplo de saída. ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "InProgress",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734,     "errors": []   } } ``` 1. Você pode monitorar o status da atualização da criptografia com o comando a seguir. Utilize o `cluster name` e o `update ID` específicos que foram retornados na saída anterior. Quando um status de `Successful` for exibido, significa que a atualização está concluída. ``` aws eks describe-update \ --region region-code \ --name my-cluster \ --update-id 3141b835-8103-423a-8e68-12c2521ffa4d ``` Veja um exemplo de saída abaixo. ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "Successful",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734>,     "errors": []   } } ``` 1. Para verificar se a criptografia está habilitada no cluster, execute comando `describe-cluster`. A resposta contém uma string `EncryptionConfig`. ``` aws eks describe-cluster --region region-code --name my-cluster ``` Depois de habilitar a criptografia no cluster, você precisa criptografar todos os segredos existentes com a nova chave: **nota** Se você utilizar `eksctl`, apenas será necessário executar o seguinte comando se você optar por não recriptografar seus segredos automaticamente: ``` kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value" ``` **Atenção** Se você habilitar a [criptografia de segredos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) para um cluster existente e se algum dia a chave do KMS usada for excluída, não haverá maneira de recuperar o cluster. Se você excluir a chave do KMS, colocará permanentemente o cluster em um estado degradado. Para informações, consulte [Exclusão das chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html). **nota** Por padrão, o comando `create-key` cria uma [chave KMS de criptografia simétrica](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) com uma política de chave que concede à conta acesso de administrador raiz às ações e aos recursos do KMS AWS. Se você quiser reduzir o escopo das permissões, certifique-se de que as ações `kms:DescribeKey` e `kms:CreateGrant` sejam permitidas na política para a entidade principal que chama a API `create-cluster`. Para clusters que usam criptografia envelopada do KMS, são necessárias permissões `kms:CreateGrant`. A condição `kms:GrantIsForAWSResource` não tem suporte para a ação CreateCluster e não deve ser utilizada nas políticas do KMS para controlar permissões `kms:CreateGrant` de usuários que executam CreateCluster. # Uso dos segredos do AWS Secrets Manager com os pods do Amazon EKS Para mostrar os segredos do Secrets Manager e os parâmetros do Parameter Store como arquivos montados nos pods do Amazon EKS, você pode usar o AWS Secrets and Configuration Provider (ASCP) para o [driver CSI do armazenamento de segredos do Kubernetes](https://secrets-store-csi-driver.sigs.k8s.io/). Com o ASCP, você pode armazenar e gerenciar segredos no Secrets Manager e, em seguida, recuperá-los por meio de workloads executadas no Amazon EKS. Você pode usar os perfis e as políticas do IAM para limitar a pods específicos do Amazon EKS em um cluster o acesso aos seus segredos. O ASCP recupera a identidade de pods e troca a identidade por um perfil do IAM. O ASCP assume o perfil do IAM do pod e, então, consegue recuperar segredos do Secrets Manager autorizados para esse perfil. Se você usar a alternância automática do Secrets Manager para seus segredos, também poderá usar o recurso de reconciliador de alternância do driver da CSI do armazenamento de segredos para garantir que está recuperando o segredo mais recente do Secrets Manager. **nota** Não há suporte para grupos de nós do AWS Fargate (Fargate). Para obter mais informações, consulte [Uso dos segredos do Secrets Manager o Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) no Guia do usuário do AWS Secrets Manager. # Criptografia envelopada padrão para todos os dados de API do Kubernetes O Amazon Elastic Kubernetes Service (Amazon EKS) fornece criptografia envelopada padrão para todos os dados de API do Kubernetes nos clusters de EKS em execução no Kubernetes versão 1.28 ou mais recente. A criptografia envelopada protege os dados que você armazena com o servidor de API do Kubernetes. Por exemplo, a criptografia envelopada se aplica à configuração do cluster do Kubernetes, como `ConfigMaps`. A criptografia envelopada não se aplica aos dados em nós ou volumes do EBS. Anteriormente, o EKS era compatível com a criptografia de segredos do Kubernetes, e agora essa criptografia envelopada se estende a todos os dados de API do Kubernetes. Ela oferece uma experiência padrão gerenciada que implementa a defesa profunda para as aplicações do Kubernetes e não requer nenhuma ação de sua parte. O Amazon EKS usa o AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) com o [provedor v2 do Kubernetes para KMS](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) para essa camada adicional de segurança com uma [chave de propriedade da Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) e a opção de você trazer sua própria [chave gerenciada pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) do AWS KMS. ## Como compreender a criptografia envelopada A criptografia envelopada é o processo de criptografar dados de texto simples com uma chave de criptografia de dados (DEK) antes de serem enviados ao datastore (etcd), e depois criptografando a DEK com uma chave raiz do KMS que é armazenada em um sistema KMS remoto e gerenciado de forma centralizada (AWS KMS). Esta é uma estratégia de defesa em profundidade porque protege os dados com uma chave de criptografia (DEK) e, depois, adiciona outra camada de segurança, protegendo essa DEK com uma chave de criptografia separada e armazenada com segurança, denominada chave de criptografia de chave (KEK). ## Como o Amazon EKS habilita a criptografia envelopada padrão com o KMS v2 e o AWS KMS O Amazon EKS usa o [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) para implementar a criptografia envelopada padrão para todos os dados de API no ambiente de gerenciamento controlado do Kubernetes antes que persistam no banco de dados [etcd](https://etcd.io/docs/v3.5/faq/). Na inicialização, o servidor de API do cluster gera uma chave de criptografia de dados (DEK) de uma semente secreta combinada com dados gerados aleatoriamente. Também na inicialização, o servidor de API faz uma chamada para o plug-in do KMS para criptografar a semente da DEK usando uma chave de criptografia de chave (KEK) remota do AWS KMS. Essa é uma chamada única executada na inicialização do servidor de API e na alternância da KEK. Em seguida, o servidor de API armazena em cache a semente criptografada da DEK. Depois, o servidor de API usa a semente em cache da DEK para gerar outras DEKs de uso único com base em uma Função de Derivação de Chave (KDF). Cada uma dessas DEKs geradas é usada apenas uma vez para criptografar um único recurso do Kubernetes antes de ser armazenado no etcd. Com o uso de uma semente em cache criptografada da DEK no KMS v2, o processo de criptografia dos recursos do Kubernetes no servidor de API é mais eficiente e econômico. **Por padrão, essa KEK é de propriedade da AWS, mas, opcionalmente, você pode trazer sua própria KEK do AWS KMS.** O diagrama abaixo mostra a geração e a criptografia de uma DEK na inicialização do servidor de API. ![\[O diagrama mostra a geração e a criptografia de uma DEK na inicialização do servidor de API\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/security-generate-dek.png) O diagrama de alto nível abaixo mostra a criptografia de um recurso do Kubernetes antes de ser armazenado no etcd. ![\[O diagrama de alto nível mostra a criptografia de um recurso do Kubernetes antes de ser armazenado no etcd.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/security-encrypt-request.png) ## Perguntas frequentes ### Como a criptografia envelopada padrão melhora a postura de segurança do meu cluster de EKS? Esse recurso reduz a área de superfície e o tempo em que os metadados e o conteúdo do cliente não são criptografados. Com a criptografia envelopada padrão, os metadados e o conteúdo do cliente só ficam não criptografados temporariamente na memória do kube-apiserver antes de serem armazenados no etcd. A memória do kube-apiserver é protegida pelo [sistema Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html). O Amazon EKS usa somente [instâncias do EC2 baseadas em Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) para o ambiente de gerenciamento controlado do Kubernetes. Essas instâncias têm designs de controle de segurança que impedem que qualquer sistema ou pessoa acesse sua memória. ### Qual versão do Kubernetes eu preciso executar para ter esse recurso? Para que a criptografia envelopada padrão seja habilitada, o cluster do Amazon EKS precisa estar executando a versão 1.28 ou posterior do Kubernetes. ### Meus dados ainda estarão seguros se eu estiver executando uma versão do cluster do Kubernetes não compatível com esse recurso? Sim. Na AWS, [a segurança é a nossa maior prioridade](https://aws.amazon.com/security/). Baseamos toda a nossa transformação e inovação digital nas mais elevadas práticas operacionais de segurança e mantemos o compromisso de elevar esse nível. Todos os dados armazenados no etcd são criptografados no nível de disco para cada cluster de EKS, independentemente da versão do Kubernetes que está sendo executada. O EKS usa chaves raiz que geram chaves de criptografia de volume gerenciadas pelo serviço do EKS. Além disso, todos os clusters do Amazon EKS são executados em uma VPC isolada usando máquinas virtuais específicas do cluster. Por causa dessa arquitetura e de nossas práticas em relação à segurança operacional, o Amazon EKS [alcançou várias classificações e padrões de conformidade](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html), incluindo a elegibilidade para SOC 1,2,3, PCI-DSS, ISO e HIPAA. Esses padrões e classificações de conformidade são mantidos para todos os clusters de EKS com ou sem criptografia envelopada padrão. ### Como a criptografia envelopada funciona no Amazon EKS? Na inicialização, o servidor de API do cluster gera uma chave de criptografia de dados (DEK) de uma semente secreta combinada com dados gerados aleatoriamente. Também na inicialização, o servidor de API faz uma chamada para o plug-in do KMS para criptografar a DEK usando uma chave de criptografia de chave (KEK) remota do AWS KMS. Essa é uma chamada única executada na inicialização do servidor de API e na alternância da KEK. Em seguida, o servidor de API armazena em cache a semente criptografada da DEK. Depois, o servidor de API usa a semente em cache da DEK para gerar outras DEKs de uso único com base em uma Função de Derivação de Chave (KDF). Cada uma dessas DEKs geradas é usada apenas uma vez para criptografar um único recurso do Kubernetes antes de ser armazenado no etcd. É importante observar que o servidor de API realiza chamadas adicionais para verificar a integridade e a funcionalidade normal da integração do AWS KMS. Essas verificações de integridade adicionais ficam visíveis no AWS CloudTrail. ### Preciso fazer alguma coisa ou alterar qualquer permissão para que esse recurso funcione no cluster de EKS? Não, você não precisa tomar nenhuma medida. A criptografia envelopada no Amazon EKS agora é uma configuração padrão habilitada em todos os clusters que executam a versão 1.28 ou mais recente do Kubernetes. A integração com o AWS KMS é estabelecida pelo servidor de API do Kubernetes gerenciado pela AWS. Isso significa que você não precisa configurar nenhuma permissão para começar a usar a criptografia do KMS no cluster. ### Como posso saber se a criptografia envelopada padrão está habilitada no cluster? Se migrar para usar sua própria CMK, você verá o ARN da chave do KMS associada ao cluster. Além disso, você pode visualizar os logs de eventos do AWS CloudTrail associados ao uso da CMK do cluster. Se o cluster usar uma chave de propriedade da AWS, isso será detalhado no console do EKS (excluindo o ARN da chave). ### A AWS pode acessar a chave de propriedade da AWS usada para criptografia envelopada padrão no Amazon EKS? Não. A AWS tem controles de segurança rigorosos no Amazon EKS que impedem que qualquer pessoa acesse qualquer chave de criptografia de texto simples usada para proteger dados no banco de dados do etcd. Essas medidas de segurança também se aplicam à chave do KMS de propriedade da AWS. ### A criptografia envelopada padrão está habilitada no meu cluster existente do EKS? Se você estiver executando um cluster do Amazon EKS com a versão 1.28 ou mais recente do Kubernetes, a criptografia envelopada de todos os dados de API do Kubernetes estará habilitada. Para os clusters existentes, o Amazon EKS usa o RBAC ClusterRole `eks:kms-storage-migrator` para migrar dados que antes não tinham criptografia envelopada no etcd para esse novo estado de criptografia. ### O que isso significa se eu já habilitei a criptografia envelopada para os segredos no cluster de EKS? Se você tiver uma chave gerenciada pelo cliente (CMK) existente no KMS que foi usada para a criptografia envelopada dos seus segredos do Kubernetes, essa mesma chave será usada como KEK para a criptografia envelopada de todos os tipos de dados de API do Kubernetes no cluster. ### Há algum custo adicional em executar um cluster de EKS com a criptografia envelopada padrão? Não haverá custo adicional associado ao ambiente de gerenciamento controlado do Kubernetes se você estiver usando uma [chave de propriedade da Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) para a criptografia envelopada padrão. Por padrão, todos os clusters de EKS em execução no Kubernetes versão 1.28 ou posterior usam uma [chave de propriedade da Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). No entanto, se você usar sua própria chave do AWS KMS, o [preço do KMS](https://aws.amazon.com/kms/pricing/) será aplicado. ### Quanto custa para usar minha própria chave do AWS KMS para criptografar dados de API do Kubernetes no cluster? Você paga US\$1 1 por mês para armazenar qualquer chave personalizada criada ou importada para o KMS. O KMS cobra por solicitações de criptografia e descriptografia. Existe um nível gratuito de 20 mil solicitações por mês por conta, e você paga US\$1 0,03 por cada 10 mil solicitações acima do nível gratuito por mês. Isso se aplica a todo o uso do KMS em uma conta e, portanto, o custo de usar sua própria chave do AWS KMS no cluster será afetado pelo uso dessa chave em outros clusters ou recursos da AWS em sua conta. ### Minhas cobranças do KMS serão mais altas agora que minha chave gerenciada pelo cliente (CMK) está sendo usada para a criptografia envelopada de todos os dados de API do Kubernetes e não apenas dos segredos? Não. Nossa implementação com o KMS v2 reduz significativamente o número de chamadas feitas para o AWS KMS. Por sua vez, ele reduzirá os custos associados à CMK, independentemente de os dados adicionais do Kubernetes serem criptografados ou descriptografados no cluster de EKS. Como detalhado anteriormente, a semente da DEK gerada usada para criptografia de recursos do Kubernetes é armazenada localmente no cache do servidor de API do Kubernetes depois de ser criptografada com a KEK remota. Se a semente criptografada da DEK não estiver no cache do servidor de API, o servidor de API chamará o AWS KMS para criptografar a semente da DEK. Em seguida, o servidor de API armazena em cache a semente criptografada da DEK para uso futuro no cluster sem chamar o KMS. Da mesma forma, para solicitações de descriptografia, o servidor de API chamará o AWS KMS para a primeira solicitação de descriptografia e, então, a semente de DEK descriptografada será armazenada em cache e usada para futuras operações de descriptografia. Para obter mais informações, consulte [KEP-3299: KMS v2 Improvements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) em Kubernetes Enhancements no GitHub. ### Posso usar a mesma chave CMK para vários clusters do Amazon EKS? Sim. Para usar uma chave novamente, você pode vinculá-la a um cluster na mesma região, associando o ARN ao cluster durante a criação. No entanto, se estiver usando a mesmo CMK para vários clusters de EKS, será necessário adotar as medidas necessárias para evitar a desabilitação arbitrária da CMK. Caso contrário, uma CMK desabilitada associada a vários clusters de EKS terá um maior impacto sobre os clusters que dependem dessa chave. ### O que acontece com meu cluster de EKS se minha CMK ficar indisponível após a ativação da criptografia envelopada padrão? Se você desabilitar uma chave do KMS, ela não poderá ser usada em nenhuma [operação criptográfica](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations). Sem acesso a uma CMK existente, o servidor de API não conseguirá criptografar e manter quaisquer objetos do Kubernetes recém-criados, bem como descriptografar quaisquer objetos do Kubernetes criptografados anteriormente armazenados no etcd. Se a CMK for desabilitada, o cluster será colocado imediatamente em um estado não íntegro/degradado, situação na qual não poderemos cumprir nosso [Compromisso de Serviço](https://aws.amazon.com/eks/sla/) até que você reabilite a CMK associada. Quando uma CMK for desabilitada, você receberá notificações sobre a integridade degradada do cluster de EKS e a necessidade de reabilitar a CMK em até 30 dias após a desabilitação para garantir a restauração bem-sucedida dos recursos do ambiente de gerenciamento do Kubernetes. ### Como posso proteger o cluster de EKS contra o impacto de uma CMK desabilitada ou excluída? Para proteger seus clusters de EKS contra essa ocorrência, os administradores de chave devem gerenciar o acesso às operações de chaves do KMS usando as políticas do IAM com um princípio de privilégio mínimo para reduzir o risco de qualquer desabilitação ou exclusão arbitrária de chaves associadas a clusters de EKS. Além disso, você pode definir um [alarme do CloudWatch](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) para ser notificado sobre o estado da sua CMK. ### Meu cluster de EKS será restaurado se eu reativar a CMK? Para garantir a restauração bem-sucedida do cluster de EKS, é altamente recomendável reabilitar a CMK nos primeiros 30 dias após sua desabilitação. No entanto, a restauração bem-sucedida do cluster de EKS também dependerá de ele sofrer ou não alguma alteração significativa na API devido a uma atualização automática do Kubernetes que pode ocorrer enquanto o cluster está em um estado não íntegro ou degradado. ### Por que meu cluster de EKS é colocado em um estado não íntegro ou degradado após a desabilitação da CMK? O servidor de API do ambiente de gerenciamento do EKS usa uma chave DEK que é criptografada e armazenada em cache na memória do servidor de API para criptografar todos os objetos durante as operações de criação e atualização antes de serem armazenados no etcd. Quando um objeto existente está sendo recuperado do etcd, o servidor DEK API usa a mesma chave DEK em cache e descriptografa o objeto de recurso do Kubernetes. Se você desativar a CMK, o servidor de API não detectará nenhum impacto imediato por causa da chave DEK em cache na memória do servidor de API. No entanto, quando a instância do servidor de API for reiniciada, ela não terá uma DEK em cache e precisará chamar o AWS KMS para operações de criptografia e descriptografia. Sem uma CMK, esse processo falhará com um código de erro KMS\$1KEY\$1DISABLED, impedindo que o servidor da API seja inicializado com êxito. ### O que acontecerá com meu cluster de EKS se eu excluir minha CMK? Excluir a chave CMK associada ao seu cluster de EKS degradará sua integridade além da recuperação. Sem sua CMK, o servidor de API não conseguirá mais criptografar e manter quaisquer novos objetos do Kubernetes, bem como descriptografar quaisquer objetos do Kubernetes criptografados anteriormente armazenados no banco de dados etcd. Somente prossiga com a exclusão de uma chave CMK para o cluster de EKS quando tiver certeza de que não vai precisar mais usá-lo. Observe que, se a CMK não for encontrada (KMS\$1KEY\$1NOT\$1FOUND) ou as concessões da CMK associada ao seu cluster forem revogadas (KMS\$1GRANT\$1REVOKED), seu cluster não será recuperável. Para obter mais informações sobre a integridade e os códigos de erro do cluster, consulte [Perguntas frequentes sobre a integridade do cluster e códigos de erro com caminhos de resolução](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status). ### Ainda serei cobrado por um cluster de EKS degradado e não íntegro porque desabilitei ou excluí a CMK? Sim. Embora o ambiente de gerenciamento do EKS não possa ser usado no caso de uma CMK desabilitada, a AWS ainda estará executando recursos de infraestrutura dedicados alocados ao cluster de EKS até que ele seja excluído pelo cliente. Além disso, nosso [Compromisso de Serviço](https://aws.amazon.com/eks/sla/) não se aplicará nesta circunstância porque será uma ação ou inação voluntária do cliente que impedirá a integridade e a operação normais do cluster de EKS. ### O cluster de EKS pode ser atualizado automaticamente quando está em um estado não íntegro ou degradado devido a uma CMK desabilitada? Sim. No entanto, se o cluster tiver uma CMK desabilitada, você terá um período de 30 dias para reabilitá-la. Nesses 30 dias, o cluster do Kubernetes não será atualizado automaticamente. No entanto, se esse período expirar e você não tiver reabilitado a CMK, o cluster será automaticamente atualizado para a próxima versão (n\$11) que está no suporte padrão, seguindo o ciclo de vida da versão do Kubernetes no EKS. É altamente recomendável reabilitar rapidamente uma CMK desabilitada quando você tomar conhecimento de um cluster afetado. É importante observar que, embora o EKS atualize automaticamente esses clusters afetados, não há garantia de que eles serão recuperados com sucesso, especialmente se o cluster passar por várias atualizações automáticas, já que essas atualizações podem incluir alterações na API do Kubernetes e um comportamento inesperado no processo de inicialização do servidor de API. ### Posso usar um alias de chave do KMS? Sim. O Amazon EKS [é compatível com o uso de alias de chave do KMS](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Um alias é um nome amigável para uma [chave do Amazon Web Service KMS.](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) Por exemplo, um alias permite fazer referência a uma chave do KMS como **my-key** em vez de **`1234abcd-12ab-34cd-56ef-1234567890ab`**. ### Ainda posso fazer backup dos meus recursos de cluster e restaurá-los usando minha própria solução de backup do Kubernetes? Sim. É possível usar uma solução de backup do Kubernetes (como o [Velero](https://velero.io/)) para recuperação de desastres, migração e proteção de dados do cluster do Kubernetes. Se você executar uma solução de backup do Kubernetes que acessa os recursos do cluster por meio do servidor de API, todos os dados recuperados pela aplicação serão descriptografados antes de chegar ao cliente. Com isso, será possível recuperar os recursos do cluster em outro cluster do Kubernetes. # Considerações de segurança sobre o Modo Automático do Amazon EKS Este tópico descreve a arquitetura de segurança, os controles e as práticas recomendadas do Modo Automático do Amazon EKS. À medida que as organizações implantam aplicações em contêineres em grande escala, manter uma postura de segurança forte torna-se cada vez mais complexo. O Modo Automático do EKS implementa controles de segurança automatizados e se integra aos serviços de segurança da AWS para ajudar você a proteger a infraestrutura de clusters, workloads e dados. Por meio de recursos de segurança integrados, como gerenciamento forçado do ciclo de vida dos nós e implantação automatizada de patches, o Modo Automático do EKS ajuda você a manter as práticas recomendadas de segurança e, ao mesmo tempo, reduzir a sobrecarga operacional. Antes de continuar com este tópico, certifique-se de estar familiarizado com os conceitos básicos do Modo Automático do EKS e ter analisado os pré-requisitos para habilitar o Modo Automático do EKS nos clusters. Para obter informações gerais sobre a segurança do Amazon EKS, consulte [Segurança no Amazon EKS](security.md). O Modo Automático do Amazon EKS se baseia nas bases de segurança existentes do Amazon EKS e, ao mesmo tempo, introduz controles de segurança automatizados adicionais para instâncias gerenciadas pelo EC2. ## Segurança e autenticação da API O Modo Automático do Amazon EKS usa mecanismos de segurança da plataforma da AWS para proteger e autenticar chamadas para a API do Amazon EKS. + O acesso à API do Kubernetes é protegido por meio de entradas de acesso ao EKS, que se integram às identidades do AWS IAM. + Para ter mais informações, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md). + Os clientes podem implementar um controle de acesso refinado ao endpoint da API do Kubernetes por meio da configuração das entradas de acesso do EKS. ## Segurança de rede O Modo Automático do Amazon EKS oferece suporte a várias camadas de segurança de rede: + **Integração com a VPC** + Opera na Amazon Virtual Private Cloud (VPC) + Compatível com as configurações personalizadas da VPC e layouts de sub-rede + Habilita a rede privada entre os componentes do cluster + Para obter mais informações, consulte [Gerenciar responsabilidades pela segurança na Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html) + **Políticas de rede** + Suporte nativo para políticas de rede do Kubernetes + Capacidade de definir regras granulares de tráfego de rede + Para ter mais informações, consulte [Limitar o tráfego do pod com políticas de rede do Kubernetes](cni-network-policy.md). ## Segurança da instância gerenciada do EC2 O Modo Automático do Amazon EKS opera instâncias gerenciadas pelo EC2 com os seguintes controles de segurança: ### Segurança do EC2 + As instâncias gerenciadas pelo EC2 mantêm os recursos de segurança do Amazon EC2. + Para obter mais informações sobre instâncias gerenciadas pelo EC2, consulte [Segurança no Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html). ### Gerenciamento do ciclo de vida da instância As instâncias gerenciadas pelo EC2 operadas pelo Modo Automático do EKS têm vida útil máxima de 21 dias. O Modo Automático do Amazon EKS encerra automaticamente as instâncias que excedem essa vida útil. Esse limite de ciclo de vida ajuda a evitar desvios de configuração e mantém a postura de segurança. ### Proteção de dados + O armazenamento de instâncias do Amazon EC2 é criptografado, sendo um armazenamento diretamente anexado à instância. Para obter mais informações, consulte [Proteção de dados no Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html). + O Modo Automático do EKS gerencia os volumes anexados às instâncias do EC2 no momento da criação, incluindo volumes raiz e de dados. O Modo Automático do EKS não gerencia totalmente os volumes do EBS criados usando os recursos de armazenamento persistente do Kubernetes. ### Gerenciamento de patches + O Modo Automático do Amazon EKS aplica automaticamente os patches às instâncias gerenciadas. + Os patches incluem: + Atualizações do sistema operacional + Patches de segurança + Componentes do Modo Automático do Amazon EKS **nota** Os clientes mantêm a responsabilidade de proteger e atualizar as workloads em execução nessas instâncias. ### Controles de acesso + O acesso direto à instância é restrito: + O acesso SSH não está disponível. + O acesso ao AWS Systems Manager Session Manager (SSM) não está disponível. + As operações de gerenciamento são realizadas por meio da API do Amazon EKS e da API do Kubernetes. ## Automatizar o gerenciamento de recursos. O Modo Automático do Amazon EKS não gerencia totalmente os volumes do Amazon Elastic Block Store (Amazon EBS) criados usando recursos de armazenamento persistente do Kubernetes. O Modo Automático do EKS também não gerencia Elastic Load Balancers (ELB). O Modo Automático do Amazon EKS automatiza as tarefas de rotina desses recursos. ### Segurança de armazenamento + A AWS recomenda que você habilite a criptografia para volumes do EBS provisionados pelos recursos de armazenamento persistente do Kubernetes. Para ter mais informações, consulte [Criar uma classe de armazenamento](create-storage-class.md). + Criptografia em repouso usando o AWS KMS + Será possível configurar sua conta da AWS para impor a criptografia das novas cópias de snapshots e volumes do EBS que criar. Para obter mais informações, consulte [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) no Guia do usuário do Amazon EBS. + Para obter mais informações, consulte [Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html). ### Segurança do balanceador de carga + Configuração automatizada de Elastic Load Balancers + Gerenciamento de certificados SSL e TLS por meio da integração com o AWS Certificate Manager + Automação de grupos de segurança para controle de acesso ao balanceador de carga + Para obter mais informações, consulte [Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html). ## Práticas recomendadas de segurança A seção a seguir descreve as práticas recomendadas de segurança do Modo Automático do Amazon EKS. + Analise regularmente as políticas do AWS IAM e as entradas de acesso ao EKS. + Implemente padrões de acesso de privilégio mínimo para workloads. + Monitore a atividade dos clusters por meio do AWS CloudTrail e do Amazon CloudWatch. Para ter mais informações, consulte [Registre chamadas de API como eventos do AWS CloudTrail](logging-using-cloudtrail.md) e [Monitorar dados de cluster com o Amazon CloudWatch](cloudwatch.md). + Use o AWS Security Hub para avaliação da postura de segurança. + Implemente padrões de segurança de pods apropriados para as workloads. # Considerações sobre segurança para funcionalidades do EKS Este tópico aborda considerações importantes de segurança para as funcionalidades do EKS, incluindo a configuração de perfis do IAM, as permissões do Kubernetes e os padrões arquiteturais para implantações em vários clusters e para o gerenciamento de recursos da AWS entre contas. As funcionalidades do EKS empregam uma combinação de perfis do IAM, entradas de acesso do EKS e RBAC do Kubernetes para fornecer acesso seguro a serviços da AWS, recursos do Kubernetes no cluster e integrações com o AWS CodeConnections, o AWS Secrets Manager e outros serviços da AWS. ## Perfil do IAM para a funcionalidade Ao criar uma funcionalidade, você fornece um perfil do IAM da funcionalidade que o EKS usa para executar ações em seu nome. Este perfil deve: + Estar na mesma conta da AWS que o cluster e o recurso da funcionalidade + Contar com uma política de confiança que permite que a entidade principal do serviço `capabilities.eks.amazonaws.com` assuma o perfil + Ter permissões do IAM apropriadas para o tipo de funcionalidade e de caso de uso, dependendo dos seus requisitos. Para informações detalhadas sobre permissões do IAM necessárias, consulte [Estabelecimento de conexão com repositórios do Git usando o AWS CodeConnections](integration-codeconnections.md), [Gerenciamento de segredos de aplicações com o AWS Secrets Manager](integration-secrets-manager.md) e [Configuração das permissões do ACK](ack-permissions.md) É uma prática recomendada considerar o escopo de privilégios necessário para seu caso de uso específico e conceder apenas as permissões essenciais para atender aos seus requisitos. Por exemplo, ao usar a funcionalidade do EKS para o Kube Resource Orchestrator, nenhuma permissão do IAM pode ser necessária, enquanto ao usar a funcionalidade do EKS para o AWS Controllers for Kubernetes, você pode conceder acesso total a um ou mais serviços da AWS. **Importante** Embora alguns casos de uso possam justificar o uso de privilégios administrativos abrangentes, siga o princípio de privilégio mínimo, concedendo apenas as permissões do IAM mínimas necessárias para seu caso de uso específico e restringindo o acesso a recursos específicos usando ARNs e chaves de condição, em vez de permissões curinga. Para obter informações detalhadas sobre como criar e configurar perfis do IAM de funcionalidades, consulte [Perfil do IAM para a funcionalidade do Amazon EKS](capability-role.md). ## Entradas de acesso do EKS Quando você cria uma funcionalidade com um perfil do IAM, o Amazon EKS gera automaticamente uma entrada de acesso para esse perfil no cluster. Essa entrada de acesso concede à funcionalidade as permissões básicas do Kubernetes necessárias para seu funcionamento. **nota** As entradas de acesso são geradas no cluster em que a funcionalidade foi criada. Para implantações do Argo CD em clusters remotos, é necessário criar entradas de acesso nesses clusters com as permissões adequadas, permitindo que a funcionalidade do Argo CD implante e gerencie aplicações. A entrada de acesso inclui: + O ARN do perfil do IAM como entidade principal + As políticas de entrada de acesso específicas da funcionalidade que concedem permissões básicas do Kubernetes + O escopo apropriado (abrangendo todo o cluster ou limitado a um namespace) com base no tipo da funcionalidade **nota** No caso do Argo CD, as permissões limitadas a namespace são concedidas ao namespace especificado na configuração da funcionalidade (por padrão, `argocd`). **Políticas padrão de entrada de acesso por funcionalidade** Cada tipo de funcionalidade concede ao perfil da funcionalidade as permissões necessárias, definindo diferentes políticas padrão de entrada de acesso da seguinte forma: **kro** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy` (com escopo de cluster) Concede permissões para monitorar e gerenciar ResourceGraphDefinitions, bem como criar instâncias de recursos personalizados definidos pelas RGDs. **ACK** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy` (com escopo de cluster) Concede permissões para criar, ler, atualizar e excluir recursos personalizados do ACK em todos os namespaces. **Argo CD** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy` (com escopo de cluster) Concede permissões em nível de cluster para o Argo CD descobrir recursos e gerenciar objetos com escopo de cluster. + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy` (com escopo de namespace) Concede permissões em nível de namespace para o Argo CD implantar e gerenciar aplicações. Aplica-se ao namespace especificado na configuração da funcionalidade (por padrão, `argocd`). Consulte [Analisar permissões da política de acesso](access-policy-permissions.md) para obter informações mais detalhadas. ## Permissões adicionais do Kubernetes Algumas funcionalidades podem exigir permissões adicionais do Kubernetes, além das políticas padrão de entrada de acesso. Essas permissões podem ser concedidas por meio de: + **Políticas de entrada de acesso**: associe políticas gerenciadas adicionais à entrada de acesso + **RBAC do Kubernetes**: crie associações `Role` ou `ClusterRole` para o usuário do Kubernetes da funcionalidade **Permissões de leitura de segredos do ACK** Alguns controladores do ACK precisam ler segredos do Kubernetes para obter dados sensíveis, como senhas de banco de dados. Os controladores do ACK listados abaixo precisam de permissão de leitura de segredos: + `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager` Para conceder permissões de leitura de segredos: 1. Associe a política de entrada de acesso `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` à entrada de acesso da funcionalidade 1. Defina o escopo da política para namespaces específicos nos quais os recursos do ACK farão referência a segredos, ou conceda acesso em todo o cluster **Importante** As permissões de leitura de segredos são limitadas aos namespaces que você especificar ao associar a política de entrada de acesso. Isso possibilita restringir o acesso da funcionalidade apenas aos segredos desejados. **Permissões de recursos arbitrários do kro** O kro requer permissões para criar e gerenciar os recursos definidos em ResourceGraphDefinitions. Por padrão, o kro só pode monitorar e gerenciar as próprias RGDs. Para conceder permissões ao kro para criar recursos: **Opção 1: políticas de entrada de acesso** Associe políticas de entrada de acesso definidas previamente, como `AmazonEKSAdminPolicy` ou `AmazonEKSEditPolicy`, à entrada de acesso da funcionalidade. **Opção 2: RBAC do Kubernetes** Crie uma `ClusterRoleBinding` que conceda ao usuário do Kubernetes da funcionalidade as permissões necessárias: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kro-cluster-admin subjects: - kind: User name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io ``` **nota** Para o kro, o nome do usuário do Kubernetes adota o padrão: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO` O nome da sessão `/KRO` (maiúsculas) é definido automaticamente pela funcionalidade kro do EKS. ## Permissões do IAM exigidas pela funcionalidade **kro (Kube Resource Orchestrator)** Nenhuma permissão do IAM é necessária. É possível criar um perfil da funcionalidade sem políticas vinculadas. O kro requer apenas permissões de RBAC do Kubernetes. **ACK (AWS Controllers for Kubernetes)** Requer permissões para gerenciar os recursos da AWS que o ACK criará e gerenciará. É necessário restringir o escopo das permissões a serviços, ações e recursos específicos, de acordo com suas necessidades. Para obter informações detalhadas sobre como configurar permissões do ACK, incluindo as práticas recomendadas para ambientes de produção com seletores de perfil do IAM, consulte [Configuração das permissões do ACK](ack-permissions.md). **Argo CD** Por padrão, nenhuma permissão do IAM é necessária. Entretanto, permissões adicionais podem ser exigidas para: + AWS Secrets Manager: se armazenar credenciais de repositórios do Git no Secrets Manager + AWS CodeConnections: se usar o CodeConnections para realizar autenticação em repositórios do Git + Amazon ECR: se usar charts do Helm armazenados em formato OCI no Amazon ECR ## Práticas recomendadas de segurança ### Princípio de privilégio mínimo do IAM Conceda aos recursos da funcionalidade apenas as permissões necessárias para o caso de uso. Isso não significa que você não possa conceder permissões administrativas abrangentes às funcionalidades, se necessário. Nesses casos, é necessário gerenciar o acesso a esses recursos de forma adequada. **Perfis da funcionalidade**: + **ACK**: sempre que possível, limite as permissões do IAM aos serviços e recursos da AWS que suas equipes precisam, com base no caso de uso e nos requisitos + **Argo CD**: restrinja o acesso a repositórios do Git específicos e a namespaces do Kubernetes + **kro**: requer um perfil da funcionalidade para a política de confiança, mas não são necessárias permissões do IAM (apenas RBAC do cluster é usado) **Exemplo**: em vez de `"Resource": "*"`, especifique padrões para recursos ou grupos de recursos específicos. ``` "Resource": [ "arn:aws:s3:::my-app-*", "arn:aws:rds:us-west-2:111122223333:db:prod-*" ] ``` Use chaves de condição do IAM para aplicar restrições adicionais de acesso: ``` "Condition": { "StringEquals": { "aws:ResourceTag/Environment": "production" } } ``` Para obter informações adicionais sobre a configuração do IAM, consulte a seção de considerações destinada a cada funcionalidade. ### Isolamento de namespace para segredos do Argo CD A funcionalidade gerenciada do Argo CD tem acesso a todos os segredos do Kubernetes no namespace configurado (padrão: `argocd`). Para manter uma postura de segurança ideal, siga estas práticas de isolamento de namespace: + Mantenha apenas segredos relevantes para o Argo CD no namespace do Argo CD + Evite armazenar segredos de aplicações não relacionadas no mesmo namespace do Argo CD + Use namespaces separados para segredos de aplicações que não sejam necessários para as operações do Argo CD Esse isolamento garante que o acesso do Argo CD a segredos seja limitado apenas às credenciais necessárias à autenticação em repositórios do Git e a outras operações específicas do Argo CD. ### RBAC do Kubernetes Controle quais usuários e contas de serviço podem criar e gerenciar recursos de funcionalidades. É uma prática recomendada implantar recursos de funcionalidades em namespaces dedicados, com políticas de RBAC apropriadas. Exemplo: perfil de RBAC para trabalhar com ACK, permitindo o gerenciamento de recursos de bucket do S3 no namespace `app-team`: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ack-s3-manager namespace: app-team rules: - apiGroups: ["s3.services.k8s.aws"] resources: ["buckets"] verbs: ["get", "list", "create", "update", "delete"] ``` ### Registro em log de auditoria **CloudTrail**: todas as operações de API das funcionalidades do EKS (por exemplo, criar, atualizar e excluir) são registradas no AWS CloudTrail. Habilite o registro em log do CloudTrail para acompanhar: + Quem criou ou modificou funcionalidades + Quando as configurações das funcionalidades foram alteradas + Quais perfis de funcionalidades estão em uso ### Acesso à rede e endpoints da VPC #### Acesso privado à API do Argo CD É possível restringir o acesso ao servidor de API do Argo CD associando um ou mais endpoints da VPC ao endpoint hospedado do Argo CD. Isso habilita conectividade privada a partir da sua VPC, sem trafegar pela Internet pública. O endpoint da VPC fornece acesso à IU da Web do Argo CD e à API do Argo CD (incluindo acesso à CLI). **nota** Endpoints da VPC conectados a endpoints hospedados da API do Argo CD (usando eks-capabilities.*region*.amazonaws.com) não oferecem suporte a políticas de endpoint da VPC. #### Implantação em clusters privados A funcionalidade do Argo CD pode implantar aplicações em clusters de EKS totalmente privados, oferecendo um benefício operacional significativo ao eliminar a necessidade de emparelhamento da VPC ou de configurações de rede complexas. No entanto, ao projetar esta arquitetura, é importante considerar que o Argo CD busca configurações em repositórios do Git (que podem ser públicos) e as aplica aos seus clusters privados. Garanta que você: + Utilize repositórios do Git privados para workloads sensíveis + Implemente controles de acesso e de autenticação adequados nos repositórios do Git + Analise e aprove alterações por meio de solicitações de pull antes de realizar a mesclagem + Considere usar as janelas de sincronização do Argo CD para controlar o momento em que as implantações podem ocorrer + Monitore os logs de auditoria do Argo CD em busca de alterações de configuração não autorizadas ### Compliance As funcionalidades do EKS são totalmente gerenciadas e contam com as certificações de conformidade do Amazon EKS. Para obter informações atualizadas sobre conformidade, consulte [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). ## Próximas etapas + [Configuração das permissões do ACK](ack-permissions.md): configure permissões do IAM para o ACK + [Configuração de permissões do kro](kro-permissions.md): configure o RBAC do Kubernetes para o kro + [Configuração das permissões do Argo CD](argocd-permissions.md): configure a integração com o Centro de Identidade para o Argo CD + [Solução de problemas das funcionalidades do EKS](capabilities-troubleshooting.md): solucione problemas de segurança e de permissões # Identity and Access Management para o Amazon EKS O AWS Identity and Access Management (IAM) é um serviço da AWS que ajuda administradores a controlar o acesso aos recursos da AWS de forma segura. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (ter permissões) para usar os recursos do Amazon EKS. O IAM é um AWS serviço da que pode ser usado sem custo adicional. ## Público O modo como você usa o AWS Identity and Access Management (IAM) é diferente, dependendo do trabalho que você faz no Amazon EKS. **Usuário do serviço**: se você usar o serviço Amazon EKS para fazer sua tarefa, o administrador fornecerá as credenciais e as permissões de que você precisa. À medida que você usa mais recursos do Amazon EKS para realizar o trabalho, talvez sejam necessárias permissões adicionais. Entender como o acesso é gerenciado pode ajudar a solicitar as permissões corretas ao administrador. Se você não puder acessar um recurso na Amazon EKS, consulte [Solução de problemas do IAM](security-iam-troubleshoot.md). **Administrador do serviço**: se você for o responsável pelos recursos do Amazon EKS em sua empresa, você provavelmente terá acesso total ao Amazon EKS. Cabe a você determinar quais funcionalidades e recursos do Amazon EKS os usuários do seu serviço devem acessar. Envie as solicitações ao administrador do IAM para alterar as permissões dos usuários de serviço. Revise as informações nesta página para compreender os conceitos básicos do IAM. Para saber mais sobre como a empresa pode usar o IAM com o Amazon EKS, consulte [Como o Amazon EKS funciona com o IAM](security-iam-service-with-iam.md). **Administrador do IAM**: se você for um administrador do IAM, talvez queira saber detalhes sobre como pode escrever políticas para gerenciar o acesso à Amazon EKS. Para visualizar exemplos de políticas baseadas em identidade do Amazon EKS que podem ser usadas no IAM, consulte [Exemplos de políticas baseadas em identidade do Amazon EKS](security-iam-id-based-policy-examples.md). ## Autenticação com identidades A autenticação é a forma como fazer login na AWS usando suas credenciais de identidade. É necessário estar *autenticado* (conectado à AWS) como usuário raiz da conta AWS, como usuário do IAM ou assumindo um perfil do IAM. É possível fazer login na AWS como uma identidade federada usando credenciais fornecidas por uma fonte de identidades. AWS Os usuários do Centro de Identidade do IAM, a autenticação de logon único da sua empresa e suas credenciais do Google ou do Facebook são exemplos de identidades federadas. Quando você faz login como identidade federada, o administrador já configurou anteriormente a federação de identidades usando perfis do IAM. Quando você acessa a AWS usando a federação, está indiretamente assumindo um perfil. A depender do tipo de usuário, você pode fazer login no Console de gerenciamento da AWS ou no portal de acesso AWS. Para obter mais informações sobre como fazer login em AWS, consulte [Como fazer login na sua conta AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no * Guia do usuário de login AWS*. Se você acessar a AWS de forma programática, a AWS fornecerá um kit de desenvolvimento de software (SDK) e uma interface de linha de comandos (CLI) para você assinar de forma criptográfica as solicitações usando as suas credenciais. Se você não utilizar as ferramentas AWS, deverá designar as solicitações por conta própria. Para obter mais informações sobre como usar o método recomendado para designar solicitações por conta própria, consulte [Designando solicitações de API AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) no *Guia do usuário do IAM*. Independente do método de autenticação usado, também pode ser exigido que você forneça informações adicionais de segurança. Por exemplo, a AWS recomenda o uso da autenticação multifator (MFA) para aumentar a segurança de sua conta. Para saber mais, consulte [Autenticação multifator](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) no * Guia do usuário do Centro de Identidade do AWS IAM* e [Usar a autenticação multifator (MFA) em AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) no *Guia do usuário do IAM*. ### Usuário raiz de conta da AWS Ao criar uma conta AWS, você começa com uma identidade de login que tem acesso completo a todos os serviços e recursos da conta AWS. Essa identidade é denominada *usuário-raiz* da conta da AWS e é acessada pelo login com o endereço de e-mail e a senha usados para criar a conta. É altamente recomendável não usar o usuário raiz para tarefas diárias. Proteja as credenciais do usuário-raiz e use-as para executar as tarefas que somente ele puder executar. Para obter a lista completa das tarefas que exigem login como usuário-raiz, consulte [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do Usuário do IAM*. ### Grupos e usuários do IAM Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) é uma identidade dentro da sua conta da AWS que tem permissões específicas para uma única pessoa ou aplicação. Sempre que possível, é recomendável contar com credenciais temporárias em vez de criar usuários do IAM com credenciais de longo prazo, como senhas e chaves de acesso. No entanto, se você tiver casos de uso específicos que exijam credenciais de longo prazo com usuários do IAM, é recomendável alternar as chaves de acesso. Para obter mais informações, consulte [Alternar as chaves de acesso regularmente para casos de uso que exijam credenciais de longo prazo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) no *Guia do Usuário do IAM*. Um [grupo do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) é uma identidade que especifica uma coleção de usuários do IAM. Não é possível fazer login como um grupo. É possível usar grupos para especificar permissões para vários usuários de uma vez. Os grupos facilitam o gerenciamento de permissões para grandes conjuntos de usuários. Por exemplo, você pode ter um grupo chamado *IAMAdmins* e conceder a esse grupo permissões para administrar recursos do IAM. Usuários são diferentes de perfis. Um usuário é exclusivamente associado a uma pessoa ou a uma aplicação, mas um perfil pode ser assumido por qualquer pessoa que precisar dele. Os usuários têm credenciais permanentes de longo prazo, mas os perfis fornecem credenciais temporárias. Para saber mais, consulte [Quando criar um usuário do IAM (em vez de um perfil)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) no *Guia do usuário do IAM*. ### Funções do IAM [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) é uma identidade dentro da sua conta da AWS que tem permissões específicas. Ele é semelhante a um usuário do IAM, mas não está associado a uma pessoa específica. É possível presumir temporariamente um perfil do IAM no Console de gerenciamento da AWS [alternando perfis](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). É possível assumir um perfil chamando uma operação da AWS CLI ou da AWS API, ou usando um URL personalizado. Para obter mais informações sobre métodos para o uso de perfis, consulte [Utilizar perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) no *Guia do usuário do IAM*. Perfis do IAM com credenciais temporárias são úteis nas situações a seguir: + **Acesso de usuário federado**: para atribuir permissões a identidades federadas, é possível criar um perfil e definir permissões para ele. Quando uma identidade federada é autenticada, essa identidade é associada ao perfil e recebe as permissões definidas por ele. Para obter mais informações sobre perfis para federação, consulte [Criar um perfil para um provedor de identidades de terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) no *Guia do usuário do IAM*. Se usar o Centro de Identidade do IAM, configure um conjunto de permissões. Para controlar o que suas identidades podem acessar após a autenticação, o Centro de Identidade do IAM correlaciona o conjunto de permissões a um perfil no IAM. Para obter informações sobre conjuntos de permissões, consulte [Conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no * Guia do usuário do Centro de Identidade do AWS IAM*. + **Permissões temporárias para usuários do IAM**: um usuário ou um perfil do IAM pode presumir um perfil do IAM para obter temporariamente permissões diferentes para uma tarefa específica. + **Acesso entre contas**: é possível usar um perfil do IAM para permitir que alguém (uma entidade principal confiável) em outra conta acesse recursos em sua conta. Os perfis são a principal forma de conceder acesso entre contas. No entanto, alguns serviços da AWS permitem que você anexe uma política diretamente a um recurso (em vez de usar um perfil como proxy). Para conhecer a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. + **Acesso entre serviços**: alguns serviços da AWS usam recursos em outros serviços da AWS. Por exemplo, quando você faz uma chamada em um serviço, é comum que esse serviço execute aplicações no Amazon EC2 ou armazene objetos no Amazon S3. Um serviço pode fazer isso usando as permissões da entidade principal de chamada, usando um perfil de serviço ou um perfil vinculado ao serviço. + **Sessões de acesso direto (FAS)**: qualquer pessoa que utilizar um perfil ou usuário do IAM para executar ações na AWS é considerada uma entidade principal. Ao usar alguns serviços, você pode executar uma ação que inicia outra ação em um serviço diferente. A FAS usa as permissões do entidade principal que chama um serviço da AWS, combinadas com o serviço da AWS solicitante, para fazer solicitações a serviços downstream. As solicitações FAS são feitas somente quando um serviço recebe uma solicitação que requer interações com outros serviços ou recursos do AWS para ser concluída. Nesse caso, você precisa ter permissões para executar ambas as ações. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). + **Perfil de serviço**: um perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir uma função de serviço do IAM. Para obter mais informações, consulte [Criação de uma função para delegar permissões a um AWS serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do usuário do IAM*. + **Função vinculada a serviço**: uma função vinculada a serviço é um tipo de função de serviço vinculada a um serviço da AWS. O serviço pode assumir o perfil de executar uma ação em seu nome. Os Perfis vinculados a serviços aparecem em sua conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados ao serviço. + **Aplicações em execução no Amazon EC2**: é possível usar um perfil do IAM para gerenciar credenciais temporárias para aplicações em execução em uma instância do EC2 e fazer solicitações da AWS CLI ou da AWS API. É preferível fazer isso a armazenar chaves de acesso na instância do EC2. Para atribuir um perfil da AWS a uma instância do EC2 e disponibilizá-la para todas as suas aplicações, crie um perfil de instância que esteja anexado a ela. Um perfil de instância contém o perfil e permite que os programas em execução na instância do EC2 obtenham credenciais temporárias. Para obter mais informações, consulte [Utilizar um perfil do IAM para conceder permissões a aplicações em execução nas instâncias do Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) no *Guia do usuário do IAM*. Para saber se deseja usar perfis do IAM, consulte [Quando criar um perfil do IAM (em vez de um usuário)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) no *Guia do usuário do IAM*. ## Gerenciando acesso usando políticas Você controla o acesso na AWS criando políticas e anexando-as a identidades ou recursos da AWS. Uma política é um objeto na AWS que, quando associado a uma identidade ou recurso, define suas permissões. A AWS avalia essas políticas quando uma entidade principal (usuário, usuário-raiz ou sessão de perfil) faz uma solicitação. As permissões nas políticas determinam se a solicitação será permitida ou negada. A maioria das políticas é armazenada na AWS como documentos JSON. Para obter mais informações sobre a estrutura e o conteúdo de documentos de políticas JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*. Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. Por padrão, usuários e perfis não têm permissões. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM. O administrador pode então adicionar as políticas do IAM aos perfis e os usuários podem assumir os perfis. As políticas do IAM definem permissões para uma ação independentemente do método usado para executar a operação. Por exemplo, suponha que você tenha uma política que permite a ação `iam:GetRole`. Um usuário com essa política pode obter informações sobre funções usando o Console de gerenciamento da AWS, a AWS CLI ou a API da AWS. ### Políticas baseadas em identidade As políticas baseadas em identidade são documentos de políticas de permissões JSON que você pode anexar a uma identidade, como usuário, grupo de usuários ou perfil do IAM. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Criando políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. As políticas baseadas em identidade podem ser categorizadas ainda adicionalmente como *políticas em linha* ou *políticas gerenciadas*. As políticas em linha são anexadas diretamente a um único usuário, grupo ou função. As políticas gerenciadas são políticas independentes que podem ser anexadas a vários usuários, grupos e funções em sua conta da AWS. As políticas gerenciadas incluem políticas gerenciadas pela AWS e políticas gerenciadas pelo cliente. Para saber como escolher entre uma política gerenciada ou uma política em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) no *Guia do Usuário do IAM*. ### Políticas baseadas em recursos Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. Você deve [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Os principais podem incluir contas, usuários, funções, usuários federados ou serviços da AWS. Políticas baseadas em recursos são políticas embutidas que estão localizadas nesse serviço. Não é possível usar as políticas do IAM gerenciadas por AWS em uma política baseada em recursos. ### Listas de controle de acesso (ACLs) As listas de controle de acesso (ACLs) controlam quais entidades principais (membros, usuários ou perfis da conta) têm permissões para acessar um recurso. As ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON. Amazon S3, AWS WAF e Amazon VPC são exemplos de serviços que suportam ACLs. Para saber mais sobre ACLs, consulte [Visão geral da lista de controle de acesso (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) no *Guia do Desenvolvedor do Amazon Simple Storage Service*. ### Outros tipos de política A AWS oferece compatibilidade com tipos de política menos comuns. Esses tipos de política podem definir o máximo de permissões concedidas a você pelos tipos de política mais comuns. + **Limites de permissões**: um limite de permissões é um recurso avançado no qual você define o máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM (usuário ou perfil do IAM). É possível definir um limite de permissões para uma entidade. As permissões resultantes são a interseção das políticas baseadas em identidade de uma entidade com seus limites de permissões. As políticas baseadas em recursos que especificam o usuário ou o perfil no campo `Principal` não são limitadas pelo limite de permissões. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para obter mais informações sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*. + **Políticas de controle de serviço (SCPs)** - SCPs são políticas JSON que especificam as permissões máximas para uma organização ou unidade organizacional (OU) em AWS Organizations. AWS O Organizations é um serviço para agrupar e gerenciar de forma centralizada várias contas do AWS que sua empresa possui. Se você habilitar todos os recursos em uma organização, poderá aplicar políticas de controle de serviço (SCPs) a qualquer uma ou a todas as contas. Uma SCP limita as permissões para entidades em contas-membro, incluindo cada usuário root da conta da AWS. Para obter mais informações sobre Organizações e SCPs, consulte [Políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no * Guia do Usuário de Organizações AWS*. + **Políticas de sessão**: são políticas avançadas que você transmite como um parâmetro quando cria de forma programática uma sessão temporária para um perfil ou um usuário federado. As permissões da sessão resultante são a interseção das políticas baseadas em identidade do usuário ou da função e as políticas da sessão. As permissões também podem ser provenientes de uma política baseada em recursos. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para obter mais informações, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*. ### Vários tipos de política Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como a AWS determina se deve permitir ou não uma solicitação quando há vários tipos de política envolvidos, consulte [Lógica da avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*. # Como o Amazon EKS funciona com o IAM Antes de usar o IAM para gerenciar o acesso ao Amazon EKS, é necessário entender quais recursos do IAM estão disponíveis para uso com o Amazon EKS. Para obter uma visualização de alto nível de como o Amazon EKS e outros serviços da AWS funcionam com o IAM, consulte [Serviços da AWS compatíveis com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Manual do usuário do IAM*. **Topics** + [Políticas baseadas em identidade do Amazon EKS](#security-iam-service-with-iam-id-based-policies) + [Políticas baseadas em recursos do Amazon EKS](#security-iam-service-with-iam-resource-based-policies) + [Autorização baseada em etiquetas do Amazon EKS](#security-iam-service-with-iam-tags) + [Funções do IAM no Amazon EKS](#security-iam-service-with-iam-roles) ## Políticas baseadas em identidade do Amazon EKS Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. A Amazon EKS oferece suporte a ações, chaves de condição e recursos específicos. Para saber mais sobre todos os elementos usados em uma política JSON, consulte [Referência de elementos de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*. ### Ações Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. As ações de políticas geralmente têm o mesmo nome que a operação de API da AWS associada. Existem algumas exceções, como *Ações somente de permissão*, que não têm uma operação de API correspondente. Algumas operações também exigem várias ações em uma política. Essas ações adicionais são chamadas de *ações dependentes*. Incluem ações em uma política para conceder permissões para executar a operação associada. As ações de política na Amazon EKS usam o seguinte prefixo antes da ação: `eks:`. Por exemplo, para conceder a alguém permissão para obter informações descritivas sobre um cluster do Amazon EKS, inclua a ação `DescribeCluster` na política dessa pessoa. As instruções de política devem incluir um elemento `Action` ou `NotAction`. Para especificar várias ações em uma única instrução, separe-as com vírgulas, como segue: ``` "Action": ["eks:action1", "eks:action2"] ``` Você também pode especificar várias ações usando caracteres curinga (\$1). Por exemplo, para especificar todas as ações que começam com a palavra `Describe`, inclua a seguinte ação: ``` "Action": "eks:Describe*" ``` Para ver uma lista das ações do Amazon EKS, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) na *Referência de autorização de serviço*. ### Recursos Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. As instruções devem incluir um elemento `Resource` ou `NotResource`. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Isso pode ser feito para ações que oferecem compatibilidade com um tipo de recurso específico, conhecido como *permissões em nível de recurso*. Para ações que não oferecem suporte a permissões em nível de recurso, como operações de listagem, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos. ``` "Resource": "*" ``` O recurso de cluster do Amazon EKS tem o seguinte ARN. ``` arn:aws:eks:region-code:account-id:cluster/cluster-name ``` Para obter mais informações sobre o formato de ARNs, consulte [Nomes de recursos da Amazon (ARNs) e namespaces de serviços da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Por exemplo, para especificar o cluster chamado *my-cluster* em sua instrução, use o seguinte ARN: ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster" ``` Para especificar todos os clusters que pertencem a uma conta e região da AWS específicas, use o caractere curinga (\$1): ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/*" ``` Algumas ações do Amazon EKS, como as que servem para a criação de recursos, não podem ser executadas em um recurso específico. Nesses casos, é necessário utilizar o caractere curinga (\$1). ``` "Resource": "*" ``` Para ver uma lista dos tipos de recursos do Amazon EKS e seus ARNs, consulte [Recursos definidos pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) na *Referência de autorização de serviço*. Para saber com quais ações você pode especificar o ARN de cada recurso, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions). ### Chaves de condição O Amazon EKS define seu próprio conjunto de chaves de condição e também oferece suporte ao uso de algumas chaves de condição globais. Para ver todas as chaves de condição globais da AWS, consulte [Chaves de contexto de condição globais da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*. É possível definir chaves de condição ao associar um provedor OpenID Connect ao cluster. Para obter mais informações, consulte [Exemplo de política do IAM](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy). Todas as ações do Amazon EC2 oferecem suporte às chaves de condição `aws:RequestedRegion` e `ec2:Region`. Para obter mais informações, consulte [Exemplo: Restrição de acesso a uma região específica do AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region). Para obter uma lista de chaves de condição do Amazon EKS, consulte [Condições definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) na *Referência de autorização de serviço*. Para saber com quais ações e recursos você pode usar a chave de condição, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions). ### Exemplos Para visualizar exemplos de políticas baseadas em identidade do Amazon EKS, consulte [Exemplos de políticas baseadas em identidade do Amazon EKS](security-iam-id-based-policy-examples.md). Quando você cria um cluster do Amazon EKS, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que cria o cluster, recebe automaticamente permissões `system:masters` na configuração de controle de acesso baseado em perfil (RBAC) no ambiente de gerenciamento do Amazon EKS. Como essa entidade principal não é exibida em nenhuma configuração visível, mantenha o controle de qual entidade principal criou o cluster originalmente. Para conceder a outras entidades principais do IAM a capacidade de interagir com o cluster, edite o `aws-auth ConfigMap` no Kubernetes e crie um `rolebinding` ou `clusterrolebinding` do Kubernetes com o nome de um `group` especificado no `aws-auth ConfigMap`. Para obter mais informações sobre como trabalhar com o ConfigMap, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md). ## Políticas baseadas em recursos do Amazon EKS O Amazon EKS não oferece suporte a políticas baseadas em recursos. ## Autorização baseada em etiquetas do Amazon EKS É possível anexar etiquetas aos recursos do Amazon EKS ou passar etiquetas em uma solicitação para o Amazon EKS. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name `, `aws:RequestTag/key-name ` ou chaves de condição `aws:TagKeys`. Para obter mais informações sobre recursos de marcação do Amazon EKS, consulte [Organizar recursos do Amazon EKS com tags](eks-using-tags.md). Para obter mais informações sobre com quais ações você pode usar tags em chaves de condição, consulte [Actions defined by Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) (Ações definidas pelo Amazon EKS) na [Referência de autorização do serviço](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). ## Funções do IAM no Amazon EKS [Perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) é uma entidade dentro da sua conta da AWS que tem permissões específicas. ### Usar credenciais temporárias com o Amazon EKS É possível usar credenciais temporárias para fazer login com federação, assumir um perfil do IAM ou assumir um perfil entre contas. Você obtém credenciais de segurança temporárias chamando operações de API do AWS STS, como AssumeRole ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). A Amazon EKS oferece suporte ao uso de credenciais temporárias. ### Perfis vinculados ao serviço [Perfis vinculados ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) permitem que os serviços da AWS acessem recursos em outros serviços para concluir uma ação em seu nome. Os perfis vinculados a serviço aparecem em sua conta do IAM e são de propriedade do serviço. Um administrador pode visualizar, mas não pode editar as permissões de perfis vinculados ao serviço. Amazon EKS oferece suporte às funções de serviço. Para obter detalhes sobre como criar ou gerenciar funções vinculadas ao serviço do Amazon EKS, consulte [Usar funções vinculadas ao serviço para o Amazon EKS](using-service-linked-roles.md). ### Perfis de serviço Esse atributo permite que um serviço assuma um [perfil de serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) em seu nome. O perfil permite que o serviço acesse recursos em outros serviços para concluir uma ação em seu nome. Os perfis de serviço aparecem em sua conta do IAM e são de propriedade da conta. Isso significa que um administrador do IAM pode alterar as permissões para esse perfil. Porém, fazer isso pode alterar a funcionalidade do serviço. Amazon EKS oferece suporte às funções de serviço. Para obter mais informações, consulte [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md) e [Perfil do IAM em nós do Amazon EKS](create-node-role.md). ### Escolher uma função IAM no Amazon EKS Ao criar um recurso de cluster no Amazon EKS, é necessário escolher uma função para permitir que o Amazon EKS acesse outros recursos da AWS em seu nome. Se você já tiver criado uma função de serviço, o Amazon EKS fornecerá uma lista de funções da qual escolher. É importante escolher uma função que tenha as políticas gerenciadas do Amazon EKS anexadas. Para obter mais informações, consulte [Verificar se há uma função de cluster existente](cluster-iam-role.md#check-service-role) e [Verificar se há uma função existente do nó](create-node-role.md#check-worker-node-role). # Exemplos de políticas baseadas em identidade do Amazon EKS Por padrão, os usuários e as funções do IAM não têm permissão para criar ou modificar recursos do Amazon EKS. Eles também não podem executar tarefas usando o Console de gerenciamento da AWS, a CLI da AWS ou a API da AWS. Um administrador do IAM deve criar políticas do IAM que concedam aos usuários e perfis permissão para executarem operações de API específicas nos recursos especificados de que precisam. O administrador deve anexar essas políticas aos usuários ou grupos do IAM que exigem essas permissões. Para saber como criar uma política baseada em identidade do IAM utilizando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Guia do usuário do IAM*. Quando você cria um cluster do Amazon EKS, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que cria o cluster, recebe automaticamente permissões `system:masters` na configuração de controle de acesso baseado em perfil (RBAC) no ambiente de gerenciamento do Amazon EKS. Como essa entidade principal não é exibida em nenhuma configuração visível, mantenha o controle de qual entidade principal criou o cluster originalmente. Para conceder a outras entidades principais do IAM a capacidade de interagir com o cluster, edite o `aws-auth ConfigMap` no Kubernetes e crie um `rolebinding` ou `clusterrolebinding` do Kubernetes com o nome de um `group` especificado no `aws-auth ConfigMap`. Para obter mais informações sobre como trabalhar com o ConfigMap, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md). **Topics** + [Práticas recomendadas de política](#security-iam-service-with-iam-policy-best-practices) + [Usar o console do Amazon EKS](#security-iam-id-based-policy-examples-console) + [Permitir que os usuários do IAM visualizem suas próprias permissões](#security-iam-id-based-policy-examples-view-own-permissions) + [Crie um cluster do Kubernetes na Nuvem AWS](#policy-create-cluster) + [Criar um cluster local do Kubernetes em um Outpost](#policy-create-local-cluster) + [Atualizar um cluster do Kubernetes](#policy-example1) + [Listar ou descrever todos os clusters](#policy-example2) ## Práticas recomendadas de política As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Amazon EKS em sua conta. Essas ações podem incorrer em custos para sua conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações: + **Comece a usar as políticas gerenciadas do AWS e avance para as permissões de privilégios mínimos** - Para começar a conceder permissões aos seus usuários e workloads, use as * políticas gerenciadas do AWS* que concedem permissões para muitos casos de uso comuns. Elas estão disponíveis em sua conta AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS que são específicas para seus casos de uso. Para obter mais informações, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*. + **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para obter mais informações sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. + **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso a ações de serviço se elas forem usadas por meio de um serviço específico do AWS, como o AWS CloudFormation. Para obter mais informações, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*. + **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de 100 verificações de política e recomendações acionáveis para ajudá-lo a criar políticas seguras e funcionais. Para obter mais informações, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do usuário do IAM*. + **Exigir autenticação multifator (MFA)** - se você tiver um cenário que exija usuários do IAM ou um usuário raiz na sua conta AWS, ative a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para obter mais informações, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do usuário do IAM*. Para obter mais informações sobre as práticas recomendadas do IAM, consulte [Práticas Recomendadas de Segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*. ## Usar o console do Amazon EKS Para acessar o console da Amazon EKS, uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) deve ter um conjunto mínimo de permissões. Essas permissões devem garantir à entidade principal concessão para visualizar os detalhes sobre os recursos da Amazon EKS na sua conta da AWS. Se você criar uma política baseada em identidade que seja mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para as entidades principais com essa política anexada. Para garantir que as entidades principais do IAM ainda possam usar o console do Amazon EKS, crie uma política com seu próprio nome exclusivo, como `AmazonEKSAdminPolicy`. Anexe a política às entidades principais. Para obter mais informações, consulte [Adicionar e remover permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) no *Guia do usuário do IAM*. **Importante** A política de exemplo a seguir permite que uma entidade principal visualize informações na guia **Configuração** do console. Para visualizar as informações nas guias **Visão geral** e **Recursos** no Console de gerenciamento da AWS, a entidade principal também precisa de permissões do Kubernetes. Para obter mais informações, consulte [Permissões obrigatórias](view-kubernetes-resources.md#view-kubernetes-resources-permissions). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "eks.amazonaws.com" } } } ] } ``` Não é necessário permitir permissões mínimas de console para os diretores que fazem chamadas apenas para a AWS CLI ou para a API da AWS. Em vez disso, permita o acesso somente às ações que correspondem à operação da API que você está tentando executar. ## Permitir que os usuários do IAM visualizem suas próprias permissões Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da AWS. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Crie um cluster do Kubernetes na Nuvem AWS Esta política de exemplo inclui as permissões mínimas necessárias para criar um cluster do Amazon EKS chamado *my-cluster* na região *us-west-2* AWS. Você pode substituir a região da AWS pela região da AWS na qual deseja criar um cluster. Se você receber um aviso informando que **As ações na sua política não são compatíveis com permissões em nível de recurso e exigem que você escolha `All resources`** no Console de gerenciamento da AWS, é possível ignorá-lo com segurança. Se sua conta já tiver o perfil *AWSServiceRoleForAmazonEKS*, você poderá remover a ação `iam:CreateServiceLinkedRole` da política. Se você já tiver criado um cluster do Amazon EKS em sua conta, esse perfil já existirá, a menos que você o tenha excluído. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS", "Condition": { "ForAnyValue:StringEquals": { "iam:AWSServiceName": "eks" } } }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" } ] } ``` ## Criar um cluster local do Kubernetes em um Outpost Essa política de exemplo inclui as permissões mínimas necessárias para criar um cluster local do Amazon EKS chamado *my-cluster* em um Outpost na região *us-west-2* da AWS. Você pode substituir a região da AWS pela região da AWS na qual deseja criar um cluster. Se você receber um aviso informando que **As ações na sua política não são compatíveis com permissões em nível de recurso e exigem que você escolha `All resources`** no Console de gerenciamento da AWS, é possível ignorá-lo com segurança. Se sua conta já tiver o perfil `AWSServiceRoleForAmazonEKSLocalOutpost`, você poderá remover a ação `iam:CreateServiceLinkedRole` da política. Se você já tiver criado um cluster local do Amazon EKS na sua conta, esse perfil já existirá, a menos que você o tenha excluído. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Action": [ "ec2:DescribeSubnets", "ec2:DescribeVpcs", "iam:GetRole" ], "Resource": "*", "Effect": "Allow" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost" }, { "Effect": "Allow", "Action": [ "iam:PassRole", "iam:ListAttachedRolePolicies" ], "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" }, { "Action": [ "iam:CreateInstanceProfile", "iam:TagInstanceProfile", "iam:AddRoleToInstanceProfile", "iam:GetInstanceProfile", "iam:DeleteInstanceProfile", "iam:RemoveRoleFromInstanceProfile" ], "Resource": "arn:aws:iam::*:instance-profile/eks-local-*", "Effect": "Allow" } ] } ``` ## Atualizar um cluster do Kubernetes Este exemplo de política inclui a permissão mínima necessária para atualizar um cluster chamado *my-cluster* na região us-west-2 AWS. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:UpdateClusterVersion", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" } ] } ``` ## Listar ou descrever todos os clusters Este exemplo de política inclui as permissões mínimas necessárias para listar e descrever todos os clusters na sua conta. Uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) deve ser capaz de listar e descrever clusters para usar o comando `update-kubeconfig` da AWS CLI. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` # Usar funções vinculadas ao serviço para o Amazon EKS O Amazon Elastic Kubernetes Service usa [perfis vinculados a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. **Topics** + [Usar funções para clusters do Amazon EKS](using-service-linked-roles-eks.md) + [Usar funções para grupos de nós do Amazon EKS](using-service-linked-roles-eks-nodegroups.md) + [Usar funções para os perfis do Amazon EKS Fargate](using-service-linked-roles-eks-fargate.md) + [Usar funções para conectar um cluster do Kubernetes ao Amazon EKS](using-service-linked-roles-eks-connector.md) + [Usar funções para clusters locais do Amazon EKS no Outpost](using-service-linked-roles-eks-outpost.md) + [Como usar perfis para o painel do Amazon EKS](using-service-linked-roles-eks-dashboard.md) # Usar funções para clusters do Amazon EKS O Amazon Elastic Kubernetes Service usa [perfis vinculados a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política não pode ser anexada a nenhuma outra entidade do IAM. Uma função vinculada ao serviço poderá ser excluída somente após excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com funções vinculadas aos serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Funções vinculadas aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKS`. O perfil permite que o Amazon EKS gerencie clusters em sua conta. As políticas anexadas permitem que a função gerencie os seguintes recursos: interfaces de rede, grupos de segurança, logs e VPCs. **nota** A função vinculada ao serviço `AWSServiceRoleForAmazonEKS` é distinta da função necessária para a criação do cluster. Para ter mais informações, consulte [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md). A função vinculada ao serviço `AWSServiceRoleForAmazonEKS` confia nos seguintes serviços para assumir a função: + `eks.amazonaws.com` A política de permissões da função permite que o Amazon EKS conclua as seguintes ações nos recursos especificados: + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criar uma função vinculada ao serviço para o Amazon EKS Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria um cluster no Console de gerenciamento da AWS, na AWS CLI ou na API AWS, o Amazon EKS cria o perfil vinculado a serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria um cluster, o Amazon EKS cria uma função vinculada ao serviço para você novamente. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKS`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um atributo ou serviço que requer uma função vinculada a serviço, é recomendável excluí-la. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, escolha **Clusters**. 1. Se o cluster tiver grupos de nós ou perfis do Fargate, você deverá excluí-los antes de excluir o cluster. Para ter mais informações, consulte [Excluir um grupo de nós gerenciados do seu cluster](delete-managed-node-group.md) e [Excluir um perfil do Fargate](delete-fargate-profile.md). 1. No**Clusters**Escolha o cluster que você quer excluir e escolha**Excluir**. 1. Digite o nome do cluster na janela de confirmação de exclusão e escolha **Delete** (Excluir) para excluir. 1. Repita esse procedimento para qualquer outro cluster na sua conta. Aguarde até que todas as operações de exclusão sejam concluídas. ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API da AWS para excluir a função vinculada ao serviço `AWSServiceRoleForAmazonEKS`. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a funções vinculadas a serviço do Amazon EKS O Amazon EKS oferece suporte a funções vinculadas a serviços em todas as regiões em que o serviço estiver disponível. Para obter mais informações, consulte [Endpoints e cotas do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html). # Usar funções para grupos de nós do Amazon EKS O Amazon EKS usa [perfis vinculados a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política não pode ser anexada a nenhuma outra entidade do IAM. Uma função vinculada ao serviço poderá ser excluída somente após excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com funções vinculadas aos serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Funções vinculadas aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKSNodegroup`. O perfil permite que o Amazon EKS gerencie grupos de nós em sua conta. A política `AWSServiceRoleForAmazonEKSNodegroup` anexada permite que o perfil gerencie os recursos a seguir: grupos do Auto Scaling, grupos de segurança, modelos de execução e perfis de instância do IAM. Para ter mais informações, consulte [Política gerenciada pela AWS: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). A função vinculada ao serviço `AWSServiceRoleForAmazonEKSNodegroup` confia nos seguintes serviços para assumir a função: + `eks-nodegroup.amazonaws.com` A política de permissões da função permite que o Amazon EKS conclua as seguintes ações nos recursos especificados: + [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html) Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criar uma função vinculada ao serviço para o Amazon EKS Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria o CreateNodegroup no Console de gerenciamento da AWS, na CLI AWS ou na API AWS, o Amazon EKS cria o perfil vinculada ao serviço para você. **Importante** Esse perfil vinculado ao serviço pode aparecer em sua conta se você concluiu uma ação em outro serviço que usa os atributos compatíveis com esse perfil. Se você estava usando o serviço do Amazon EKS antes de 1º de janeiro de 2017, quando ele começou a oferecer suporte a funções vinculadas ao serviço, o Amazon EKS criou a função AWSServiceRoleForAmazonEKSNodegroup na sua conta. Para saber mais, consulte [Uma nova função apareceu na minha conta do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). ### Criação de uma função vinculada ao serviço no Amazon EKS (API da AWS) Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria um grupo de nós gerenciados no Console de gerenciamento da AWS, na CLI AWS ou na API AWS, o Amazon EKS cria o perfil vinculada ao serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria outro grupo de nós gerenciados, o Amazon EKS cria a função vinculada ao serviço novamente para você. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKSNodegroup`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um atributo ou serviço que requer uma função vinculada a serviço, é recomendável excluí-la. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, escolha **Clusters**. 1. Selecione a guia **Compute** (Computação). 1. Na seção **Node groups** (Grupos de nós), escolha o grupo de nós a ser excluído. 1. Digite o nome do grupo de nós na janela de confirmação de exclusão e selecione **Delete** (Excluir) para excluir. 1. Repita esse procedimento para qualquer outro grupo de nós no cluster. Aguarde até que todas as operações de exclusão sejam concluídas. ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API da AWS para excluir a função vinculada ao serviço `AWSServiceRoleForAmazonEKSNodegroup`. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a funções vinculadas a serviço do Amazon EKS O Amazon EKS oferece suporte a funções vinculadas a serviços em todas as regiões em que o serviço estiver disponível. Para obter mais informações, consulte [Endpoints e cotas do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html). # Usar funções para os perfis do Amazon EKS Fargate O Amazon EKS usa [perfis vinculados a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política não pode ser anexada a nenhuma outra entidade do IAM. Uma função vinculada ao serviço poderá ser excluída somente após excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com funções vinculadas aos serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Funções vinculadas aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKSForFargate`. O perfil permite que o Fargate para Amazon EKS configure a rede da VPC necessária para pods do Fargate. As políticas anexadas permitem que a função crie e exclua interfaces de rede elástica e descreva recursos e interfaces de rede elástica. O perfil vinculado ao serviço `AWSServiceRoleForAmazonEKSForFargate` confia nos seguintes serviços para aceitar o perfil: + `eks-fargate.amazonaws.com` A política de permissões da função permite que o Amazon EKS conclua as seguintes ações nos recursos especificados: + [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html) Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criar uma função vinculada ao serviço para o Amazon EKS Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria um perfil do Fargate no Console de gerenciamento da AWS, na AWS CLI ou na API da AWS, o Amazon EKS cria o perfil vinculado a serviço para você. **Importante** Esse perfil vinculado ao serviço pode aparecer em sua conta se você concluiu uma ação em outro serviço que usa os atributos compatíveis com esse perfil. Se você estava usando o serviço do Amazon EKS antes de 13 de dezembro de 2019, quando ele começou a oferecer suporte a funções vinculadas ao serviço, o Amazon EKS criou a função AWSServiceRoleForAmazonEKSForFargate na sua conta. Para saber mais, consulte [Uma nova função apareceu na minha conta do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). ### Criação de uma função vinculada ao serviço no Amazon EKS (API da AWS) Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria um perfil do Fargate no Console de gerenciamento da AWS, na AWS CLI ou na API da AWS, o Amazon EKS cria o perfil vinculado a serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria outro grupo de nós gerenciados, o Amazon EKS cria a função vinculada ao serviço novamente para você. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKSForFargate`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um atributo ou serviço que requer uma função vinculada a serviço, é recomendável excluí-la. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, escolha **Clusters**. 1. Na página **Clusters**, selecione seu cluster. 1. Selecione a guia **Compute** (Computação). 1. Se houver algum perfil do Fargate na seção **Fargate profiles** (Perfis do Fargate), selecione cada um individualmente e, depois, **Delete** (Excluir). 1. Digite o nome do perfil na janela de confirmação de exclusão e escolha **Delete** (Excluir) para excluir. 1. Repita o procedimento para todos os perfis do Fargate no cluster e para outros clusters na sua conta. ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API AWS para excluir o perfil vinculada ao serviço AWSServiceRoleForAmazonEKSForFargate. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a funções vinculadas a serviço do Amazon EKS O Amazon EKS oferece suporte a funções vinculadas a serviços em todas as regiões em que o serviço estiver disponível. Para obter mais informações, consulte [Endpoints e cotas do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html). # Usar funções para conectar um cluster do Kubernetes ao Amazon EKS O Amazon EKS usa [perfis vinculados a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM. Um perfil vinculado ao serviço poderá ser excluído somente após excluir seus atributos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços que oferecem suporte a perfis vinculados ao serviço, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure pelos serviços que apresentam a afirmativa **Sim** na coluna **Perfil vinculado ao serviço**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKSConnector`. O perfil permite que o Amazon EKS conecte clusters do Kubernetes. As políticas anexadas permitem que o perfil gerencie os recursos necessários para se conectar ao cluster do Kubernetes registrado. O perfil vinculado ao serviço `AWSServiceRoleForAmazonEKSConnector` confia nos seguintes serviços para aceitar o perfil: + `eks-connector.amazonaws.com` A política de permissões da função permite que o Amazon EKS conclua as seguintes ações nos recursos especificados: + [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. Este perfil usa permissões do SSM (Systems Manager) para estabelecer conexões seguras e gerenciar clusters do Kubernetes conectados. ## Criar uma função vinculada ao serviço para o Amazon EKS Você não precisa criar manualmente uma função vinculada a serviço para se conectar a um cluster. Quando você conecta um cluster no Console de gerenciamento da AWS, no AWS CLI, no `eksctl` ou na API AWS, o Amazon EKS cria o perfil vinculada ao serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você conecta um cluster, o Amazon EKS cria uma função vinculada a serviço para você novamente. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKSConnector`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, escolha **Clusters**. 1. Na página **Clusters**, selecione seu cluster. 1. Selecione a guia **Deregister (Cancelar registro)** e, em seguida, selecione a guia **OK**. ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API do AWS para excluir o perfil vinculada ao serviço AWSServiceRoleForAmazonEKSConnector. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. # Usar funções para clusters locais do Amazon EKS no Outpost O Amazon Elastic Kubernetes Service usa [perfis vinculados a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política não pode ser anexada a nenhuma outra entidade do IAM. Uma função vinculada ao serviço poderá ser excluída somente após excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com funções vinculadas aos serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Funções vinculadas aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKSLocalOutpost`. O perfil permite que o Amazon EKS gerencie clusters locais em sua conta. As políticas anexadas permitem que a função gerencie os seguintes recursos: interfaces de rede, grupos de segurança, logs e instâncias do Amazon EC2. **nota** A função vinculada ao serviço `AWSServiceRoleForAmazonEKSLocalOutpost` é distinta da função necessária para a criação do cluster. Para ter mais informações, consulte [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md). A função vinculada ao serviço `AWSServiceRoleForAmazonEKSLocalOutpost` confia nos seguintes serviços para assumir a função: + `outposts.eks-local.amazonaws.com` A política de permissões da função permite que o Amazon EKS conclua as seguintes ações nos recursos especificados: + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criar uma função vinculada ao serviço para o Amazon EKS Não é necessário criar manualmente uma função vinculada ao serviço. Quando você cria um cluster no Console de gerenciamento da AWS, na AWS CLI ou na API AWS, o Amazon EKS cria o perfil vinculado a serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria um cluster, o Amazon EKS cria uma função vinculada ao serviço para você novamente. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKSLocalOutpost`. Depois que você criar um perfil vinculado ao serviço, não poderá alterar o nome do perfil, pois várias entidades podem fazer referência ao perfil. No entanto, será possível editar a descrição da função usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um atributo ou serviço que requer uma função vinculada a serviço, é recomendável excluí-la. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, escolha **Clusters** do Amazon EKS. 1. Se o cluster tiver grupos de nós ou perfis do Fargate, você deverá excluí-los antes de excluir o cluster. Para ter mais informações, consulte [Excluir um grupo de nós gerenciados do seu cluster](delete-managed-node-group.md) e [Excluir um perfil do Fargate](delete-fargate-profile.md). 1. No**Clusters**Escolha o cluster que você quer excluir e escolha**Excluir**. 1. Digite o nome do cluster na janela de confirmação de exclusão e escolha **Delete** (Excluir) para excluir. 1. Repita esse procedimento para qualquer outro cluster na sua conta. Aguarde até que todas as operações de exclusão sejam concluídas. ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API da AWS para excluir a função vinculada ao serviço `AWSServiceRoleForAmazonEKSLocalOutpost`. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a funções vinculadas a serviço do Amazon EKS O Amazon EKS oferece suporte a funções vinculadas a serviços em todas as regiões em que o serviço estiver disponível. Para obter mais informações, consulte [Endpoints e cotas do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html). # Como usar perfis para o painel do Amazon EKS O painel do Amazon EKS usa esse perfil vinculado ao serviço para agregar informações sobre os recursos de clusters de várias regiões e contas. O painel se integra ao AWS Organizations para ler com segurança as informações sobre várias contas em sua organização. Para saber mais sobre o painel do Amazon EKS, consulte [Visualizar dados agregados sobre recursos de cluster com o painel do EKS](cluster-dashboard.md). ## Contexto O Amazon EKS usa [perfis vinculados a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. Uma função vinculada ao serviço facilita a configuração do Amazon EKS porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EKS define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon EKS pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM. Um perfil vinculado ao serviço poderá ser excluído somente após excluir seus atributos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com funções vinculadas aos serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Funções vinculadas aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço. ## Permissões de função vinculada ao serviço para o Amazon EKS O Amazon EKS usa o perfil vinculado a serviço chamado `AWSServiceRoleForAmazonEKSDashboard`. O perfil permite que o Amazon EKS gere e exiba o painel do EKS, incluindo informações agregadas sobre os recursos de clusters. A política `AmazonEKSDashboardServiceRolePolicy` anexada permite que o perfil gerencie os recursos a seguir: grupos do Auto Scaling, grupos de segurança, modelos de execução e perfis de instância do IAM. Para obter mais informações, consulte [Política gerenciada pela AWS: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). A função vinculada ao serviço `AWSServiceRoleForAmazonEKSDashboard` confia nos seguintes serviços para assumir a função: + `dashboard.eks.amazonaws.com` Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) no Guia de referência de políticas gerenciadas pela AWS. Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para obter mais informações, consulte [Permissões de perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. ## Criar uma função vinculada ao serviço para o Amazon EKS Não é necessário criar manualmente uma função vinculada ao serviço. Ao habilitar o painel no Console da AWS, o Amazon EKS cria o perfil vinculado ao serviço para você. Para obter mais informações sobre como habilitar o painel do EKS, consulte [Configurar a integração do painel do EKS com o AWS Organizations](cluster-dashboard-orgs.md). **Importante** Esse perfil vinculado ao serviço pode aparecer em sua conta se você concluiu uma ação em outro serviço que usa os atributos compatíveis com esse perfil. ## Editar uma função vinculada ao serviço do Amazon EKS O Amazon EKS não permite que você edite a função vinculada ao serviço do `AWSServiceRoleForAmazonEKSDashboard`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para obter mais informações, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Excluir uma função vinculada ao serviço do Amazon EKS Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar suo perfil vinculado ao serviço para excluí-la manualmente. ### Limpar um perfil vinculado ao serviço Antes de usar o IAM para excluir uma função vinculada ao serviço, você deverá excluir qualquer recurso usado pela função. **nota** Se o serviço do Amazon EKS estiver usando a função quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. Para obter mais informações sobre como desabilitar o painel do EKS, consulte [Configurar a integração do painel do EKS com o AWS Organizations](cluster-dashboard-orgs.md). ### Excluir manualmente o perfil vinculado ao serviço Use o console do IAM, a AWS CLI ou a API da AWS para excluir a função vinculada ao serviço `AWSServiceRoleForAmazonEKSDashboard`. Para obter mais informações, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a funções vinculadas a serviço do Amazon EKS O Amazon EKS oferece suporte a funções vinculadas a serviços em todas as regiões em que o serviço estiver disponível. Para obter mais informações, consulte [Endpoints e cotas do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html). # Perfil do IAM de execução de pods do Amazon EKS O perfil de execução de pods do Amazon EKS é necessário para executar pods na infraestrutura do AWS Fargate. Quando o cluster cria pods na infraestrutura do AWS Fargate, os componentes que estão em execução nessa infraestrutura do Fargate devem fazer as chamadas para as APIs da AWS em seu nome. Isso é para que eles possam realizar ações como extrair imagens de contêiner do Amazon ECR ou encaminhar logs para outros serviços da AWS. O perfil de execução de pods do Amazon EKS fornece as permissões do IAM para fazer isso. Ao criar um perfil do Fargate, é necessário especificar um perfil de execução de pods para os componentes do Amazon EKS que são executados na infraestrutura do Fargate usando o perfil. Esse perfil é adicionado ao [Controle de acesso baseado em perfil](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) do Kubernetes do cluster para autorização. Isso permite que o `kubelet` que está sendo executado na infraestrutura do Fargate seja registrado no cluster do Amazon EKS para aparecer no cluster como um nó. **nota** O perfil do Fargate deve ter uma função do IAM diferente dos grupos de nós do Amazon EC2. **Importante** Os contêineres em execução no pod do Fargate não podem assumir as permissões do IAM associadas a um perfil de execução do pods. Para conceder aos contêineres no pod do Fargate permissões de acesso a outros serviços da AWS, é necessário usar os [perfis do IAM das contas de serviço](iam-roles-for-service-accounts.md). Antes de criar um perfil do Fargate, é necessário criar um perfil do IAM com [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html). ## Verifique se existe um perfil de execução de pods existente e configurado corretamente É possível usar o procedimento a seguir para verificar se a conta já tem um perfil de execução de pods do Amazon EKS corretamente configurado. Para evitar um problema de segurança de representante confuso, é importante que a função restrinja o acesso com base no `SourceArn`. É possível modificar a função de execução conforme necessário de forma a incluir suporte para perfis do Fargate em outros clusters. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Na página **Roles** (Funções), procure **AmazonEKSFargatePodExecutionRole** na lista de funções. Se a função não existir, consulte [Criar o perfil de execução de pods do Amazon EKS](#create-pod-execution-role) para criá-la. Se a função existir, escolha-a. 1. Na página **AmazonEKSFargatePodExecutionRole**, faça o seguinte: 1. Escolha **Permissões**. 1. Certifique-se de que a política gerenciada pela Amazon **AmazonEKSFargatePodExecutionRolePolicy** esteja associada ao perfil. 1. Escolha **Relações de Confiança**. 1. Escolha **Edit trust policy** (Editar política de confiança). 1. Na página **Edit trust policy** (Editar política de confiança), verifique se a relação de confiança contém a política a seguir e tem uma linha para perfis do Fargate no cluster. Em caso afirmativo, escolha **Cancel** (Cancelar). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Se a política corresponder, mas não tiver uma linha especificando os perfis do Fargate no seu cluster, será possível adicionar a seguinte linha sobre o objeto `ArnLike`. Substitua *region-code* pela região da AWS em que seu cluster está localizado, *111122223333* pelo ID da sua conta e *my-cluster* pelo nome do seu cluster. ``` "aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*", ``` Se a política não corresponder, copie a política anterior completa para o formulário e escolha **Atualizar política**. Substitua *region-code* pela região da AWS em que seu cluster se encontra. Se você quiser usar o mesmo perfil em todas as regiões da AWS da sua conta, substitua *region-code* por `*`. Substitua *111122223333* pelo ID da sua conta e *my-cluster* pelo nome do seu cluster. Se quiser usar o mesmo perfil para todos os clusters da sua conta, substitua *my-cluster* por `*`. ## Criar o perfil de execução de pods do Amazon EKS Se ainda não tiver o perfil de execução de pods do Amazon EKS para o cluster, será possível usar o Console de gerenciamento da AWS ou a AWS CLI para criá-lo. Console de gerenciamento da AWS 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Na página **Perfis**, selecione **Criar perfil**. 1. Na página **Selecionar entidade confiável**, faça o seguinte: 1. Na seção **Tipo de entidade confiável**), escolha **Service da AWS**. 1. Na lista suspensa **Casos de uso para outros serviços AWS**, escolha **EKS**. 1. Escolha **EKS - Pod do Fargate**. 1. Escolha **Próximo**. 1. Na página **Add permissions** (Adicionar permissões), escolha **Next** (Próximo). 1. Na página **Name, review, and create** (Nomear, revisar e criar), faça o seguinte: 1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `AmazonEKSFargatePodExecutionRole`. 1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*. 1. Selecione **Criar perfil**. 1. Na página **Roles** (Funções), procure **AmazonEKSFargatePodExecutionRole** na lista de funções. Escolha a função. 1. Na página **AmazonEKSFargatePodExecutionRole**, faça o seguinte: 1. Escolha **Relações de Confiança**. 1. Escolha **Edit trust policy** (Editar política de confiança). 1. Na página **Edit trust policy** (Editar política de confiança), faça o seguinte: 1. Copie e cole o conteúdo a seguir no formulário **Edit trust policy** (Editar política de confiança). Substitua *region-code* pela região da AWS em que seu cluster se encontra. Se você quiser usar o mesmo perfil em todas as regiões da AWS da sua conta, substitua *region-code* por `*`. Substitua *111122223333* pelo ID da sua conta e *my-cluster* pelo nome do seu cluster. Se quiser usar o mesmo perfil para todos os clusters da sua conta, substitua *my-cluster* por `*`. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Escolha **Atualizar política**. AWS CLI 1. Copie e cole o conteúdo a seguir em um arquivo denominado `pod-execution-role-trust-policy.json`. Substitua *region-code* pela região da AWS em que seu cluster se encontra. Se você quiser usar o mesmo perfil em todas as regiões da AWS da sua conta, substitua *region-code* por `*`. Substitua *111122223333* pelo ID da sua conta e *my-cluster* pelo nome do seu cluster. Se quiser usar o mesmo perfil para todos os clusters da sua conta, substitua *my-cluster* por `*`. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Crie um perfil do IAM de execução de pods. ``` aws iam create-role \ --role-name AmazonEKSFargatePodExecutionRole \ --assume-role-policy-document file://"pod-execution-role-trust-policy.json" ``` 1. Anexe a política do IAM gerenciada pelo Amazon EKS ao perfil. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \ --role-name AmazonEKSFargatePodExecutionRole ``` # Função do IAM do conector do Amazon EKS Você pode conectar clusters do Kubernetes para visualizá-los no Console de gerenciamento da AWS. Para se conectar a um cluster do Kubernetes, crie uma função do IAM. ## Verificar se já existe um perfil de conector do EKS Use o procedimento a seguir para verificar se a conta já tem a função de conector do Amazon EKS. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Pesquise na lista de perfis `AmazonEKSConnectorAgentRole`. Se não houver uma função que inclua `AmazonEKSConnectorAgentRole`, consulte [Criar a função do IAM para o agente de conector do Amazon EKS](#create-connector-role) para criar a função. Se houver uma função que inclua `AmazonEKSConnectorAgentRole`, selecione-a para visualizar as políticas anexadas. 1. Escolha **Permissões**. 1. Verifique se a política gerenciada **AmazonEKSConnectorAgentPolicy** está anexada ao perfil. Se a política estiver anexada, o perfil de conector do Amazon EKS estará configurado corretamente. 1. Escolha **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança). 1. Verifique se o relacionamento de confiança contém a seguinte política: Se o relacionamento de confiança corresponder à seguinte política, escolha **Cancel** (Cancelar). Se o relacionamento de confiança não corresponder, copie a política para a janela **Edit trust policy** (Editar política de confiança) e escolha **Update policy** (Atualizar política). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ## Criar a função do IAM para o agente de conector do Amazon EKS Você pode usar o Console de gerenciamento da AWS ou o AWS CloudFormation para criar o perfil de agente conector. AWS CLI 1. Crie um arquivo denominado `eks-connector-agent-trust-policy.json` que contenha o seguinte JSON para ser usado para a função do IAM: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` 1. Crie um arquivo denominado `eks-connector-agent-policy.json` que contenha o seguinte JSON para ser usado para a função do IAM. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SsmControlChannel", "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel" ], "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "ssmDataplaneOperations", "Effect": "Allow", "Action": [ "ssmmessages:CreateDataChannel", "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel" ], "Resource": "*" } ] } ``` 1. Crie a função de agente do Amazon EKS Connector usando a política de confiança e a política que você criou nos itens de lista anteriores. ``` aws iam create-role \ --role-name AmazonEKSConnectorAgentRole \ --assume-role-policy-document file://eks-connector-agent-trust-policy.json ``` 1. Anexe a política à função do agente do Amazon EKS Connector. ``` aws iam put-role-policy \ --role-name AmazonEKSConnectorAgentRole \ --policy-name AmazonEKSConnectorAgentPolicy \ --policy-document file://eks-connector-agent-policy.json ``` AWS CloudFormation 1. Salve o seguinte modelo do AWS CloudFormation em um arquivo de texto em seu sistema local. **nota** Esse modelo também cria a função vinculada ao serviço que seria criada quando a API `registerCluster` fosse chamada. Para mais detalhes, consulte [Usar funções para conectar um cluster do Kubernetes ao Amazon EKS](using-service-linked-roles-eks-connector.md). ``` --- AWSTemplateFormatVersion: '2010-09-09' Description: 'Provisions necessary resources needed to register clusters in EKS' Parameters: {} Resources: EKSConnectorSLR: Type: AWS::IAM::ServiceLinkedRole Properties: AWSServiceName: eks-connector.amazonaws.com EKSConnectorAgentRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: [ 'sts:AssumeRole' ] Principal: Service: 'ssm.amazonaws.com' EKSConnectorAgentPolicy: Type: AWS::IAM::Policy Properties: PolicyName: EKSConnectorAgentPolicy Roles: - {Ref: 'EKSConnectorAgentRole'} PolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Action: [ 'ssmmessages:CreateControlChannel' ] Resource: - Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*' - Effect: 'Allow' Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ] Resource: "*" Outputs: EKSConnectorAgentRoleArn: Description: The agent role that EKS connector uses to communicate with AWS services. Value: !GetAtt EKSConnectorAgentRole.Arn ``` 1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Escolha **Criar pilha** com novos recursos (padrão). 1. Para **Specify template (Especificar modelo)**, selecione **Upload a template file (Fazer upload de um arquivo de modelo)** e depois **Choose file (Escolher arquivo)**. 1. Selecione o arquivo que você criou anteriormente e, em seguida, selecione **Next (Próximo)**. 1. Em **Stack name (Nome da pilha)**, insira um nome para a função, como `eksConnectorAgentRole`, e selecione **Next (Próximo)**. 1. Na página **Configurar opções de pilha**, selecione **Avançar**. 1. Na página **Review (Revisão)**, reveja as informações, confirme se a pilha pode criar recursos do IAM e, em seguida, selecione **Create (Criar)**. # Políticas gerenciadas pela AWS para o Amazon Elastic Kubernetes Service Uma política gerenciada pela AWS é uma política autônoma criada e administrada pela AWS. As políticas gerenciadas pela AWS são criadas para fornecer permissões a vários casos de uso comuns e permitir a atribuição de permissões a usuários, grupos e perfis. Lembre-se de que as políticas gerenciadas pela AWS podem não conceder permissões de privilégio mínimo para casos de uso específicos porque estão disponíveis para todos os clientes da AWS usarem. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso. Não é possível alterar as permissões definidas em políticas gerenciadas pela AWS. Caso a AWS faça atualizações nas permissões estabelecidas em uma política gerenciada pela AWS, estas mudanças impactarão todas as identidades das entidades principais (usuários, grupos e perfis) vinculadas à esta política. A AWS é mais propensa a atualizar uma política gerenciada pela AWS durante o lançamento de um novo serviço da AWS ou quando novas operações de API estiverem disponíveis para serviços existentes. Para obter mais informações, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Manual do usuário do IAM*. ## Política gerenciada pela AWS: AmazonEKS\$1CNI\$1Policy É possível anexar a `AmazonEKS_CNI_Policy` às suas entidades do IAM. Antes de criar um grupo de nós do Amazon EC2, essa política deve ser anexada ao [perfil do IAM do nó](create-node-role.md) ou a um perfil do IAM que seja usado especificamente pelo plug-in CNI da Amazon VPC para Kubernetes. Isso é para que ele possa realizar ações em seu nome. Recomendamos que você anexe a política a um perfil usado apenas pelo plugin. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md) e [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2:*NetworkInterface` e `ec2:*PrivateIpAddresses` **: permite que o plug-in CNI da Amazon VPC execute ações, como o provisionamento de interfaces de rede elástica e de endereços IP para pods a fim de fornecer redes para as aplicações executadas no Amazon EKS. + **Ações de leitura do `ec2`**: permite que o plug-in CNI da Amazon VPC execute ações, como a descrição de instâncias e de sub-redes, para visualizar a quantidade de endereços IP disponíveis nas sub-redes da Amazon VPC. O plug-in CNI da VPC pode usar os endereços IP disponíveis em cada sub-rede para escolher as sub-redes com a maior quantidade de endereços IP disponíveis para usar ao criar uma interface de rede elástica. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) no Guia de referência de políticas gerenciadas da AWS. ## AWSPolítica gerenciada da : AmazonEKSClusterPolicy É possível anexar `AmazonEKSClusterPolicy` às entidades do IAM. Antes de criar um cluster, é preciso ter um [perfil do IAM para o cluster](cluster-iam-role.md) com esta política anexada. Os clusters do Kubernetes gerenciados pelo Amazon EKS fazem chamadas para outros serviços da AWS em seu nome. Eles fazem isso para gerenciar os recursos que você usa junto com o serviço. Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + **`autoscaling`**: leia e atualize a configuração de um grupo do Auto Scaling. Essas permissões não são usadas pelo Amazon EKS, mas permanecem na política para compatibilidade com versões anteriores. + ** `ec2` **: trabalhe com volumes e recursos de rede associados aos nós do Amazon EC2. Isso é necessário para que o ambiente de gerenciamento do Kubernetes possa unir instâncias a um cluster e provisionar e gerenciar dinamicamente os volumes do Amazon EBS solicitados por volumes persistentes do Kubernetes. + ** `ec2` **: exclua interfaces de rede elástica criadas pela CNI da VPC. Isso é necessário para que o EKS possa limpar as interfaces de rede elástica que serão esquecidas se a CNI da VPC for encerrada inesperadamente. + ** `elasticloadbalancing` **: trabalhe com Elastic Load Balancers e adicione nós a eles como alvos. Isso é necessário para que o plano de controle do Kubernetes possa provisionar dinamicamente o Elastic Load Balancers solicitado pelos serviços do Kubernetes. + ** `iam` **: crie um perfil vinculado ao serviço. Isso é necessário para que o ambiente de gerenciamento do Kubernetes possa provisionar dinamicamente o Elastic Load Balancers solicitado pelos serviços do Kubernetes. + ** `kms` **: leia uma chave do AWS KMS. Isso é necessário para que o ambiente de gerenciamento do Kubernetes suporte a [criptografia de segredos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) dos segredos do Kubernetes armazenados no `etcd`. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSDashboardConsoleReadOnly É possível anexar `AmazonEKSDashboardConsoleReadOnly` às entidades do IAM. Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `eks` **: acesso somente leitura às informações de versão do cluster, aos recursos e aos dados do painel do EKS. Isso permite visualizar as métricas relacionadas ao EKS e os detalhes da configuração do cluster. + ** `organizations` **: acesso somente leitura às informações do AWS Organizations, incluindo: + Visualização de detalhes da organização e acesso ao serviço + Listagem de raízes organizacionais, contas e unidades organizacionais + Visualização da estrutura da organização Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) no Guia de referência de políticas gerenciadas pela AWS. ## AWSPolítica gerenciada da : AmazonEKSFargatePodExecutionRolePolicy É possível anexar `AmazonEKSFargatePodExecutionRolePolicy` às entidades do IAM. Antes de criar um perfil do Fargate, é necessário criar um perfil de execução de pod do Fargate e anexar essa política a ele. Para obter mais informações, consulte [Etapa 2: criar um perfil de execução de pods do Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role) e [Definir quais pods usam o AWS Fargate quando iniciado](fargate-profile.md). Essa política concede ao perfil as permissões que fornecem acesso a outros recursos de serviços da AWS necessários para executar pods do Amazon EKS no Fargate. **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ecr` ** – permite que pods em execução no Fargate extraiam imagens de contêiner armazenadas no Amazon ECR. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSConnectorServiceRolePolicy Não é possível anexar `AmazonEKSConnectorServiceRolePolicy` às entidades do IAM. Esta política é anexada a uma função vinculada ao serviço que permite ao Amazon EKS realizar ações em seu nome. Para obter mais informações, consulte [Usar funções para conectar um cluster do Kubernetes ao Amazon EKS](using-service-linked-roles-eks-connector.md). O perfil permite que o Amazon EKS conecte clusters do Kubernetes. As políticas anexadas permitem que o perfil gerencie os recursos necessários para se conectar ao cluster do Kubernetes registrado. **Detalhes relacionados às permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + **`SSM Management`**: permite criar, descrever e excluir ativações do SSM, bem como cancelar o registro de instâncias gerenciadas. Isso viabiliza operações básicas do Systems Manager. + **`Session Management`**: permite iniciar sessões do SSM específicas para clusters de EKS e executar comandos não interativos por meio do documento AmazonEKS. + **`IAM Role Passing`**: permite a transferência de perfis do IAM especificamente para o serviço SSM, controlado por uma condição que restringe os perfis transferidos para `ssm.amazonaws.com`. + **`EventBridge Rules`**: permite criar regras e destinos no EventBridge somente quando gerenciados por `eks-connector.amazonaws.com`. As regras são especificamente limitadas ao AWS SSM como origem do evento. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) no Guia de referência de políticas gerenciadas pela AWS. ## AWSPolítica gerenciada da : AmazonEKSForFargateServiceRolePolicy Não é possível anexar `AmazonEKSForFargateServiceRolePolicy` às entidades do IAM. Esta política é anexada a uma função vinculada ao serviço que permite ao Amazon EKS realizar ações em seu nome. Para obter mais informações, consulte `AWSServiceRoleforAmazonEKSForFargate`. Esta política concede permissões necessárias ao Amazon EKS para executar tarefas do Fargate. A política só é usada se você tiver nós Fargate. **Detalhes relacionados às permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` ** – crie e exclua interfaces de rede elástica e descreva os recursos e interfaces de rede elástica. Isso é necessário para que o serviço Amazon EKS Fargate possa configurar a rede VPC necessária para Fargate Pods. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSComputePolicy É possível anexar `AmazonEKSComputePolicy` às entidades do IAM. É possível anexar essa política ao [perfil do IAM do cluster](cluster-iam-role.md) para expandir os recursos que o EKS pode gerenciar na sua conta. Essa política concede as permissões necessárias para o Amazon EKS criar e gerenciar instâncias do EC2 para o cluster de EKS, bem como as permissões do IAM necessárias para configurar o EC2. Além disso, essa política concede ao Amazon EKS as permissões para criar o perfil vinculado ao serviço de instâncias spot do EC2 em seu nome. ### Detalhes das permissões Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` Permissões do**: + `ec2:CreateFleet` e `ec2:RunInstances`: permitem criar instâncias do EC2 e usar recursos específicos do EC2 (imagens, grupos de segurança, sub-redes) para nós do cluster de EKS. + `ec2:CreateLaunchTemplate`: permite criar modelos de execução do EC2 para nós de cluster de EKS. + A política também inclui condições para restringir o uso dessas permissões do EC2 a recursos com tags com o nome do cluster de EKS e outras tags relevantes. + `ec2:CreateTags`: permite adicionar tags aos recursos do EC2 criados pelas ações `CreateFleet`, `RunInstances` e `CreateLaunchTemplate`. + ** `iam` Permissões do**: + `iam:AddRoleToInstanceProfile`: permite adicionar um perfil do IAM ao perfil de instância de computação do EKS. + `iam:PassRole`: permite passar os perfis do IAM necessários ao serviço do EC2. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada da AWS: AmazonEKSNetworkingPolicy É possível anexar `AmazonEKSNetworkingPolicy` às entidades do IAM. É possível anexar essa política ao [perfil do IAM do cluster](cluster-iam-role.md) para expandir os recursos que o EKS pode gerenciar na sua conta. Essa política foi projetada para conceder as permissões necessárias para o Amazon EKS criar e gerenciar interfaces de rede para o cluster de EKS, permitindo que o ambiente de gerenciamento e os nós de processamento se comuniquem e funcionem corretamente. ### Detalhes da permissão Essa política concede as seguintes permissões para permitir que o Amazon EKS gerencie interfaces de rede para o cluster: + ** `ec2` Permissões de interface de rede**: + `ec2:CreateNetworkInterface`: permite a criação de interfaces de rede do EC2. + A política inclui condições para restringir o uso dessa permissão a interfaces de rede marcadas com o nome do cluster de EKS e o nome do nó CNI do Kubernetes. + `ec2:CreateTags`: permite adicionar etiquetas às interfaces de rede criadas pela ação `CreateNetworkInterface`. + ** `ec2` Permissões de gerenciamento de interface de rede do**: + `ec2:AttachNetworkInterface`, `ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface`: permite conectar, modificar atributos de interfaces de rede e desconectar interfaces de rede de instâncias do EC2. + `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses`: permite gerenciar as atribuições de endereço IP das interfaces de rede. + Essas permissões são restritas às interfaces de rede marcadas com o nome do cluster de EKS. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSBlockStoragePolicy É possível anexar `AmazonEKSBlockStoragePolicy` às entidades do IAM. É possível anexar essa política ao [perfil do IAM do cluster](cluster-iam-role.md) para expandir os recursos que o EKS pode gerenciar na sua conta. Essa política concede as permissões necessárias para o Amazon EKS criar, gerenciar e manter volumes e snapshots do EC2 para o cluster de EKS, permitindo que o ambiente de gerenciamento e os nós de processamento provisionem e usem armazenamento persistente conforme exigido pelas workloads do Kubernetes. ### Detalhes da permissão Essa política do IAM concede as permissões a seguir para permitir que o Amazon EKS gerencie volumes e snapshots do EC2: + ** `ec2` Permissões de gerenciamento de volume do**: + `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores`: permitem anexar, desanexar, modificar e habilitar restaurações rápidas de instantâneos para volumes do EC2. + Essas permissões são restritas aos volumes com tag do nome do cluster de EKS. + `ec2:CreateTags`: permite adicionar tags aos volumes e snapshots do EC2 criados pelas ações `CreateVolume` e `CreateSnapshot`. + ** `ec2` Permissões de criação de volume do**: + `ec2:CreateVolume`: permite criar novos volumes do EC2. + A política inclui condições para restringir o uso dessa permissão a volumes com tags com o nome do cluster de EKS e outras tags relevantes. + `ec2:CreateSnapshot`: permite criar novos snapshots de volumes do EC2. + A política inclui condições para restringir o uso dessa permissão a snapshots com tags com o nome do cluster de EKS e outras tags relevantes. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSLoadBalancingPolicy É possível anexar `AmazonEKSLoadBalancingPolicy` às entidades do IAM. É possível anexar essa política ao [perfil do IAM do cluster](cluster-iam-role.md) para expandir os recursos que o EKS pode gerenciar na sua conta. Essa política do IAM concede as permissões necessárias para que o Amazon EKS trabalhe com vários serviços da AWS para gerenciar o Elastic Load Balancing (ELB) e recursos relacionados. ### Detalhes da permissão As principais permissões concedidas por essa política são: + ** `elasticloadbalancing` **: permite criar, modificar e gerenciar balanceadores de carga elásticos e grupos de destino. Isso inclui permissões para criar, atualizar e excluir balanceadores de carga, grupos de destino, receptores e regras. + ** `ec2` **: permite criar e gerenciar grupos de segurança, necessários para que o ambiente de gerenciamento do Kubernetes possa unir instâncias a um cluster e gerenciar os volumes do Amazon EBS. Além disso, possibilita descrever e listar recursos do EC2, como instâncias, VPCs, sub-redes, grupos de segurança e outros recursos de rede. + ** `iam` **: permite criar um perfil vinculado a serviço para o Elastic Load Balancing, que é necessário para que o ambiente de gerenciamento do Kubernetes provisione ELBs dinamicamente. + **`kms`**: permite a leitura de uma chave do AWS KMS, necessária para que o ambiente de gerenciamento do Kubernetes ofereça suporte à criptografia de segredos do Kubernetes armazenados no etcd. + **`wafv2`** e **`shield`**: permitem associar e desassociar ACLs da Web e criar/excluir proteções do AWS Shield para os balanceadores de carga elásticos. + **`cognito-idp`**, **`acm`** e **`elasticloadbalancing`**: concede permissões para descrever clientes do grupo de usuários, listar e descrever certificados e descrever grupos de destino, que são necessários para que o ambiente de gerenciamento do Kubernetes gerencie os balanceadores de carga elásticos. A política também inclui várias verificações de condição para garantir que as permissões tenham como escopo o cluster de EKS específico que está sendo gerenciado, usando a tag `eks:eks-cluster-name`. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSMCPReadOnlyAccess É possível anexar `AmazonEKSMCPReadOnlyAccess` às entidades do IAM. Essa política fornece acesso somente de leitura aos recursos do Amazon EKS e aos serviços da AWS relacionados, permitindo que o servidor do protocolo de contexto para modelos (MCP) do Amazon EKS execute operações de observabilidade e de solução de problemas sem realizar quaisquer modificações na infraestrutura. **Detalhes relacionados às permissões** Essa política inclui as seguintes permissões que possibilitam que as entidades principais realizem as seguintes tarefas: + **`eks`**: permite que as entidades principais descrevam e listem clusters de EKS, grupos de nós, complementos, entradas de acesso, insights, e acessem a API do Kubernetes para operações somente de leitura. + **`iam`**: permite que as entidades principais recuperem informações sobre perfis do IAM, políticas e seus anexos para entender as permissões associadas aos recursos do EKS. + **`ec2`**: permite que as entidades principais descrevam VPCs, sub-redes e tabelas de rotas para compreender a configuração de rede dos clusters de EKS. + **`sts`**: permite que as entidades principais recuperem informações de identidade do chamador para fins de autenticação e autorização. + **`logs`**: permite que as entidades principais iniciem consultas e recuperem os resultados de consultas do CloudWatch Logs para solução de problemas e monitoramento. + **`cloudwatch`**: permite que as entidades principais recuperem dados de métricas para monitorar a performance de clusters e workloads. + **`eks-mcp`**: permite que as entidades principais invoquem operações MCP e usem ferramentas somente de leitura dentro do servidor MCP do Amazon EKS. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSServicePolicy É possível anexar `AmazonEKSServicePolicy` às entidades do IAM. Os clusters criados antes de 16 de abril de 2020 exigiam que você criasse um perfil do IAM e associasse essa política a ele. Os clusters criados em ou após 16 de abril de 2020 não exigem que você crie um perfil nem que você atribua essa política. Quando você cria um cluster usando uma entidade principal do IAM que tem a permissão `iam:CreateServiceLinkedRole`, o perfil vinculado a serviço [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) é criado automaticamente para você. O perfil vinculada a serviço tem a [política gerenciada: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) anexada a ela. Essa política permite que o Amazon EKS crie e gerencie os recursos necessários para operar clusters do Amazon EKS. **Detalhes relacionados às permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `eks` ** – atualize a versão do Kubernetes do cluster depois de iniciar uma atualização. Essa permissão não é usada pelo Amazon EKS, mas permanece na política para compatibilidade com versões anteriores. + ** `ec2` ** – trabalhe com interfaces de rede elásticas e outros recursos e tags de rede. Isso é exigido pelo Amazon EKS para configurar redes que facilitem a comunicação entre nós e o ambiente de gerenciamento do Kubernetes. Leia informações sobre grupos de segurança. Atualize etiquetas em grupos de segurança. + ** `route53` ** – associe uma VPC a uma zona hospedada. Isso é exigido pelo Amazon EKS para habilitar a rede privada de endpoint para o seu servidor de API de cluster do Kubernetes. + ** `logs` ** – Eventos de log Isso é necessário para que o Amazon EKS possa enviar logs do plano de controle do Kubernetes para o CloudWatch. + ** `iam` ** – crie um perfil vinculado a serviço. Isso é necessário para que o Amazon EKS crie o perfil vinculado ao serviço [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) em seu nome. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSServiceRolePolicy Não é possível anexar `AmazonEKSServiceRolePolicy` às entidades do IAM. Esta política é anexada a uma função vinculada ao serviço que permite ao Amazon EKS realizar ações em seu nome. Para obter mais informações, consulte [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Quando você cria um cluster usando uma entidade principal do IAM que tem a permissão `iam:CreateServiceLinkedRole`, o perfil vinculado a serviço [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) é criado automaticamente para você e essa política é anexada a ele. Esta política permite que o perfil vinculado ao serviço chame serviços da AWS da em seu nome. **Detalhes relacionados às permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` ** – crie e descreva as interfaces de rede elástica e as instâncias do Amazon EC2, o grupo de segurança de cluster e VPC que são necessários para a criação de um cluster. Para obter mais informações, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). Leia informações sobre grupos de segurança. Atualize tags em grupos de segurança. Leia mais informações sobre reservas de capacidade sob demanda. Leia a configuração da VPC, incluindo tabelas de rotas e ACLs de rede, a fim de identificar problemas de configuração nos insights do cluster. + **Modo automático do `ec2`**: encerre instâncias do EC2 criadas pelo Modo automático do EKS. Para obter mais informações, consulte [Automatizar a infraestrutura de clusters com o Modo Automático do EKS](automode.md). + ** `iam` ** – liste todas as políticas gerenciadas anexadas a um perfil do IAM. Isso é necessário para que o Amazon EKS possa listar e validar todas as políticas gerenciadas e permissões necessárias para criar um cluster. + **Associar uma VPC a uma zona hospedada**: isso é exigido pelo Amazon EKS para habilitar a rede privada de endpoint para o seu servidor de API de cluster do Kubernetes. + **Evento de logs**: isso é necessário para que o Amazon EKS possa enviar logs do ambiente de gerenciamento do Kubernetes para o CloudWatch. + **Put metric**: isto é necessário para que o Amazon EKS possa enviar logs do ambiente de gerenciamento do Kubernetes para o CloudWatch. + **`eks`**: gerencia entradas e políticas de acesso ao cluster, permitindo um controle refinado sobre quem pode acessar os recursos do EKS e quais ações eles podem realizar. Isso inclui a associação de políticas de acesso padrão para operações de computação, rede, balanceamento de carga e armazenamento. + **`elasticloadbalancing`**: cria, gerencia e exclui balanceadores de carga e seus componentes (receptores, grupos de destino, certificados) associados aos clusters de EKS. Visualiza os atributos e o status de integridade do balanceador de carga. + **`events`**: cria e gerencia as regras do EventBridge para monitorar eventos do EC2 e do AWS Health relacionados aos clusters de EKS, permitindo respostas automatizadas às mudanças na infraestrutura e alertas de saúde. + **`iam`**: gerencia perfis de instância do EC2 com o prefixo "eks", incluindo a criação, exclusão e associação de perfis, o que é necessário para o gerenciamento de nós do EKS. Permite descrever qualquer perfil de instância para permitir que os usuários definam perfis de instância personalizados para uso por seus nós de processamento. + **`pricing`** **`shield`**: acessa as informações de preços da AWS e o status de proteção do Shield, permitindo o gerenciamento de custos e recursos avançados de segurança para os recursos do EKS. + **Limpeza de recursos**: exclui com segurança recursos marcados com tag do EKS, incluindo volumes, instantâneos, modelos de lançamento e interfaces de rede durante as operações de limpeza do cluster. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSVPCResourceController É possível anexar a política `AmazonEKSVPCResourceController` às suas identidades do IAM. Se estiver usando [grupos de segurança para Pods](security-groups-for-pods.md), será necessário anexar essa política à [perfil IAM do cluster do Amazon EKS](cluster-iam-role.md) para executar ações em seu nome. Esta política concede ao perfil do cluster permissões para gerenciar interfaces de rede elástica e endereços IP para nós. **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` ** – gerencie interfaces de rede elástica e endereços IP para ter compatibilidade com grupos de segurança de pods e nós do Windows. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSWorkerNodePolicy É possível anexar a `AmazonEKSWorkerNodePolicy` às suas entidades do IAM. É preciso anexar essa política a um [perfil do IAM do nó](create-node-role.md) que você especifica ao criar nós do Amazon EC2 que permitem ao Amazon EKS realizar ações em seu nome. Se você criar um grupo de nós usando `eksctl`, ele criará o perfil do nó do IAM e anexará essa política ao perfil automaticamente. Esta política concede aos nós Amazon EKS Amazon EC2 permissões para se conectar a clusters do Amazon EKS. **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` ** – leia o volume da instância e as informações de rede. Isso é necessário para que os nós do Kubernetes possam descrever informações sobre os recursos do Amazon EC2 necessários para o nó ingressar no cluster do Amazon EKS. + ** `eks` ** – opcionalmente, descreva o cluster como parte do bootstrapping do nó. + ** `eks-auth:AssumeRoleForPodIdentity` ** – permita a recuperação de credenciais para workloads do EKS no nó. Essa API é necessária para a Identidade de Pods do EKS funcionar corretamente. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSWorkerNodeMinimalPolicy É possível anexar o AmazonEKSWorkerNodeMinimalPolicy às suas entidades IAM. É possível anexar essa política a um perfil do IAM do nó que você especifica ao criar nós do Amazon EC2 que permitem ao Amazon EKS realizar ações em seu nome. Esta política concede aos nós Amazon EKS Amazon EC2 permissões para se conectar a clusters do Amazon EKS. Essa política tem menos permissões em comparação com a AmazonEKSWorkerNodePolicy. **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + `eks-auth:AssumeRoleForPodIdentity`: permita a recuperação de credenciais para workloads do EKS no nó. Essa API é necessária para a Identidade de Pods do EKS funcionar corretamente. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AWSServiceRoleForAmazonEKSNodegroup Não é possível anexar `AWSServiceRoleForAmazonEKSNodegroup` às entidades do IAM. Esta política é anexada a uma função vinculada ao serviço que permite ao Amazon EKS realizar ações em seu nome. Para obter mais informações, consulte [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups). Esta política concede a `AWSServiceRoleForAmazonEKSNodegroup` permissões de perfil que permitem que ele crie e gerencie grupos de nós do Amazon EC2 em sua conta. **Detalhes das permissões** Esta política inclui as permissões abaixo, que permitem ao Amazon EKS concluir as tarefas a seguir. + ** `ec2` ** – trabalhe com grupos de segurança, tags, reservas de capacidade e modelos de lançamento. Isso é necessário para grupos de nós gerenciados pelo Amazon EKS a fim de habilitar a configuração de acesso remoto e descrever reservas de capacidade que podem ser usadas em grupos de nós gerenciados. Além disso, os grupos de nós gerenciados do Amazon EKS criam um modelo de execução em seu nome. Isso serve para configurar o grupo do Amazon EC2 Auto Scaling que oferece suporte a cada grupo de nós gerenciados. + ** `iam` ** – crie um perfil vinculado a serviço e transmita um perfil. Isso é exigido pelos grupos de nós gerenciados do Amazon EKS para gerenciar perfis de instância para o perfil que está sendo passado ao criar um grupo de nós gerenciados. Esse perfil de instância é usado pelas instâncias do Amazon EC2 executadas como parte de um grupo de nós gerenciados. O Amazon EKS precisa criar perfis vinculados ao serviço para outros serviços, como os grupos do Amazon EC2 Auto Scaling. Essas permissões são usadas na criação de um grupo de nós gerenciados + ** `autoscaling` ** – trabalhe com grupos de segurança Auto Scaling. Isso é exigido pelos grupos de nós gerenciados do Amazon EKS para gerenciar o grupo do Amazon EC2 Auto Scaling que apoia cada grupo de nós gerenciados. Ele também é usado para oferecer suporte a funcionalidades como remover pods quando os nós são encerrados ou reciclados durante as atualizações de grupo de nós e gerenciar grupos de alta atividade em grupos de nós gerenciados. Para visualizar a versão mais recente do documento de política JSON, consulte [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSDashboardServiceRolePolicy Não é possível anexar `AmazonEKSDashboardServiceRolePolicy` às entidades do IAM. Esta política é anexada a uma função vinculada ao serviço que permite ao Amazon EKS realizar ações em seu nome. Para obter mais informações, consulte [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard). Esta política concede a `AWSServiceRoleForAmazonEKSDashboard` permissões de perfil que permitem que ele crie e gerencie grupos de nós do Amazon EC2 em sua conta. **Detalhes relacionados às permissões** Esta política inclui as permissões abaixo que permitem ao serviço realizar as seguintes tarefas: + ** `organizations`**: visualize informações sobre a estrutura e as contas do AWS Organizations. Isso inclui permissões para listar contas em sua organização, visualizar unidades organizacionais e raízes, listar administradores delegados, visualizar serviços que têm acesso à sua organização e recuperar informações detalhadas sobre sua organização e contas. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEBSCSIDriverPolicy A política `AmazonEBSCSIDriverPolicy` permite que o driver Container Storage Interface (CSI) do Amazon EBS crie, modifique, copie, anexe, desanexe e exclua volumes em seu nome. Isso inclui a modificação de etiquetas em volumes existentes e a habilitação da restauração rápida de snapshot (FSR) em volumes do EBS. Ele também concede permissões ao driver da CSI do EBS para criar, bloquear, restaurar e excluir snapshots, bem como listar as instâncias, os volumes e os snapshots. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEFSCSIDriverPolicy A política `AmazonEFSCSIDriverPolicy` permite que a Container Storage Interface (CSI) do Amazon EFS crie e exclua pontos de acesso em seu nome. Ela também concede ao driver CSI do Amazon EFS permissões para listar os sistemas de arquivos, destinos de montagem e zonas de disponibilidade do Amazon EC2 dos seus pontos de acesso. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Política gerenciada pela AWS: AmazonEKSLocalOutpostClusterPolicy Essa política pode ser anexada a entidades do IAM. Antes de criar um cluster local, você precisa anexar essa política ao [perfil do cluster](cluster-iam-role.md). Os clusters do Kubernetes gerenciados pelo Amazon EKS fazem chamadas para outros serviços da AWS em seu nome. Eles fazem isso para gerenciar os recursos que você usa junto com o serviço. A política `AmazonEKSLocalOutpostClusterPolicy` inclui as seguintes permissões: + **Ações de leitura do `ec2`**: permite que as instâncias do ambiente de gerenciamento descrevam as propriedades da zona de disponibilidade, da tabela de rotas, da instância e da interface de rede. Permissões necessárias para que as instâncias do Amazon EC2 ingressem com êxito no cluster como instâncias do ambiente de gerenciamento. + ** `ssm` ** – permite a conexão do Amazon EC2 Systems Manager com a instância do ambiente de gerenciamento, que é usada pelo Amazon EKS para se comunicar e gerenciar o cluster local na sua conta. + ** `logs` ** – permite que as instâncias enviem logs para o Amazon CloudWatch. + **`secretsmanager`**: permite que as instâncias obtenham e excluam dados de bootstrap para as instâncias do ambiente de gerenciamento com segurança no AWS Secrets Manager . + ** `ecr` ** – permite que pods e contêineres em execução nas instâncias do ambiente de gerenciamento extraiam imagens de contêineres armazenadas no Amazon Elastic Container Registry. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) no Guia de referência de políticas gerenciadas pela AWS. ## Política gerenciada pela AWS: AmazonEKSLocalOutpostServiceRolePolicy Não é possível anexar essa política a suas entidades do IAM. Quando você cria um cluster usando uma entidade principal do IAM que tem a permissão `iam:CreateServiceLinkedRole`, o Amazon EKS cria automaticamente o perfil vinculado a serviço [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks-outpost.md) para você e essa política é anexada a ele. Essa política permite que o perfil vinculado ao serviço chame produtos da AWS em seu nome para clusters locais. A política `AmazonEKSLocalOutpostServiceRolePolicy` inclui as seguintes permissões: + ** `ec2` ** – permite que o Amazon EKS trabalhe com segurança, com a rede e com outros recursos para iniciar e gerenciar com êxito instâncias do ambiente de gerenciamento na sua conta. + ** `ssm`, `ssmmessages` ** – permite a conexão do Amazon EC2 Systems Manager com as instâncias do ambiente de gerenciamento, que é usada pelo Amazon EKS para se comunicar e gerenciar o cluster local na sua conta. + ** `iam` ** – permite que o Amazon EKS gerencie o perfil de instância associado às instâncias do ambiente de gerenciamento. + **`secretsmanager`**: permite que o Amazon EKS coloque dados de bootstrap para as instâncias do ambiente de gerenciamento no AWS Secrets Manager para que ele possa ser referenciado com segurança durante o bootstrapping da instância. + ** `outposts` ** – permite que o Amazon EKS obtenha informações do Outpost de sua conta para lançar com êxito um cluster local em um Outpost. Para visualizar a versão mais recente do documento de política JSON, consulte [AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) no Guia de referência de políticas gerenciadas da AWS. ## Atualizações do Amazon EKS para políticas gerenciadas pela AWS Visualize detalhes sobre atualizações em políticas gerenciadas pela AWS para o Amazon EKS, desde que este serviço começou a monitorar essas alterações. Para receber notificações de todas as alterações do arquivo de origem nesta página específica da documentação, você pode se inscrever no seguinte URL com um leitor de RSS: ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom ``` | Alteração | Descrição | Data | | --- | --- | --- | | Adicionada uma permissão a [Política gerenciada da AWS: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | Permissão `ec2:ModifyNetworkInterfaceAttribute` adicionada em `AmazonEKSNetworkingPolicy`. Isso permite que o Controlador do Modo Automático do Amazon EKS modifique os atributos da interface de rede relacionados às instâncias do EC2 | 3 de fevereiro de 2026 | | Foram adicionadas permissões a [Política gerenciada pela AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Foram adicionadas as permissões `autoscaling:PutWarmPool`, `autoscaling:DeleteWarmPool` e `autoscaling:DescribeWarmPool` a `AWSServiceRoleForAmazonEKSNodegroup`. Isso permite que os grupos de nós gerenciados do Amazon EKS gerenciem os recursos subjacentes do grupo de alta atividade do ASG em todo o ciclo de vida do grupo de nós. | 17 de fevereiro de 2026 | | Foi adicionada a permissão para a política . [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Foi removido o requisito do prefixo “eks” no nome do perfil de instância de destino para a permissão `iam:GetInstanceProfile` em `AmazonEKSServiceRolePolicy`. Essa ação permite que o Amazon EKS Auto Mode valide e utilize os perfis de instância personalizados em NodeClasses sem exigir o prefixo de nomenclatura “eks”. | 2 de fevereiro de 2026 | | Permissões adicionadas à [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | A permissão `ec2:LockSnapshot` foi adicionada para permitir que o driver CSI do EBS realize o bloqueio de snapshots do EBS diretamente. | 15 de janeiro de 2026 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | O Amazon EKS introduziu a nova política gerenciada `AmazonEKSMCPReadOnlyAccess` para habilitar ferramentas somente de leitura no servidor MCP do Amazon EKS para observabilidade e solução de problemas. | 21 de novembro de 2025 | | Permissões adicionadas à [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Foi adicionada a permissão `ec2:CopyVolumes`, possibilitando que o driver CSI do EBS realize a cópia direta de volumes do EBS. | 17 de novembro de 2025 | | Foi adicionada a permissão para a política . [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Foram adicionadas as permissões `ec2:DescribeRouteTables` e `ec2:DescribeNetworkAcls` para a política `AmazonEKSServiceRolePolicy`. Isso permite que o Amazon EKS detecte problemas de configuração em tabelas de rotas da VPC e ACLs de rede para nós híbridos, como parte dos insights do cluster. | 22 de outubro de 2025 | | Foi adicionada uma permissão à política [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md). | Foi adicionada a permissão `ssmmessages:OpenDataChannel` para a política `AmazonEKSConnectorServiceRolePolicy`. | 15 de outubro de 2025 | | Foi adicionada a permissão para a política . [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | Esse perfil pode anexar uma nova política de acesso `AmazonEKSEventPolicy`. Permissões restritas para `ec2:DeleteLaunchTemplate` e `ec2:TerminateInstances`. | 26 de agosto de 2025 | | Adicionada uma permissão a [Política gerenciada pela AWS: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Adicionada a permissão `ssmmessages:OpenDataChannel` a `AmazonEKSLocalOutpostServiceRolePolicy`. | 26 de junho de 2025 | | Adicionada uma permissão a [Política gerenciada pela AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Permissões de recursos atualizadas para as ações `ec2:RunInstances` e `ec2:CreateFleet` para incluir reservas de capacidade ` arn:aws:ec2:*:*:capacity-reservation/*`. Isso permite que o Modo automático do Amazon EKS inicialize instâncias usando as reservas de capacidade sob demanda do EC2 em sua conta. Adicionado `iam:CreateServiceLinkedRole` para permitir que o Modo automático do Amazon EKS crie o perfil `AWSServiceRoleForEC2Spot` vinculado ao serviço de instâncias spot do EC2 em seu nome. | 20 de junho de 2025 | | Adicionada uma permissão à [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Adicionada a permissão `ec2:DescribeCapacityReservations` para permitir que o Modo automático do Amazon EKS inicialize instâncias usando as reservas de capacidade sob demanda do EC2 em sua conta. | 20 de junho de 2025 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Introdução da nova política `AmazonEKSDashboardConsoleReadOnly`. | 19 de junho de 2025 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Introduziu a nova política `AmazonEKSDashboardServiceRolePolicy`. | 21 de maio de 2025 | | Permissões adicionadas à [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Adicionada a permissão `ec2:DeleteNetworkInterfaces` para possibilitar que o Amazon EKS exclua interfaces de rede elásticas que serão esquecidas se a CNI da VPC for encerrada inesperadamente. | 16 de abril de 2025 | | Adicionada uma permissão à política [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Adicionadas as permissões `ec2:RevokeSecurityGroupEgress` e `ec2:AuthorizeSecurityGroupEgress` para possibilitar que os clientes de IA e ML do EKS adicionem regras de saída de grupos de segurança ao grupo de segurança padrão do cluster de EKS que sejam compatíveis com o EFA, como parte do lançamento da versão 1.33 do EKS. | 14 de abril de 2025 | | Permissões adicionadas à [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Adicionada permissão para encerrar instâncias do EC2 criadas pelo Modo automático do EKS. | 28 de fevereiro de 2025 | | Permissões adicionadas à [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Foi adicionada uma nova declaração autorizando o driver da CSI do EBS a restaurar todos os snapshots. Anteriormente, isso era permitido pela política existente, mas uma nova declaração explícita se faz necessária devido a uma alteração no gerenciamento do IAM para `CreateVolume`. Foi adicionada a capacidade para o driver da CSI do EBS modificar tags em volumes existentes. O driver CSI do EBS pode modificar as tags de volumes existentes por meio dos parâmetros em VolumeAttributesClasses do Kubernetes. Foi adicionada a capacidade para o driver da CSI do EBS habilitar a restauração rápida de snapshot (FSR) em volumes do EBS. O driver CSI do EBS pode habilitar a FSR em novos volumes por meio de parâmetros nas classes de armazenamento do Kubernetes. | 13 de janeiro de 2025 | | Permissões adicionadas à [Política gerenciada pela AWS: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | A política `AmazonEKSLoadBalancingPolicy` foi atualizada para possibilitar a listagem e descrição de recursos de rede e endereços IP. | 26 de dezembro de 2024 | | Foram adicionadas permissões a [Política gerenciada pela AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Foi atualizado o `AWSServiceRoleForAmazonEKSNodegroup` para compatibilidade com as regiões da China. | 22 de novembro de 2024 | | Permissões adicionadas à [Política gerenciada pela AWS: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | Foi adicionada a permissão `ec2:DescribeAvailabilityZones` a `AmazonEKSLocalOutpostClusterPolicy` para que o AWS Cloud Controller Manager no ambiente de gerenciamento do cluster possa identificar a zona de disponibilidade em que cada nó está. | 21 de novembro de 2024 | | Foram adicionadas permissões a [Política gerenciada pela AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Foi atualizada a política `AWSServiceRoleForAmazonEKSNodegroup` para permitir `ec2:RebootInstances` para instâncias criadas por grupos de nós gerenciados pelo Amazon EKS. Foram restringidas as permissões `ec2:CreateTags` para recursos do Amazon EC2. | 20 de novembro de 2024 | | Foram adicionadas permissões a [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | O EKS atualizou a política gerenciada `AmazonEKSServiceRolePolicy` da AWS. Foram adicionadas permissões para políticas de acesso ao EKS, gerenciamento de balanceador de carga e limpeza automatizada de recursos de cluster. | 16 de novembro de 2024 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | O EKS atualizou a política gerenciada `AmazonEKSComputePolicy` da AWS. Foram atualizadas as permissões de recurso para a ação `iam:AddRoleToInstanceProfile`. | 7 de novembro de 2024 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | A AWS introduziu a `AmazonEKSComputePolicy`. | 1.º de novembro de 2024 | | Permissões adicionadas à `AmazonEKSClusterPolicy` | Foi adicionada a permissão `ec2:DescribeInstanceTopology` para permitir que o Amazon EKS anexe informações de topologia ao nó como rótulos. | 1.º de novembro de 2024 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS A introduziu a `AmazonEKSBlockStoragePolicy`. | 30 de outubro de 2024 | | Introduzido em [Política gerenciada pela AWS: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS A introduziu a `AmazonEKSLoadBalancingPolicy`. | 30 de outubro de 2024 | | Foram adicionadas permissões ao [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Foram adicionadas permissões `cloudwatch:PutMetricData` para permitir que o Amazon EKS publique métricas no Amazon CloudWatch. | 29 de outubro de 2024 | | Introduzido em [Política gerenciada da AWS: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS A introduziu a `AmazonEKSNetworkingPolicy`. | 28 de outubro de 2024 | | Foram adicionadas permissões para `AmazonEKSServicePolicy` e `AmazonEKSServiceRolePolicy` | Adição de `ec2:GetSecurityGroupsForVpc` e permissões de etiqueta associadas para permitir que o EKS leia as informações do grupo de segurança e atualize as etiquetas relacionadas. | 10 de outubro de 2024 | | Introdução da [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS A introduziu a `AmazonEKSWorkerNodeMinimalPolicy`. | 3 de outubro de 2024 | | Permissões adicionadas para [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Foram adicionadas as permissões `autoscaling:ResumeProcesses` e `autoscaling:SuspendProcesses` para permitir que o Amazon EKS suspenda e retome o `AZRebalance` em grupos do Auto Scaling gerenciados pelo Amazon EKS. | 21 de agosto de 2024 | | Permissões adicionadas para [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | A permissão `ec2:DescribeCapacityReservations` foi adicionada para que o Amazon EKS possa descrever a reserva de capacidade na conta do usuário. A permissão `autoscaling:PutScheduledUpdateGroupAction` foi adicionada para permitir a configuração da escalabilidade programada em grupos de nós `CAPACITY_BLOCK`. | 27 de junho de 2024 | | [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy): atualização de uma política existente | O Amazon EKS adicionou novas permissões `ec2:DescribeSubnets` para permitir que o plug-in CNI da Amazon VPC para Kubernetes identifique a quantidade de endereços IP disponíveis nas sub-redes da Amazon VPC. O plug-in CNI da VPC pode usar os endereços IP disponíveis em cada sub-rede para escolher as sub-redes com a maior quantidade de endereços IP disponíveis para usar ao criar uma interface de rede elástica. | 4 de março de 2024 | | [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy): atualização de uma política existente | O Amazon EKS adicionou novas permissões para permitir a Identidade de Pods do EKS. O atentende de Identidade de Pods do Amazon EKS usa o perfil de nó. | 26 de novembro de 2023 | | Introdução da [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS A introduziu a `AmazonEFSCSIDriverPolicy`. | 26 de julho de 2023 | | Permissões adicionadas à [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | A permissão `ec2:DescribeAvailabilityZones` foi adicionada para permitir que o Amazon EKS obtenha os detalhes da AZ durante a descoberta automática de sub-redes ao criar balanceadores de carga. | 7 de fevereiro de 2023 | | Condições da política [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) foram atualizadas. | Foram removidas as condições de política inválidas com caracteres curingas no campo de chave `StringLike`. Também foi adicionada uma nova condição `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` a `ec2:DeleteVolume`, que permite que o driver da CSI do EBS exclua volumes criados pelo plug-in em árvore. | 17 de novembro de 2022 | | Adicionadas permissões à [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Adicionados `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` e `ec2:DescribeSecret` para permitir melhor validação de pré-requisitos e controle gerenciado do ciclo de vida. Também foram adicionados `ec2:DescribePlacementGroups` e `"arn:aws:ec2:*:*:placement-group/*"` a `ec2:RunInstances` para permitir controle de colocação das instâncias do Amazon EC2 do ambiente de gerenciamento no Outposts. | 24 de outubro de 2022 | | Atualize as permissões do Amazon Elastic Container Registry em [AmazoneKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Movida a ação `ecr:GetDownloadUrlForLayer` de todas as seções de recurso para uma seção com escopo definido. Adicionado o recurso ` arn:aws:ecr:*:*:repository/eks/ `. Removido o recurso ` arn:aws:ecr:`. Esse recurso é coberto pelo recurso ` arn:aws:ecr:*:*:repository/eks/*` adicionado. | 20 de outubro de 2022 | | Permissões adicionadas à [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Adicionado o repositório do Amazon Elastic Container Registry ` arn:aws:ecr:*:*:repository/kubelet-config-updater` para que as instâncias do ambiente de gerenciamento do cluster possam atualizar alguns argumentos `kubelet`. | 31 de agosto de 2022 | | Apresentada a [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS A introduziu a `AmazonEKSLocalOutpostClusterPolicy`. | 24 de agosto de 2022 | | Apresentada a [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS A introduziu a `AmazonEKSLocalOutpostServiceRolePolicy`. | 23 de agosto de 2022 | | Introdução da [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | A AWS apresentou o `AmazonEBSCSIDriverPolicy`. | 4 de abril de 2022 | | Adição de permissões a [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | Adição de `ec2:DescribeInstanceTypes` para habilitar AMIs otimizadas para do Amazon EKS que podem detectar propriedades em nível de instâncias automaticamente. | 21 de março de 2022 | | Permissões adicionadas para [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | A permissão `autoscaling:EnableMetricsCollection` foi adicionada para que o Amazon EKS possa habilitar a coleta de métricas. | 13 de dezembro de 2021 | | Permissões adicionadas para [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | As permissões `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses` e `ec2:DescribeInternetGateways` foram adicionadas para permitir que o Amazon EKS crie um perfil vinculado ao serviço para um Network Load Balancer. | 17 de junho de 2021 | | O Amazon EKS passou a monitorar as alterações. | O Amazon EKS passou a controlar as alterações para as políticas gerenciadas da AWS. | 17 de junho de 2021 | # Solução de problemas do IAM Este tópico aborda alguns erros comuns que você pode encontrar ao usar o Amazon EKS com o IAM e como resolvê-los. ## AccessDeniedException Se você receber um `AccessDeniedException` ao chamar uma operação de API da AWS, é porque as credenciais da [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que estão sendo usadas não têm as permissões necessárias para faze essa chamada. ``` An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:iam::111122223333:user/user_name is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster ``` No exemplo de mensagem anterior, o usuário não tem permissões para chamar a operação da API `DescribeCluster` do Amazon EKS. Para conceder permissões de administrador do Amazon EKS a uma entidade principal do IAM, consulte [Exemplos de políticas baseadas em identidade do Amazon EKS](security-iam-id-based-policy-examples.md). Para obter mais informações sobre o IAM, consulte [Controlling access using policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) (Controlar o acesso usando políticas) no *Manual do usuário do IAM*. ## Não é possível ver **Nodes** (Nós) na guia **Compute** (Computação) ou qualquer coisa na guia **Resources** (Recursos), e você recebe um erro no Console de gerenciamento da AWS Você pode ver uma mensagem de erro do console informando `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Verifique se o usuário da [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) com o qual você está usando o Console de gerenciamento da AWS tem as permissões necessárias. Para obter mais informações, consulte [Permissões obrigatórias](view-kubernetes-resources.md#view-kubernetes-resources-permissions). ## O aws-auth `ConfigMap` não concede acesso ao cluster O [AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) não permite um caminho no ARN da função usado no `ConfigMap`. Portanto, antes de especificar `rolearn`, remova o caminho. Por exemplo, altere ` arn:aws:iam::111122223333:role/team/developers/eks-admin ` para ` arn:aws:iam::111122223333:role/eks-admin `. ## Não estou autorizado a executar iam:PassRole Se receber uma mensagem de erro informando que você não tem autorização para executar a ação `iam:PassRole`, suas políticas devem ser atualizadas para permitir a transmissão de um perfil ao Amazon EKS. Alguns serviços da AWS permitem que você passe uma função existente para o serviço, em vez de criar um novo perfil de serviço ou perfil vinculado ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço. O erro exemplificado a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta usar o console para executar uma ação no Amazon EKS. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço. ``` User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`. Se você precisar de ajuda, entre em contato com seu administrador AWS. Seu administrador é a pessoa que forneceu suas credenciais de login. ## Quero permitir que pessoas fora da minha conta da AWS acessem meus recursos do Amazon EKS É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem compatibilidade com políticas baseadas em recursos ou listas de controle de acesso (ACLs), é possível usar essas políticas para conceder às pessoas acesso aos seus recursos. Para saber mais, consulte: + Para saber se o Amazon EKS oferece suporte a esses recursos, consulte [Como o Amazon EKS funciona com o IAM](security-iam-service-with-iam.md). + Para saber como conceder acesso a seus recursos em todas as contas da AWS pertencentes a você, consulte [Fornecimento de acesso a um usuário do IAM em outra conta da AWS pertencente a você](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia de Usuário do IAM*. + Para saber como conceder acesso aos recursos para contas da AWS de terceiros, consulte [Fornecer acesso a contas da AWS pertencentes a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*. + Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*. + Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. ## Os contêineres do pod recebem o seguinte erro: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region` Seus contêineres receberão esse erro se a aplicação estiver explicitamente fazendo solicitações ao endpoint global do AWS STS (`https://sts.amazonaws`) e sua conta de serviço do Kubernetes estiver configurada para usar um endpoint regional. É possível resolver o problema com uma das seguintes opções: + Atualize o código da aplicação para remover chamadas explícitas para o endpoint global AWS STS. + Atualize o código da aplicação para fazer chamadas explícitas para endpoints regionais, como `https://sts.us-west-2.amazonaws.com`. Seu aplicação deve ter redundância incorporada para escolher uma região AWS diferente em caso de falha do serviço na região AWS. Para obter mais informações, consulte [Gerenciar o AWS STS em uma região da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html), no Guia do usuário do IAM. + Configure as suas contas de serviço para utilizar o endpoint global. Os clusters usam o endpoint regional por padrão. Para obter mais informações, consulte [Configurar o endpoint do AWS Security Token Service para uma conta de serviço](configure-sts-endpoint.md). # Função do IAM 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. Antes de criar clusters do Amazon EKS, você deve criar uma função do IAM com uma das seguintes políticas do IAM: + [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) + Uma política do IAM personalizada. As permissões mínimas a seguir permitem que o cluster do Kubernetes gerencie nós, mas não permitem que o [provedor de nuvem legado](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) crie balanceadores de carga com o Elastic Load Balancing. Sua política do IAM personalizada deve ter pelo menos as seguintes permissões: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "kubernetes.io/cluster/*" } } }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DescribeDhcpOptions", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstanceTopology", "kms:DescribeKey" ], "Resource": "*" } ] } ``` **nota** Antes de 3 de outubro de 2023, [AmazoneksClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) era exigido no perfil do IAM para cada cluster. Antes de 16 de abril de 2020, [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) e [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) eram obrigatórios, e o nome sugerido para o perfil era `eksServiceRole`. Com o perfil vinculado ao serviço `AWSServiceRoleForAmazonEKS`, a política [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) não será mais necessária para clusters criados em ou após 16 de abril de 2020. ## Verificar se há uma função de cluster existente É possível usar o procedimento a seguir para verificar se a conta já tem a função do cluster do Amazon EKS. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Pesquise na lista de perfis `eksClusterRole`. Se não houver uma função que inclua `eksClusterRole`, consulte [Criar uma função para o cluster do Amazon EKS](#create-service-role) para criar a função. Se houver uma função que inclua `eksClusterRole`, selecione-a para visualizar as políticas anexadas. 1. Escolha **Permissões**. 1. Verifique se a política gerenciada **AmazonEKSClusterPolicy** está anexada à função. Se a política estiver anexada, a função do cluster do Amazon EKS estará configurada corretamente. 1. Escolha **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança). 1. Verifique se o relacionamento de confiança contém a seguinte política: Se o relacionamento de confiança corresponder à seguinte política, escolha **Cancel** (Cancelar). Se o relacionamento de confiança não corresponder, copie a política para a janela **Edit trust policy** (Editar política de confiança) e escolha **Update policy** (Atualizar política). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Criar uma função para o cluster do Amazon EKS Você pode usar o Console de gerenciamento da AWS ou a CLI AWS para criar o perfil de cluster. Console de gerenciamento da AWS 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. Escolha **Roles (Funções)** e, em seguida, **Create Role (Criar função)**. 1. Em **Tipo de entidade confiável**, selecione **Serviço da AWS**. 1. Na lista suspensa **Casos de uso para outros serviços AWS**, escolha **EKS**. 1. Escolha **EKS - Cluster** para o caso de uso e escolha **Next** (Próximo). 1. Na guia **Add permissions** (Adicionar permissões), escolha **Next** (Próximo). 1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `eksClusterRole`. 1. Em **Description** (Descrição), insira um texto descritivo, como `Amazon EKS - Cluster role`. 1. Selecione **Criar perfil**. AWS CLI 1. Copie o conteúdo a seguir em um arquivo chamado *cluster-trust-policy.json*. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Crie a função. Você pode substituir *eksClusterRole* por qualquer nome que desejar. ``` aws iam create-role \ --role-name eksClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. Anexe a política do IAM necessária à função. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \ --role-name eksClusterRole ``` # Perfil do IAM em nós do Amazon EKS O daemon `kubelet` do nó do Amazon EKS chama as APIs da AWS em seu nome. Os nós recebem permissões para essas chamadas de API por meio de um perfil de instância do IAM e políticas associadas. Antes de iniciar os nós e registrá-los em um cluster, você deve criar um perfil do IAM para uso desses nós quando eles forem iniciados. Esse requisito se aplica a nós executados com a AMI otimizada para Amazon EKS fornecida pela Amazon ou com qualquer outra AMI do nó que você pretende usar. Além disso, este requisito se aplica tanto aos grupos de nós gerenciados quanto aos nós autogerenciados. **nota** Não é possível usar a mesma função usada para criar clusters. Antes de criar os nós, é necessário criar um perfil do IAM com as seguintes permissões: + Permissões para que o `kubelet` descreva os recursos do Amazon EC2 na VPC, como as fornecidas pela política [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html). Esta política também fornece as permissões para o Amazon EKS Pod Identity Agent. + Permissões para que o `kubelet` use imagens de contêiner do Amazon Elastic Container Registry (Amazon ECR), como as fornecidas pela política [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html). As permissões para usar imagens de contêiner do Amazon Elastic Container Registry (Amazon ECR) são necessárias porque os complementos integrados para a rede executam pods que usam imagens de contêiner do Amazon ECR. + (Opcional) Permissões para que o Amazon EKS Pod Identity Agent use a ação `eks-auth:AssumeRoleForPodIdentity` para recuperar credenciais para pods. Se você não usa a [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), então forneça esta permissão adicionalmente às permissões do EC2 para usar a Identidade de Pods do EKS. + (Opcional) Caso não use a Identidade de Pods do EKA ou IRSA para conceder permissões aos pods da CNI da VPC, forneça permissões para a CNI da VPC no perfil da instância. Você pode usar a política gerenciada [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) (caso tenha criado o cluster com a família `IPv4`) ou uma [política destinada a IPv6 criada por você](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (caso tenha criado o cluster com a família `IPv6`). Contudo, em vez de anexar a política à essa função, recomendamos que você anexe a política a uma função separada usada especificamente para o complemento CNI da Amazon VPC. Para obter mais informações sobre a criação de uma função separada para o complemento CNI da Amazon VPC, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). **nota** Os grupos de nós do Amazon EC2 devem ter uma função do IAM diferente do perfil do Fargate. Para obter mais informações, consulte [Perfil do IAM de execução de pods do Amazon EKS](pod-execution-role.md). ## Verificar se há uma função existente do nó Use o procedimento a seguir para verificar se a conta já tem a função de nó do Amazon EKS. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Procure `eksNodeRole`, `AmazonEKSNodeRole` ou `NodeInstanceRole` na lista de funções. Se não houver uma função com um desses nomes, consulte [Criação de uma função para a função do IAM de nó do Amazon EKS](#create-worker-node-role) para criar a função. Se houver uma função que contenha `eksNodeRole`, `AmazonEKSNodeRole` ou `NodeInstanceRole`, selecione-a para visualizar as políticas anexadas. 1. Escolha **Permissões**. 1. Certifique-se de que as políticas gerenciadas **AmazonEKSWorkerNodePolicy** e **AmazonEC2ContainerRegistryPullOnly** estejam anexadas à perfil ou que uma política personalizada esteja anexada com as permissões mínimas. **nota** Se o**AmazonEKS\$1CNI\$1Policy**estiver anexada à função, recomendamos removê-la e anexá-la a uma função do IAM mapeada para o`aws-node`Em vez disso, a conta do serviço Kubernetes. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). 1. Escolha **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança). 1. Verifique se o relacionamento de confiança contém a seguinte política: Se o relacionamento de confiança corresponder à seguinte política, escolha **Cancel** (Cancelar). Se o relacionamento de confiança não corresponder, copie a política para a janela **Edit trust policy** (Editar política de confiança) e escolha **Update policy** (Atualizar política). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` ## Criação de uma função para a função do IAM de nó do Amazon EKS Você pode criar o perfil IAM do nó com o Console de gerenciamento da AWS ou com a CLI AWS. Console de gerenciamento da AWS 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Na página **Perfis**, selecione **Criar perfil**. 1. Na página **Selecionar entidade confiável**, faça o seguinte: 1. Na seção **Tipo de entidade confiável**), escolha **Service da AWS**. 1. Em **Use case** (Caso de uso), selecione **EC2**. 1. Escolha **Próximo**. 1. Na página **Add permissions (Adicionar permissões)**, faça o seguinte: 1. Na caixa **Filtrar políticas** insira `AmazonEKSWorkerNodePolicy`. 1. Marque a caixa de seleção à esquerda de **AmazonEKSWorkerNodePolicy** nos resultados da pesquisa. 1. Escolha **Clear filters** (Limpar filtros). 1. Na caixa **Filtrar políticas** insira `AmazonEC2ContainerRegistryPullOnly`. 1. Marque a caixa de seleção à esquerda de **AmazonEC2ContainerRegistryPullOnly** nos resultados da pesquisa. A política gerenciada **AmazonEKS\$1CNI\$1Policy** ou uma [política de IPv6](cni-iam-role.md#cni-iam-role-create-ipv6-policy) que você criar também deverá ser anexada a esse perfil ou a um perfil diferente que seja mapeado para a conta de serviço `aws-node` do Kubernetes. Recomendamos atribuir a política à função associada à conta de serviço do Kubernetes em vez de atribuí-la a essa função. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). 1. Escolha **Próximo**. 1. Na página **Name, review, and create** (Nomear, revisar e criar), faça o seguinte: 1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `AmazonEKSNodeRole`. 1. Em **Description** (Descrição), substitua o texto atual por um texto descritivo como `Amazon EKS - Node role`. 1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*. 1. Selecione **Criar perfil**. AWS CLI 1. Execute o seguinte comando para criar o arquivo `node-role-trust-relationship.json`. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` 1. Crie o perfil do IAM. ``` aws iam create-role \ --role-name AmazonEKSNodeRole \ --assume-role-policy-document file://"node-role-trust-relationship.json" ``` 1. Anexe duas políticas do IAM gerenciadas necessárias à função do IAM. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \ --role-name AmazonEKSNodeRole aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \ --role-name AmazonEKSNodeRole ``` 1. Anexe uma das seguintes políticas do IAM à função do IAM, dependendo de com qual família de IP você criou o seu cluster. A política deve ser anexada a esse perfil ou a um perfil associado à conta de serviço `aws-node` do Kubernetes, que é usada para o plug-in CNI da Amazon VPC para Kubernetes. Recomendamos atribuir a política à função associada à conta de serviço do Kubernetes. Para atribuir a política à função associada à conta de serviço do Kubernetes, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). + IPv4 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name AmazonEKSNodeRole ``` + IPv6 1. Copie o texto a seguir e salve-o em um arquivo chamado `vpc-cni-ipv6-policy.json`. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignIpv6Addresses", "ec2:DescribeInstances", "ec2:DescribeTags", "ec2:DescribeNetworkInterfaces", "ec2:DescribeInstanceTypes" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ] } ] } ``` 1. Crie a política do IAM. ``` aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json ``` 1. Anexe a política do IAM à função do IAM. Substitua *111122223333* pelo ID da sua conta. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \ --role-name AmazonEKSNodeRole ``` # Perfil do IAM do cluster do Modo Automático 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 automatizar tarefas de rotina de armazenamento, rede e ajuste de escala automático de computação. Antes de criar clusters do Amazon EKS, é necessário criar um perfil do IAM com as políticas necessárias a seguir do Modo Automático do EKS. Você pode anexar as políticas gerenciadas pelo AWS IAM sugeridas ou criar políticas personalizadas com permissões equivalentes. + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) ## Verificar se há uma função de cluster existente É possível usar o procedimento a seguir para verificar se a conta já tem a função do cluster do Amazon EKS. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Pesquise na lista de perfis `AmazonEKSAutoClusterRole`. Se um perfil que inclua `AmazonEKSAutoClusterRole` não existir, consulte as instruções na próxima seção para criar o perfil. Se houver uma função que inclua `AmazonEKSAutoClusterRole`, selecione-a para visualizar as políticas anexadas. 1. Escolha **Permissões**. 1. Verifique se a política gerenciada **AmazonEKSClusterPolicy** está anexada à função. Se a política estiver anexada, a função do cluster do Amazon EKS estará configurada corretamente. 1. Escolha **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança). 1. Verifique se o relacionamento de confiança contém a seguinte política: Se o relacionamento de confiança corresponder à seguinte política, escolha **Cancel** (Cancelar). Se o relacionamento de confiança não corresponder, copie a política para a janela **Edit trust policy** (Editar política de confiança) e escolha **Update policy** (Atualizar política). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` **nota** A AWS não exige o nome `AmazonEKSAutoClusterRole` para esse perfil. ## Criar uma função para o cluster do Amazon EKS Você pode usar o Console de gerenciamento da AWS ou a CLI AWS para criar o perfil de cluster. ### Console de gerenciamento da AWS 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. Escolha **Roles (Funções)** e, em seguida, **Create Role (Criar função)**. 1. Em **Tipo de entidade confiável**, selecione **Serviço da AWS**. 1. Na lista suspensa **Casos de uso para outros serviços AWS**, escolha **EKS**. 1. Escolha **EKS - Cluster** para o caso de uso e escolha **Next** (Próximo). 1. Na guia **Adicionar permissões**, selecione as políticas e escolha **Próximo**. + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) 1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `AmazonEKSAutoClusterRole`. 1. Em **Description** (Descrição), insira um texto descritivo, como `Amazon EKS - Cluster role`. 1. Selecione **Criar perfil**. ### AWS CLI 1. Copie o conteúdo a seguir em um arquivo chamado *cluster-trust-policy.json*. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 1. Crie a função. Você pode substituir *AmazonEKSAutoClusterRole* por qualquer nome que desejar. ``` aws iam create-role \ --role-name AmazonEKSAutoClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. Anexe as políticas do IAM necessárias ao perfil: **AmazonEKSClusterPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy ``` **AmazonEKSComputePolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy ``` **AmazonEKSBlockStoragePolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy ``` **AmazonEKSLoadBalancingPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy ``` **AmazonEKSNetworkingPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy ``` # Perfil do IAM do nó do Modo Automático do Amazon EKS **nota** Não é possível usar a mesma função usada para criar clusters. Antes de criar os nós, é necessário criar um perfil do IAM com as seguintes políticas, ou permissões equivalentes: + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) ## Verificar se há uma função existente do nó Use o procedimento a seguir para verificar se a conta já tem a função de nó do Amazon EKS. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Pesquise na lista de perfis `AmazonEKSAutoNodeRole`. Se não houver um perfil com um desses nomes, consulte as instruções na próxima seção para criar o perfil. Se houver uma função que contenha `AmazonEKSAutoNodeRole`, selecione a função para visualizar as políticas anexadas. 1. Escolha **Permissões**. 1. Certifique-se de que as políticas necessárias acima estejam anexadas, ou políticas personalizadas equivalentes. 1. Escolha **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança). 1. Verifique se o relacionamento de confiança contém a seguinte política: Se o relacionamento de confiança corresponder à seguinte política, escolha **Cancel** (Cancelar). Se o relacionamento de confiança não corresponder, copie a política para a janela **Edit trust policy** (Editar política de confiança) e escolha **Update policy** (Atualizar política). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Criação de uma função para a função do IAM de nó do Amazon EKS Você pode criar o perfil IAM do nó com o Console de gerenciamento da AWS ou com a CLI AWS. ### Console de gerenciamento da AWS 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Na página **Perfis**, selecione **Criar perfil**. 1. Na página **Selecionar entidade confiável**, faça o seguinte: 1. Na seção **Tipo de entidade confiável**), escolha **Service da AWS**. 1. Em **Use case** (Caso de uso), selecione **EC2**. 1. Escolha **Próximo**. 1. Na página **Adicionar permissões**, anexe as seguintes políticas: + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) 1. Na página **Name, review, and create** (Nomear, revisar e criar), faça o seguinte: 1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `AmazonEKSAutoNodeRole`. 1. Em **Description** (Descrição), substitua o texto atual por um texto descritivo como `Amazon EKS - Node role`. 1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*. 1. Selecione **Criar perfil**. ### AWS CLI **Criar o perfil do IAM do nó** Use o arquivo **node-trust-policy.json** da etapa anterior para definir quais entidades podem assumir o perfil. Execute o seguinte comando para criar o perfil do IAM do nó: ``` aws iam create-role \ --role-name AmazonEKSAutoNodeRole \ --assume-role-policy-document file://node-trust-policy.json ``` **Registrar o ARN do perfil** Depois de criar o perfil, recupere e salve o ARN do perfil do IAM do nó. Você precisará desse ARN nas etapas subsequentes. Use o seguinte comando para obter o ARN: ``` aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text ``` **Anexar as políticas obrigatórias** Anexe as seguintes políticas gerenciadas pela AWS ao perfil do IAM do nó para fornecer as permissões necessárias: Para anexar a política AmazonEKSWorkerNodeMinimalPolicy: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy ``` Para anexar a política AmazonEC2ContainerRegistryPullOnly: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` # Perfil do IAM para a funcionalidade do Amazon EKS As funcionalidades do EKS exigem a configuração de um perfil do IAM para a funcionalidade (ou perfil da funcionalidade). As funcionalidades usam esse perfil para realizar ações em serviços da AWS e para acessar recursos do Kubernetes no cluster por meio de entradas de acesso criadas automaticamente. Antes que você possa especificar um perfil da funcionalidade durante a criação desta, é necessário criar o perfil do IAM com a política de confiança e as permissões adequadas ao tipo de funcionalidade. Assim que este perfil do IAM for criado, ele poderá ser reaproveitado para qualquer quantidade de recursos da funcionalidade. ## Requisitos do perfil da funcionalidade O perfil da funcionalidade deve atender aos seguintes requisitos: + O perfil deve estar na mesma conta da AWS que o cluster e o recurso da funcionalidade + O perfil deve ter uma política de confiança que permita ao serviço de funcionalidades do EKS assumir o perfil + O perfil deve ter permissões apropriadas para o tipo de funcionalidade e para os requisitos do caso de uso (consulte [Permissões por tipo de funcionalidade](#capability-permissions)) ## Política de confiança para perfis da funcionalidade Todos os perfis da funcionalidade devem incluir a seguinte política de confiança: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "capabilities.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` Esta política de confiança autoriza o EKS a: + Assumir o perfil para executar operações de API da AWS + Marcar sessões para fins de auditoria e rastreamento ## Permissões por tipo de funcionalidade As permissões do IAM exigidas variam conforme a funcionalidade que você usa e o modelo de implantação. **nota** Para implantações em ambientes de produção usando seletores de perfil do IAM com o ACK, ou ao usar o kro ou o Argo CD sem integração com serviços da AWS, o perfil da funcionalidade talvez não requeira permissões do IAM além da política de confiança. **kro (Kube Resource Orchestrator)** Não são necessárias permissões do IAM. É possível criar um perfil da funcionalidade sem políticas vinculadas. O kro requer apenas permissões de RBAC do Kubernetes para a criação e o gerenciamento de recursos do Kubernetes. ** AWS Controlllers for Kubernetes (ACK) da)** O ACK fornece suporte a dois modelos de permissão: + **Configuração simples para ambientes de desenvolvimento e teste**: adicione permissões para os serviços da AWS diretamente ao perfil da funcionalidade. Esta opção é ideal para começar a usar, em implantações realizadas em uma única conta ou quando todos os usuários necessitam das mesmas permissões. + **Prática recomendada para ambientes de produção**: use seletores de perfil do IAM para implementar o acesso de privilégio mínimo. Com essa abordagem, o perfil da funcionalidade precisa apenas da permissão `sts:AssumeRole` para assumir perfis específicos de serviço. Você não adiciona permissões de serviços da AWS (como o S3 ou o RDS) diretamente ao perfil da funcionalidade. Essas permissões são concedidas a perfis do IAM individuais que são mapeados para namespaces específicos. Os seletores de perfil do IAM permitem: + Isolamento de permissões em nível de namespace + Gerenciamento de recursos entre contas + Perfis do IAM exclusivos para cada equipe + Modelo de segurança com privilégio mínimo Exemplo de política de perfil da funcionalidade para a abordagem de seletor de perfil do IAM: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/ACK-S3-Role", "arn:aws:iam::111122223333:role/ACK-RDS-Role", "arn:aws:iam::444455556666:role/ACKCrossAccountRole" ] } ] } ``` Para obter detalhes sobre a configuração de permissões do ACK, incluindo os seletores de perfil do IAM, consulte [Configuração das permissões do ACK](ack-permissions.md). **Argo CD** Por padrão, nenhuma permissão do IAM é necessária. Entretanto, permissões adicionais podem ser exigidas para: + **AWS Secrets Manager**: se estiver usando o Secrets Manager para armazenar credenciais de repositório do Git + **AWS CodeConnections**: se usar o CodeConnections para realizar autenticação em repositórios do Git Exemplo de política para o Secrets Manager e para o CodeConnections: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*" }, { "Effect": "Allow", "Action": [ "codeconnections:UseConnection", "codeconnections:GetConnection" ], "Resource": "arn:aws:codeconnections:region:account-id:connection/*" } ] } ``` Para obter detalhes sobre os requisitos da permissão do Argo CD, consulte [Considerações sobre o Argo CD](argocd-considerations.md). ## Verificação da existência de um perfil da funcionalidade Você pode usar o procedimento apresentado a seguir para verificar se a conta já tem um perfil do IAM para a funcionalidade que seja adequado ao seu caso de uso. 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. No painel de navegação à esquerda, escolha **Funções**. 1. Pesquise na lista de perfis pelo nome do perfil da funcionalidade (por exemplo, `ACKCapabilityRole` ou `ArgoCDCapabilityRole`). 1. Se um perfil existir, selecione-o para visualizar as políticas anexadas e a relação de confiança. 1. Escolha **Relações de confiança** e, em seguida, escolha **Editar política de confiança**. 1. Verifique se a relação de confiança corresponde à [política de confiança da funcionalidade](#capability-trust-policy). Se não houver correspondência, atualize a política de confiança. 1. Selecione a guia **Permissões** e valide se o perfil conta com as permissões adequadas ao seu tipo de funcionalidade e às necessidades do caso de uso. ## Criação de um perfil do IAM para a funcionalidade É possível usar o Console de gerenciamento da AWS ou a AWS CLI para a criação de um perfil da funcionalidade. ** Console de gerenciamento da AWS ** 1. Abra o console do IAM em https://console.aws.amazon.com/iam/. 1. Escolha **Roles (Funções)** e, em seguida, **Create Role (Criar função)**. 1. Em **Tipo de entidade confiável**, selecione **Política de confiança personalizada**. 1. Copie e cole a [política de confiança da funcionalidade](#capability-trust-policy) no editor de política de confiança. 1. Escolha **Próximo**. 1. Na guia **Adicionar permissões**, selecione ou crie as políticas apropriadas para o seu tipo de funcionalidade (consulte [Permissões por tipo de funcionalidade](#capability-permissions)). Para o kro, você pode pular esta etapa. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira um nome exclusivo para o seu perfil, como`ACKCapabilityRole`, `ArgoCDCapabilityRole` ou `kroCapabilityRole`. 1. Em **Description** (Descrição), insira um texto descritivo, como `Amazon EKS - ACK capability role`. 1. Selecione **Criar perfil**. ** AWS CLI** 1. Copie a [política de confiança da funcionalidade](#capability-trust-policy) para um arquivo chamado `capability-trust-policy.json`. 1. Crie a função. Substitua `ACKCapabilityRole` pelo nome de perfil desejado. ``` aws iam create-role \ --role-name ACKCapabilityRole \ --assume-role-policy-document file://capability-trust-policy.json ``` 1. Anexe as políticas do IAM necessárias ao perfil. Para o ACK, anexe as políticas dos serviços da AWS que você deseja gerenciar. Para o Argo CD, anexe políticas para o Secrets Manager ou CodeConnections, se necessário. Para o kro, você pode pular esta etapa. Exemplo para o ACK com permissões de S3: ``` aws iam put-role-policy \ --role-name ACKCapabilityRole \ --policy-name S3Management \ --policy-document file://s3-policy.json ``` ## Solução de problemas em perfis da funcionalidade **Criação da funcionalidade apresentou falhas com o erro “Perfil do IAM inválido"** Verificar se: + O perfil existe na mesma conta que o cluster + A política de confiança corresponde à [política de confiança da funcionalidade](#capability-trust-policy) + Você conta com a permissão `iam:PassRole` para o perfil **Funcionalidade apresenta erros de permissão** Verificar se: + O perfil tem as permissões do IAM necessárias para o tipo de funcionalidade + A entrada de acesso existe no cluster para o perfil + As permissões adicionais do Kubernetes estão configuradas, se necessário (consulte [Permissões adicionais do Kubernetes](capabilities-security.md#additional-kubernetes-permissions)) **Recursos do ACK apresentam falhas com erros de “Permissão negada** Verificar se: + O perfil tem as permissões do IAM necessárias para o caso de uso + Para controladores do ACK que referenciam segredos, certifique-se de ter associado a política de entrada de acesso `AmazonEKSSecretReaderPolicy` com escopo para os namespaces apropriados. Para obter mais orientações sobre a solução de problemas, consulte [Considerações sobre segurança para funcionalidades do EKS](capabilities-security.md).