Criar entradas de acesso

Considerações

Antes de criar entradas de acesso, considere o seguinte:

• Um modo de autenticação definido corretamente. Consulte Alterar o modo de autenticação para usar entradas de acesso.

• Uma entrada de acesso inclui o nome do recurso da Amazon (ARN) de uma, e somente uma, entidade principal do IAM existente. Uma entidade principal do IAM não pode ser incluída em mais de uma entrada de acesso. Considerações adicionais para o ARN especificado por você:

  • As práticas recomendadas do IAM sugerem que você acesse o cluster usando perfis do IAM que têm credenciais de curto prazo, em vez de usuários do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte Exija que os usuários humanos usem a federação com um provedor de identidades para acessar a AWS usando credenciais temporárias no Guia do usuário do IAM.

  • Se o ARN for para um perfil do IAM, ele pode incluir um caminho. Os ARNs nas entradas ConfigMap aws-auth não podem incluir um caminho. Por exemplo, seu ARN pode ser arn:aws:iam::111122223333:role/development/apps/my-role ou arn:aws:iam::111122223333:role/my-role.

  • Se o tipo da entrada de acesso for diferente de STANDARD (consulte a próxima consideração sobre os tipos), o ARN deverá estar na mesma Conta da AWS em que seu cluster está. Se o tipo for STANDARD, o ARN poderá estar na mesma Conta da AWS, ou outra diferente, da conta em que seu cluster está.

  • Não é possível alterar a entidade principal do IAM depois que a entrada de acesso é criada.

  • Se você alguma vez você excluir a entidade principal do IAM com esse ARN, a entrada de acesso não será excluída automaticamente. Recomendamos que você exclua a entrada de acesso com um ARN para uma entidade principal do IAM que você exclua. Se você não excluir a entrada de acesso e nunca recriar a entidade principal do IAM, mesmo que ela tenha o mesmo ARN, a entrada de acesso não funcionará. Isto ocorre porque, embora o ARN seja o mesmo para a entidade principal do IAM recriado, o roleID ou userID (você pode ver isso com o comando aws sts get-caller-identity da AWS CLI) é diferente para a entidade principal do IAM recriada do que foi para a entidade principal do IAM original. Mesmo que você não veja o roleID ou userID da entidade principal do IAM para uma entrada de acesso, o Amazon EKS o armazena com a entrada de acesso.

• Cada entrada de acesso tem um tipo. Você pode especificar EC2 Linux (para um perfil do IAM usado com nós autogerenciados do Linux ou do Bottlerocket), EC2 Windows (para perfis do IAM usados com nós autogerenciados do Windows), FARGATE_LINUX (para perfis do IAM usados com AWS Fargate (Fargate)) ou STANDARD como um tipo. Se você não especificar um tipo, o Amazon EKS definirá automaticamente o tipo como STANDARD. Não é necessário criar uma entrada de acesso para um perfil do IAM usado para um grupo de nós gerenciados ou um perfil do Fargate, porque o Amazon EKS adiciona entradas para essas funções ao ConfigMap aws-auth, independentemente da versão da plataforma em que seu cluster esteja.

  Não é possível alterar o tipo depois que a entrada de acesso é criada.

• Se o tipo da entrada de acesso for STANDARD, será possível especificar um nome de usuário para a entrada de acesso. Se você não especificar um valor para o nome de usuário, o Amazon EKS definirá um dos valores a seguir para você, dependendo do tipo de entrada de acesso e de se a entidade principal do IAM que você especificou é um perfil do IAM ou um usuário do IAM. A menos que você tenha um motivo específico para determinar seu próprio nome de usuário, recomendamos que não especifique um e deixe o Amazon EKS gerá-lo automaticamente para você. Se você especificar seu próprio nome de usuário:

  • Não pode começar com system:, eks:, aws:, amazon: ouiam:.

  • Se o nome de usuário for para um perfil do IAM, recomendamos que você adicione {{SessionName}} ao final do seu nome de usuário. Se você adicionar {{SessionName}} ao seu nome de usuário, ele deverá incluir dois pontos antes de {{SessionName}}. Quando essa função é assumida, o nome da sessão especificado ao assumir a função é automaticamente passado para o cluster e aparecerá nos logs do CloudTrail. Por exemplo, não é possível ter um nome de usuário john{{SessionName}}. O nome de usuário teria que ser :john{{SessionName}} ou jo:hn{{SessionName}}. Os dois pontos precisam vir antes de {{SessionName}}. O nome de usuário gerado pelo Amazon EKS na tabela a seguir inclui um ARN. Como um ARN inclui dois pontos, ele atende a esse requisito. Os dois pontos não serão necessários se você não incluir {{SessionName}} no seu nome de usuário.

  Tipo de entidade principal do IAM	Tipo	Valor do nome de usuário que o Amazon EKS define automaticamente
  Usuário	STANDARD	O ARN do usuário. Exemplo: arn:aws:iam::111122223333:user/my-user
  Função	STANDARD	O STS ARN da função quando ela é assumida. O Amazon EKS anexa {{SessionName}} à função. Exemplo: arn:aws:sts::111122223333:assumed-role/my-role/{{SessionName}} Se o ARN da função que você especificou contiver um caminho, o Amazon EKS o removerá no nome de usuário gerado.
  Função	EC2 Linux ou EC2 Windows	system:node:{{EC2PrivateDNSName}}
  Função	FARGATE_LINUX	system:node:{{SessionName}}

  Você poderá alterar o nome de usuário depois que a entrada de acesso for criada.

• Se o tipo de entrada de acesso for STANDARD e você quiser usar a autorização RBAC do Kubernetes, poderá adicionar um ou mais nomes de grupos à entrada de acesso. Depois de criar uma entrada de acesso, você pode adicionar e remover nomes de grupos. Para que a entidade principal do IAM tenha acesso aos objetos do Kubernetes em seu cluster, você deve criar e gerenciar objetos de autorização baseada em funções (RBAC) do Kubernetes. Crie objetos RoleBinding ou ClusterRoleBinding do Kubernetes em seu cluster que especifiquem o nome do grupo como um subject para kind: Group. O Kubernetes autoriza o acesso da entidade principal do IAM a qualquer objeto de cluster que você especificou em um objeto Role ClusterRole do Kubernetes que você também especificou no roleRef da vinculação. Se você especificar nomes de grupo, convém familiarizar-se com os objetos de autorização com base em função (RBAC) do Kubernetes. Para mais informações, consulte Using RBAC Authorization (Usar autorização RBAC) na documentação do Kubernetes.

  Importante

  O Amazon EKS não confirma que nenhum objeto RBAC do Kubernetes existente no seu cluster inclua nenhum dos nomes de grupos que você especificar.

  Em vez de, ou além de, o Kubernetes autorizar o acesso da entidade principal do IAM aos objetos do Kubernetes em seu cluster, você pode associar as políticas de acesso do Amazon EKS a uma entrada de acesso. O Amazon EKS autoriza as entidades principais do IAM a acessar objetos do Kubernetes em seu cluster com as permissões na política de acesso. Você pode definir o escopo das permissões de uma política de acesso aos namespaces do Kubernetes que você especificar. O uso de políticas de acesso não exige que você gerencie objetos RBAC do Kubernetes. Para ter mais informações, consulte Associar políticas de acesso a entradas de acesso.

• Se você criar uma entrada de acesso com o tipo EC2 Linux ou EC2 Windows, a entidade principal do IAM que criou a entrada de acesso deverá ter a permissão iam:PassRole. Para obter mais informações, consulte Conceder permissões a um usuário para passar uma função para um AWS service (Serviço da AWS) no Guia do usuário do IAM.

• Semelhante ao comportamento padrão do IAM, a criação e as atualizações de entradas de acesso acabam sendo consistentes e podem levar alguns segundos para serem efetivadas após o retorno bem-sucedido da chamada inicial de API. Suas aplicações devem ser projetadas para levar em conta esses possíveis atrasos. Recomendamos que você não inclua criações ou atualizações de entrada de acesso nos caminhos de código críticos de alta disponibilidade da sua aplicação. Em vez disso, faça alterações do em uma rotina de inicialização ou de configuração separada que você executa com menos frequência. Além disso, certifique-se de verificar se as alterações foram propagadas antes que os fluxos de trabalho de produção dependam delas.

• As entradas de acesso não oferecem suporte para perfis vinculados ao serviço. Não é possível criar entradas de acesso nas quais o ARN da entidade principal corresponde a um perfil vinculado ao serviço. É possível identificar perfis vinculados ao serviço pelo ARN deles, que está no formato arn:aws:iam::*:role/aws-service-role/*.

Você pode criar uma entrada de acesso usando o AWS Management Console ou a AWS CLI.

AWS Management Console

Para criar uma entrada de acesso

1. Abra o console do Amazon EKS em https://console.aws.amazon.com/eks/home#/clusters.

2. Escolha o nome do cluster em que você deseja criar uma entrada de acesso.

3. Escolha a guia Acesso.

4. Selecione Criar entrada de acesso.

5. Para a entidade principal do IAM, selecione um perfil ou usuário do IAM existente. As práticas recomendadas do IAM sugerem que você acesse o cluster usando perfis do IAM que têm credenciais de curto prazo, em vez de usuários do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte Exija que os usuários humanos usem a federação com um provedor de identidades para acessar a AWS usando credenciais temporárias no Guia do usuário do IAM.

6. Em Tipo, se a entrada de acesso for para a função de nó usada para nós autogerenciados do Amazon EC2, selecione EC2 Linux ou EC2 Windows. Caso contrário, aceite o padrão (Padrão).

7. Se o Tipo escolhido for Padrão e você quiser especificar um nome de usuário, insira o nome de usuário.

8. Se o Tipo escolhido for Padrão e você quiser usar a autorização RBAC do Kubernetes para a entidade principal do IAM, especifique um ou mais nomes para Grupos. Se você não especificar nenhum nome de grupo e quiser usar a autorização do Amazon EKS, poderá associar uma política de acesso em uma etapa posterior ou após a criação da entrada de acesso.

9. (Opcional) Para Tags, atribua rótulos à entrada de acesso. Por exemplo, para facilitar a localização de todos os recursos com a mesma tag.

10. Escolha Próximo.

11. Na página Adicionar política de acesso, se o tipo escolhido for Padrão e você quiser que o Amazon EKS autorize a entidade principal do IAM a ter permissões para os objetos do Kubernetes em seu cluster, execute as etapas a seguir. Caso contrário, escolha Next.

    1. Em Nome da política, escolha uma política de acesso. Você não pode ver as permissões das políticas de acesso, mas elas incluem permissões semelhantes às dos objetos ClusterRole voltados para o usuário do Kubernetes. Para obter mais informações, consulte User-facing roles na documentação do Kubernetes.

    2. Escolha uma das seguintes opções:

       • Cluster: escolha essa opção se quiser que o Amazon EKS autorize a entidade principal do IAM a ter as permissões na política de acesso para todos os objetos do Kubernetes em seu cluster.

       • Namespace do Kubernetes: escolha essa opção se quiser que o Amazon EKS autorize a entidade principal do IAM a ter as permissões na política de acesso para todos os objetos do Kubernetes em um namespace do Kubernetes específico em seu cluster. Em Namespace, insira o nome do namespace do Kubernetes no seu cluster. Se quiser adicionar mais namespaces, escolha Adicionar novo namespace e insira o nome do namespace.

    3. Se você quiser adicionar mais políticas, escolha Adicionar política. Você pode definir o escopo de cada política de forma diferente, mas cada política só pode ser adicionada uma vez.

    4. Escolha Próximo.

12. Revise a configuração da entrada de acesso. Se algo parecer errado, escolha Anterior para voltar às etapas anteriores e corrigir o erro. Se a configuração estiver correta, escolha Criar.

AWS CLI

Pré-requisito

Instalar a AWS CLI conforme descrito em Instalar, atualizar e desinstalar a AWS CLI no Guia do usuário da AWS Command Line Interface.

Para criar uma entrada de acesso

Você pode usar qualquer um dos seguintes exemplos para criar entradas de acesso:

• Crie uma entrada de acesso para um grupo de nós autogerenciado do Amazon EC2 Linux. Substitua my-cluster pelo nome do seu cluster, 111122223333 pelo seu ID da Conta da AWS e EKS-my-cluster-self-managed-ng-1 pelo nome do seu nó do perfil do IAM. Se seu grupo de nós for um grupo de nós do Windows, substitua EC2_Linux por EC2_Windows.

  aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_Linux
  

  Você não pode usar a opção --kubernetes-groups ao especificar um tipo diferente de STANDARD. Você não pode associar uma política de acesso a essa entrada de acesso porque seu tipo é um valor diferente de STANDARD.

• Crie uma entrada de acesso que permita um perfil do IAM que não é usado para um grupo de nós autogerenciado do Amazon EC2, com o qual você deseja que o Kubernetes autorize o acesso ao seu cluster. Substitua my-cluster pelo nome do cluster e 111122223333 pelo seu ID da Conta da AWS e my-role pelo nome do seu perfil do IAM. Substitua Espectadores pelo nome de um grupo que você especificou em um objeto RoleBinding ou ClusterRoleBinding do Kubernetes em seu cluster.

  aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
  

• Crie uma entrada de acesso que permita que um usuário do IAM se autentique no seu cluster. Esse exemplo é fornecido porque isso é possível, embora as práticas recomendadas do IAM sugiram acessar seu cluster usando perfis do IAM que têm credenciais de curto prazo, em vez de usuários do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte Exija que os usuários humanos usem a federação com um provedor de identidades para acessar a AWS usando credenciais temporárias no Guia do usuário do IAM.

  aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
  

  Se quiser que esse usuário tenha mais acesso ao seu cluster do que as permissões nas funções de descoberta da API do Kubernetes, você precisará associar uma política de acesso à entrada de acesso, já que a opção --kubernetes-groups não é usada. Para obter mais informações, consulte Associar políticas de acesso a entradas de acesso e API discovery roles na documentação do Kubernetes.