Melhores práticas de criptografia para o Amazon EKS - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Melhores práticas de criptografia para o Amazon EKS

O Amazon Elastic Kubernetes Service (Amazon EKS) ajuda você a executar o AWS Kubernetes sem precisar instalar ou manter seu próprio plano de controle ou nós do Kubernetes. No Kubernetes, os segredos ajudam você a gerenciar informações confidenciais, como certificados de usuário, senhas ou chaves de API. Por padrão, esses segredos são armazenados sem criptografia no armazenamento de dados subjacente do servidor da API, o etcd. No Amazon EKS, os volumes do Amazon Elastic Block Store (Amazon EBS) etcd para nós são criptografados com a criptografia do Amazon EBS. Qualquer usuário com acesso à API ou ao etcd pode recuperar ou modificar um segredo. Além disso, qualquer pessoa autorizada a criar um pod em um namespace pode usar esse acesso para ler qualquer segredo nesse namespace. Você pode criptografar esses segredos em repouso no Amazon EKS usando AWS KMS keys chaves gerenciadas ou chaves AWS gerenciadas pelo cliente. Uma abordagem alternativa de uso etcd é usar o AWS Secrets and Config Provider (ASCP) (GitHub repositório). O ASCP se integra ao IAM e a políticas com base em recursos para limitar e restringir o acesso a segredos somente em pods específicos do Kubernetes em um cluster.

Você pode usar os seguintes serviços AWS de armazenamento com o Kubernetes:

  • Para o Amazon EBS, você pode usar o driver de armazenamento em árvore ou o driver CSI do Amazon EBS. Ambos incluem parâmetros para criptografar volumes e fornecer uma chave gerenciada pelo cliente.

  • Para o Amazon Elastic File System (Amazon EFS), é possível usar o Driver da CSI do Amazon EFS compatível com provisionamento dinâmico e estático.

Considere as seguintes práticas recomendadas de criptografia para esse serviço:

  • Se você estiver usando o etcd, que armazena objetos secretos não criptografados por padrão, faça o seguinte para ajudar a protegê-los:

    • Criptografia de dados em repouso secretos (documentação do Kubernetes).

    • Use AWS KMS para criptografia de envelope de segredos do Kubernetes. Isso permite que você criptografe seus segredos com uma chave de dados exclusiva. Você pode usar uma AWS KMS chave de criptografia de chave para criptografar a chave de dados. Você pode alternar automaticamente a chave de criptografia de chave em uma programação recorrente. Com o AWS KMS plug-in para Kubernetes, todos os segredos do Kubernetes são armazenados em texto cifrado. etcd Eles só podem ser descriptografados pelo servidor da API Kubernetes. Para obter mais informações, consulte Como usar o suporte do provedor de criptografia Amazon EKS para defesa profunda e Criptografar segredos do Kubernetes em clusters existentes. AWS KMS

    • Ative ou configure a autorização por meio de regras de controle de acesso baseado em perfil (RBAC) que restringem a leitura e a gravação do segredo. Restrinja as permissões para criar novos segredos ou substituir segredos existentes. Para obter mais informações, consulte Visão geral da autorização (documentação do Kubernetes).

    • Se você estiver definindo vários contêineres em um pod e somente um desses contêineres precisar acessar um segredo, defina a montagem do volume para que os outros contêineres não tenham acesso a esse segredo. Segredos montados como volumes são instanciados como volumes tmpfs e são removidos automaticamente do nó quando o pod é excluído. Também é possível usar variáveis de ambiente, mas não recomendamos essa abordagem porque os valores das variáveis de ambiente podem aparecer nos registros. Para obter mais informações, consulte Segredos (documentação do Kubernetes).

    • Quando possível, evite conceder acesso a solicitações watch e list para segredos em um namespace. Na API do Kubernetes, essas solicitações são poderosas porque permitem que o cliente inspecione os valores de cada segredo nesse namespace.

    • Permita que somente os administradores de cluster acessem o etcd, incluindo acesso somente leitura.

    • Se houver várias instâncias do etcd, garanta que etcd use TLS para comunicação entre pares etcd.

  • Se você estiver usando o ASCP, faça o seguinte para ajudar a proteger os segredos:

  • Para ajudar a mitigar o risco de vazamento de dados de variáveis de ambiente, recomendamos que você use o driver CSI e AWS Secrets Manager Config Provider for Secret Store (). GitHub Esse driver permite que os segredos armazenados no Secrets Manager e os parâmetros armazenados no Parameter Store apareçam como arquivos montados em pods do Kubernetes.

    nota

    AWS Fargate não é suportado.

  • Crie um filtro de CloudWatch métricas e um alarme da Amazon para enviar alertas para operações especificadas pelo administrador, como exclusão secreta ou uso de uma versão secreta no período de espera para ser excluída. Para obter mais informações, consulte Criar um alarme com base na detecção de anomalias.