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.

Faça hardening do RBAC do Kubernetes no Amazon EKS

O controle de acesso baseado em função (RBAC) controla quais ações as identidades podem executar em um cluster. Muitos componentes do cluster, incluindo drivers CSI e outros complementos instalados como DaemonSets, exigem amplas permissões para funcionar. A revisão e o escopo dessas permissões reduzem o escopo potencial de qualquer acesso não intencional.

Este tópico descreve as considerações de permissão para componentes comuns do cluster e os controles recomendados.

Permissões da conta de serviço DaemonSet

Os DaemonSet Pods são executados em todos os nós do cluster, portanto, os tokens da conta de serviço e as permissões RBAC que esses tokens concedem estão presentes em cada nó.

Um processo não autorizado em um nó pode acessar os tokens da conta de serviço de outros pods em execução no mesmo nó, incluindo os DaemonSet Pods. As permissões de RBAC concedidas às contas de serviço DaemonSets são as mesmas em todos os nós no cluster.

Os componentes normalmente implantados como DaemonSets incluem:

Se um DaemonSet Pod AWS tiver credenciais do IAM por meio do EKS Pod Identity ou do IAM Roles for Service Accounts (IRSA), um processo que obtém acesso fora do contêiner no mesmo nó também pode acessar essas credenciais. Isso estende o escopo do impacto além do Kubernetes RBAC para qualquer permissão da API AWS concedida ao perfil do IAM de um DaemonSet.

Escopo do RBAC do driver CSI

Os drivers CSI geralmente recebem amplas concessões de RBAC porque interagem com nós, volumes persistentes e APIs de armazenamento.

Permissões de objeto de nó

Os drivers CSI podem exigir permissões RBAC para modificar objetos do nó para oferecer suporte a recursos como remoção de taint ou outras tarefas de gerenciamento de nós. Devido às limitações do Kubernetes RBAC, essas permissões se aplicam a todos os objetos de nó no cluster, não apenas ao nó local em que o driver está sendo executado.

Para o driver EBS CSI, o chart do Helm fornece um parâmetro (node.serviceAccount.disableMutation) que remove a permissão de modificação do nó da conta de serviço ebs-csi-node. Ativar isso desativa o atributo de remoção de taint.

Exposição do token da conta de serviço

Os pods de drivers CSI podem usar tokens de conta de serviço projetados para autenticação. Em um nó em que um processo não autorizado obteve acesso fora do contêiner, esses tokens podem ser acessados por meio do sistema de arquivos do contêiner ou da API kubelet. Se a conta de serviço também estiver associada a um perfil do IAM por meio da Identidade de Pods do EKS ou pelo IRSA, um token exposto poderá ser usado para obter as credenciais AWS do IAM.

Controles recomendados

Escopo RBAC para privilégio mínimo

Imponha padrões de segurança do pod

Aplique os padrões de segurança do Kubernetes Pod usando o controlador de admissão de segurança do Pod integrado ou um mecanismo de políticas. No mínimo, aplique o perfil baseline em todo o cluster e o perfil restricted para namespaces de workload. Isso limita a capacidade de criar contêineres privilegiados fora dos namespaces do sistema.

Usar políticas de rede

Aplique políticas de rede para restringir a saída do driver CSI e dos DaemonSet Pods somente aos endpoints de que eles precisam (por exemplo, o servidor da API Kubernetes e os endpoints de serviço AWS). Isso reduz o escopo das ações possíveis.

Monitore a atividade do RBAC

Ative o registro de auditoria do Kubernetes e monitore chamadas de API inesperadas de contas de serviço DaemonSet. Procure:

Para obter mais informações, consulte Enviar logs do ambiente de gerenciamento para o CloudWatch Logs.