Considerações sobre segurança para funcionalidades do EKS - Amazon EKS
Perfil do IAM para a funcionalidadeEntradas de acesso do EKSPermissões adicionais do KubernetesPermissões do IAM exigidas pela funcionalidadePráticas recomendadas de segurançaPróximas etapas

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Considerações 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:

É 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.

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 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

  2. 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 é 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á. Você deve 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.

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, você deve 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

Você pode 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 com a interface do usuário do Argo CD e com a API do Argo CD usando a VPC, sem trafegar pela internet pública.

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 do 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.

Próximas etapas