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
[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 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](https://github.com/kubernetes-sigs/aws-ebs-csi-driver). Ambos incluem parâmetros para criptografar volumes e fornecer uma CMK. Para o EFS, você pode usar o [driver EFS CSI](https://github.com/kubernetes-sigs/aws-efs-csi-driver), 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](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html). 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:
```
O [driver FSx CSI](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) 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:
```
**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.
### Criptografia de 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](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)
### 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](https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/).
## 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). 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](https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/)
### 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](https://aws.amazon.com/secrets-manager/) 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 com o Kubernetes Secrets. O Bitnami's [Sealed Secrets](https://github.com/bitnami-labs/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](https://aws.amazon.com/blogs/opensource/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/) 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](https://github.com/kubernetes-sigs/secrets-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](https://github.com/aws/secrets-store-csi-driver-provider-aws), 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](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/auth/auth.go).
Para obter informações adicionais sobre o AWS Secrets & Configuration Provider (ASCP), consulte os seguintes recursos:
+ [Como usar o AWS Secrets Configuration Provider com o driver CSI do Kubernetes Secret Store](https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-configuration-provider-with-kubernetes-secrets-store-csi-driver/)
+ [Integrando segredos do Secrets Manager com o driver CSI do Kubernetes Secrets Store](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)
[external-secrets](https://github.com/external-secrets/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
+ [Workshop de imersão em segurança do Amazon EKS — Criptografia de dados e gerenciamento de segredos](https://catalog.workshops.aws/eks-security-immersionday/en-US/13-data-encryption-and-secret-management)