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 diferentes de armazenamento nativo da AWS que você pode usar com o Kubernetes: EBS, EFS e for Lustre. FSx Todos os três oferecem criptografia em repouso usando uma chave gerenciada por serviço ou uma chave mestra do cliente (CMK). Para o EBS, você pode usar o driver de armazenamento em árvore ou o driver EBS CSI. Ambos incluem parâmetros para criptografar volumes e fornecer uma CMK. Para o 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 você quiser usar o EFS com o EKS, precisará provisionar e configurar a criptografia em repouso para o sistema de arquivos antes de criar um PV. Para obter mais informações sobre a criptografia de arquivos EFS, consulte Criptografando dados em repouso. Além de oferecer criptografia em repouso, o EFS e FSx o Lustre incluem uma opção para criptografar dados em trânsito. 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 oferece suporte ao provisionamento dinâmico dos sistemas de arquivos Lustre. Por padrão, ele criptografa os dados com uma chave gerenciada por 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 do EKS Fargate são criptografados por padrão usando um algoritmo criptográfico AES-256 padrão do setor. Nenhuma modificação em seu aplicativo é necessária, pois a criptografia e a descriptografia são tratadas sem problemas pelo serviço.

Criptografe dados em repouso

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

Gire seu periodicamente CMKs

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

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

Se você tiver conjuntos de dados compartilhados com permissões de arquivo POSIX diferentes ou quiser restringir o acesso a parte do sistema de arquivos compartilhado criando pontos de montagem diferentes, considere usar pontos de acesso do 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 Introdução ao provisionamento dinâmico CSI do Amazon EFS 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 são mantidos no etcd como strings codificadas em base64. No EKS, os volumes do EBS para nós etcd são criptografados com a criptografia do EBS. Um pod pode recuperar objetos secretos do Kubernetes referenciando o 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 namespace específico 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 envelopes de segredos do Kubernetes

Isso permite que você criptografe seus segredos com uma chave de criptografia de dados (DEK) exclusiva. Em seguida, a DEK é criptografada usando uma chave de criptografia de chave (KEK) do AWS KMS, que pode ser rotacionada automaticamente de acordo com uma programação 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 detalhes

Audite o uso dos segredos do Kubernetes

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 baseado em RAM) que são automaticamente removidos do nó quando o pod é excluído.

Use um provedor externo de segredos

Há várias alternativas viáveis para usar segredos do Kubernetes, incluindo o AWS Secrets Manager e o Hashicorp's Vault. 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 com o Kubernetes Secrets. O Bitnami's Sealed Secrets é 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 externos de segredos 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 segredos do Kubernetes. 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 de um volume.

nota

Quando o driver CSI do armazenamento secreto 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, os segredos externos funcionam 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, os segredos externos copiam os segredos desses back-ends para o Kubernetes como segredos. Isso permite que você gerencie segredos usando seu repositório secreto preferido e interaja com os segredos de uma forma nativa do Kubernetes.

Ferramentas e recursos