Gerenciamento de acesso ao cluster

O gerenciamento eficaz do acesso é crucial para manter a segurança e a integridade dos seus clusters do Amazon EKS. Este guia explora várias opções de gerenciamento de acesso ao EKS, com foco no uso do AWS IAM Identity Center (antigo AWS SSO). Compararemos diferentes abordagens, discutiremos suas vantagens e desvantagens e destacaremos as limitações e considerações conhecidas.

Opções de gerenciamento de acesso EKS

nota

ConfigMapo gerenciamento de acesso baseado (aws-auth ConfigMap) está obsoleto e substituído pela API Cluster Access Management (CAM). Para novos clusters EKS, implemente a API CAM para gerenciar o acesso ao cluster. Para clusters existentes usando aws-auth ConfigMap, migre para o uso da API CAM.

Opção 1: AWS IAM Identity Center com API de gerenciamento de acesso ao cluster (CAM)

• Gerenciamento centralizado de usuários e permissões

• Integração com provedores de identidade existentes (por exemplo, Microsoft AD, Okta PingId e outros)

• A API CAM usa entradas de acesso para vincular os principais do AWS IAM (usuários ou funções) ao cluster EKS. Essas entradas funcionam com as identidades gerenciadas do IAM Identity Center, permitindo que os administradores controlem o acesso ao cluster para usuários e grupos definidos no Identity Center.

Fluxo de autenticação do cluster EKS:

1. Os diretores (usuários humanos) ou processos automatizados se autenticam por meio do AWS IAM apresentando as permissões apropriadas da conta da AWS. Nesta etapa, eles são mapeados para o principal (função ou usuário) apropriado do AWS IAM.

2. Em seguida, uma entrada de acesso do EKS mapeia esse principal do IAM para um principal do Kubernetes RBAC (usuário ou grupo) definindo a política de acesso apropriada, que contém somente as permissões do Kubernetes.

3. Quando um usuário final do Kubernetes tenta acessar um cluster, sua solicitação de autenticação é processada pela CLI do aws-iam-authenticator AWS EKS e validada em relação ao contexto do cluster no arquivo kubeconfig.

4. Por fim, o autorizador do EKS verifica as permissões associadas à entrada de acesso do usuário autenticado e concede ou nega o acesso adequadamente.

   • A API usa políticas de acesso específicas do Amazon EKS para definir o nível de autorização para cada entrada de acesso. Essas políticas podem ser mapeadas para funções e permissões configuradas no IAM Identity Center, garantindo um controle de acesso consistente nos serviços da AWS e nos clusters do EKS.

Benefícios ConfigMap em relação ao gerenciamento de acesso baseado:

1. Risco reduzido de configurações incorretas: o gerenciamento direto baseado em API elimina erros comuns associados à edição manual. ConfigMap Isso ajuda a evitar exclusões acidentais ou erros de sintaxe que podem impedir que os usuários saiam do cluster.

2. Princípio aprimorado de privilégios mínimos: elimina a necessidade de permissão de administrador de cluster da identidade do criador do cluster e permite uma atribuição de permissões mais granular e apropriada. Você pode optar por adicionar essa permissão para casos de uso de quebra-vidros.

3. Modelo de segurança aprimorado: fornece validação integrada das entradas de acesso antes de serem aplicadas. Além disso, oferece maior integração com o AWS IAM para autenticação.

4. Operações simplificadas: oferece uma maneira mais intuitiva de gerenciar permissões por meio de ferramentas nativas da AWS.

Melhores práticas:

1. Use o AWS Organizations para gerenciar várias contas e aplicar políticas de controle de serviços (SCPs).

2. Implemente o princípio de privilégio mínimo criando conjuntos de permissões específicos para diferentes funções do EKS (por exemplo, administrador, desenvolvedor, somente leitura).

3. Utilize o controle de acesso baseado em atributos (ABAC) para atribuir dinamicamente permissões aos pods com base nos atributos do usuário.

4. Audite e revise regularmente as permissões de acesso.

Considerações/limitações:

1. As funções ARNs geradas pelo Identity Center têm sufixos aleatórios, o que as torna difíceis de usar em configurações estáticas.

2. Suporte limitado para permissões refinadas no nível de recursos do Kubernetes. É necessária uma configuração adicional para funções RBAC personalizadas do Kubernetes. Junto com o RBAC nativo do Kubernetes, considere usar o Kyverno para gerenciamento avançado de permissões em clusters EKS.

Opção 2: AWS IAM Users/Roles mapeado para grupos do Kubernetes

Prós:

1. Controle refinado sobre as permissões do IAM.

2. Papel previsível e estático ARNs

Contras:

1. Aumento da sobrecarga de gerenciamento das contas de usuário

2. Falta de gerenciamento centralizado de identidade

3. Potencial de proliferação de entidades do IAM

Melhores práticas:

1. Use funções do IAM em vez de usuários do IAM para melhorar a segurança e a capacidade de gerenciamento

2. Implemente uma convenção de nomenclatura para funções para garantir consistência e facilidade de gerenciamento

3. Utilize as condições da política do IAM para restringir o acesso com base em tags ou outros atributos.

4. Alterne regularmente as chaves de acesso e revise as permissões.

Considerações/limitações:

1. Problemas de escalabilidade ao gerenciar um grande número de usuários ou funções

2. Sem recursos integrados de login único

Opção 3: Provedores do OIDC

Prós:

1. Integração com sistemas de gerenciamento de identidade existentes

2. Redução da sobrecarga de gerenciamento das contas de usuário

Contras:

1. Complexidade adicional de configuração

2. Potencial para maior latência durante a autenticação

3. Dependência do provedor de identidade externo

Melhores práticas:

1. Configure cuidadosamente o provedor OIDC para garantir a validação segura do token.

2. Use tokens de curta duração e implemente mecanismos de atualização de tokens.

3. Audite e atualize regularmente as configurações do OIDC.

Consulte este guia para obter uma implementação de referência da integração de provedores externos de Single Sign-On com o Amazon EKS

Considerações/limitações:

1. Integração nativa limitada com os serviços da AWS em comparação com o IAM.

2. O URL do emissor do provedor do OIDC deve estar acessível ao público para que o EKS descubra as chaves de assinatura.

AWS EKS Pod Identity versus IRSA para cargas de trabalho

O Amazon EKS fornece duas maneiras de conceder permissões do AWS IAM para cargas de trabalho executadas em clusters do Amazon EKS: funções do IAM para contas de serviço (IRSA) e EKS Pod Identities.

Embora tanto o IRSA quanto o EKS Pod Identities ofereçam os benefícios de acesso com privilégios mínimos, isolamento de credenciais e auditabilidade, o EKS Pod Identity é a forma recomendada de conceder permissões às cargas de trabalho.

Para obter orientações detalhadas sobre identidade e credenciais para pods EKS, consulte a seção Identidades e credenciais das melhores práticas de segurança.

Recomendação

Combine o IAM Identity Center com a API CAM

• Gerenciamento simplificado: ao usar a API Cluster Access Management em conjunto com o IAM Identity Center, os administradores podem gerenciar o acesso ao cluster EKS junto com outros serviços da AWS, reduzindo a necessidade de alternar entre diferentes interfaces ou editar ConfigMaps manualmente.

• Use entradas de acesso para gerenciar as permissões do Kubernetes das entidades principais do IAM de fora do cluster. Você pode adicionar e gerenciar o acesso ao cluster usando a API EKS, a interface de linha de comando da AWS, a AWS SDKs, a AWS CloudFormation e o AWS Management Console. Isso significa que você pode gerenciar usuários com as mesmas ferramentas com as quais criou o cluster.

• As permissões granulares do Kubernetes podem ser aplicadas com o mapeamento de usuários ou grupos do Kubernetes com diretores do IAM associados a identidades de SSO por meio de entradas de acesso e políticas de acesso.

• Para começar, siga Alterar modo de autenticação para usar entradas de acesso e, em seguida, Migrar entradas aws-auth existentes para ConfigMap entradas de acesso.