View a markdown version of this page

Criptografia de dados e gerenciamento de segredos - Amazon EKS
Criptografia em repousoGerenciamento de segredosFerramentas e recursos

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

Criptografia de dados e gerenciamento de segredos

Criptografia em repouso

Há três opções de AWS-native armazenamento diferentes que você pode usar com o Kubernetes: EBS , EFS e FSx for Lustre. Todos os três oferecem criptografia em repouso usando uma chave gerenciada pelo serviço ou uma chave mestra do cliente (CMK). Para o EBS, você pode usar o driver de armazenamento na árvore ou o driver EBS CSI. Ambos incluem parâmetros para criptografar volumes e fornecer uma CMK. Para EFS, você pode usar o driver EFS CSI, no entanto, diferentemente do EBS, o driver EFS CSI não oferece suporte ao provisionamento dinâmico. Se quiser usar o EFS com o EKS, você precisará provisionar e configurar a criptografia em repouso para o sistema de arquivos antes de criar um PV. Para obter mais informações sobre criptografia de arquivos EFS, consulte Criptografando dados em repouso. Além de oferecer criptografia em repouso, o EFS e o FSx for Lustre incluem uma opção para criptografar dados em trânsito. O FSx for Lustre faz isso por padrão. Para o EFS, você pode adicionar criptografia de transporte adicionando o tls parâmetro ao mountOptions seu PV, como neste exemplo:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  mountOptions:
    - tls
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <file_system_id>

O driver FSx CSI suporta o provisionamento dinâmico de sistemas de arquivos Lustre. Por padrão, ele criptografa os dados com uma chave gerenciada pelo serviço, embora haja a opção de fornecer sua própria CMK, como neste exemplo:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
  subnetId: subnet-056da83524edbe641
  securityGroupIds: sg-086f61ea73388fb6b
  deploymentType: PERSISTENT_1
  kmsKeyId: <kms_arn>
Importante

Em 28 de maio de 2020, todos os dados gravados no volume efêmero nos pods EKS Fargate são criptografados por padrão usando um algoritmo criptográfico padrão do setor. AES-256 Nenhuma modificação em seu aplicativo é necessária, pois a criptografia e a descriptografia são tratadas perfeitamente pelo serviço.

Criptografia de dados em repouso

A criptografia de dados em repouso é considerada uma prática recomendada. Se você não tiver certeza se a criptografia é necessária, criptografe seus dados.

Alterne suas CMKs periodicamente

Configure o KMS para rotacionar automaticamente suas CMKs. Isso rotacionará suas chaves uma vez por ano, salvando as chaves antigas indefinidamente para que seus dados ainda possam ser descriptografados. Para obter informações adicionais, consulte Como girar as chaves mestras do cliente.

Use pontos de acesso EFS para simplificar o acesso a conjuntos de dados compartilhados

Se você tiver conjuntos de dados compartilhados com diferentes permissões de arquivo POSIX ou quiser restringir o acesso a parte do sistema de arquivos compartilhados criando pontos de montagem diferentes, considere usar pontos de acesso EFS. Para saber mais sobre como trabalhar com pontos de acesso, consulte https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html. Hoje, se você quiser usar um ponto de acesso (AP), precisará referenciar o AP no volumeHandle parâmetro do PV.

Importante

A partir de 23 de março de 2021, o driver EFS CSI oferece suporte ao provisionamento dinâmico de pontos de acesso EFS. Os pontos de acesso são pontos de entrada específicos do aplicativo em um sistema de arquivos EFS que facilitam o compartilhamento de um sistema de arquivos entre vários pods. Cada sistema de arquivos EFS pode ter até 120 PVs. Consulte Apresentando o provisionamento dinâmico do Amazon EFS CSI para obter informações adicionais.

Gerenciamento de segredos

Os segredos do Kubernetes são usados para armazenar informações confidenciais, como certificados de usuário, senhas ou chaves de API. Eles persistem no etcd como strings codificadas em base64. No EKS, os volumes do EBS para nós etcd são criptografados com criptografia do EBS. Um pod pode recuperar objetos secretos do Kubernetes fazendo referência ao segredo no. podSpec Esses segredos podem ser mapeados para uma variável de ambiente ou montados como volume. Para obter informações adicionais sobre a criação de segredos, consulte https://kubernetes.io/docs/concepts/configuration/secret/.

Atenção

Os segredos em um determinado namespace podem ser referenciados por todos os pods no namespace do segredo.

Atenção

O autorizador do nó permite que o Kubelet leia todos os segredos montados no nó.

Use o AWS KMS para criptografia de envelope de segredos do Kubernetes

Isso permite que você criptografe seus segredos com uma chave de criptografia de dados (DEK) exclusiva. A DEK é então criptografada usando uma chave de criptografia de chave (KEK) do AWS KMS, que pode ser alternada automaticamente em um cronograma recorrente. Com o plug-in KMS para Kubernetes, todos os segredos do Kubernetes são armazenados no etcd em texto cifrado em vez de texto simples e só podem ser descriptografados pelo servidor da API Kubernetes. Para obter detalhes adicionais, consulte Como usar o suporte do provedor de criptografia EKS para defesa em profundidade

Audite o uso do Kubernetes Secrets

No EKS, ative o registro de auditoria e crie um filtro de CloudWatch métricas e um alarme para alertá-lo quando um segredo for usado (opcional). Veja a seguir um exemplo de filtro de métricas para o registro de auditoria do Kubernetes,. {($.verb="get") && ($.objectRef.resource="secret")} Você também pode usar as seguintes consultas com o CloudWatch Log Insights:

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"

A consulta acima exibirá o número de vezes que um segredo foi acessado em um período específico.

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code

Essa consulta exibirá o segredo, junto com o namespace e o nome de usuário do usuário que tentou acessar o segredo e o código de resposta.

Alterne seus segredos periodicamente

O Kubernetes não alterna automaticamente os segredos. Se você precisar alternar segredos, considere usar um armazenamento secreto externo, por exemplo, Vault ou AWS Secrets Manager.

Use namespaces separados como forma de isolar segredos de diferentes aplicativos

Se você tiver segredos que não podem ser compartilhados entre aplicativos em um namespace, crie um namespace separado para esses aplicativos.

Use montagens de volume em vez de variáveis de ambiente

Os valores das variáveis de ambiente podem aparecer acidentalmente nos registros. Os segredos montados como volumes são instanciados como volumes tmpfs (um sistema de arquivos com suporte de RAM) que são removidos automaticamente do nó quando o pod é excluído.

Use um provedor externo de segredos

Há várias alternativas viáveis ao uso dos segredos do Kubernetes, incluindo o AWS Secrets Manager e o Hashicorp's Vault. https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/ Esses serviços oferecem recursos como controles de acesso refinados, criptografia forte e rotação automática de segredos que não estão disponíveis no Kubernetes Secrets. Os segredos selados da Bitnami são outra abordagem que usa criptografia assimétrica para criar “segredos selados”. Uma chave pública é usada para criptografar o segredo, enquanto a chave privada usada para descriptografar o segredo é mantida no cluster, permitindo que você armazene segredos selados com segurança em sistemas de controle de origem como o Git. Consulte Gerenciando a implantação de segredos no Kubernetes usando segredos selados para obter mais informações.

À medida que o uso de armazenamentos de segredos externos cresceu, também aumentou a necessidade de integrá-los ao Kubernetes. O Secret Store CSI Driver é um projeto comunitário que usa o modelo de driver CSI para buscar segredos de lojas secretas externas. Atualmente, o driver tem suporte para AWS Secrets Manager, Azure, Vault e GCP. O provedor da AWS oferece suporte ao AWS Secrets Manager e ao AWS Parameter Store. Ele também pode ser configurado para alternar segredos quando eles expirarem e pode sincronizar segredos do AWS Secrets Manager com o Kubernetes Secrets. A sincronização de segredos pode ser útil quando você precisa referenciar um segredo como uma variável de ambiente em vez de lê-lo em um volume.

nota

Quando o driver CSI da loja secreta precisa buscar um segredo, ele assume a função IRSA atribuída ao pod que faz referência a um segredo. O código dessa operação pode ser encontrado aqui.

Para obter informações adicionais sobre o AWS Secrets & Configuration Provider (ASCP), consulte os seguintes recursos:

external-secrets é outra forma de usar um armazenamento secreto externo com o Kubernetes. Assim como o CSI Driver, external-secrets funciona em uma variedade de back-ends diferentes, incluindo o AWS Secrets Manager. A diferença é que, em vez de recuperar segredos do armazenamento secreto externo, external-secrets copia segredos desses back-ends para o Kubernetes como segredos. Isso permite que você gerencie segredos usando seu armazenamento secreto preferido e interaja com os segredos de uma Kubernetes-native forma.

Ferramentas e recursos