

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Cifrado de datos y gestión de secretos
<a name="data-encryption-and-secrets-management"></a>

## Cifrado en reposo
<a name="_encryption_at_rest"></a>

Hay tres opciones de AWS-native almacenamiento diferentes que puede usar con Kubernetes: [ EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)[, ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) EFS y [ FSx for Lustre. ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) Las tres ofrecen cifrado en reposo mediante una clave gestionada por el servicio o una clave maestra de cliente (CMK). En el caso de EBS, puede usar el controlador de almacenamiento integrado en árbol o el controlador CSI de [ EBS. ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) Ambos incluyen parámetros para cifrar volúmenes y suministrar una CMK. Para EFS, puede usar el controlador [ EFS CSI; sin embargo](https://github.com/kubernetes-sigs/aws-efs-csi-driver), a diferencia de EBS, el controlador EFS CSI no admite el aprovisionamiento dinámico. Si desea utilizar EFS con EKS, tendrá que aprovisionar y configurar el cifrado en reposo del sistema de archivos antes de crear un PV. Para obtener más información sobre el cifrado de archivos EFS, consulte [ Cifrado de datos en reposo. ](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html) Además de ofrecer cifrado en reposo, EFS y FSx for Lustre incluyen una opción para cifrar los datos en tránsito. FSx for Lustre lo hace de forma predeterminada. En el caso de EFS, puede añadir el cifrado de transporte añadiendo el `tls` parámetro a `mountOptions` en su PV, como en este ejemplo:

```
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>
```

El controlador [ FSx CSI ](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) admite el aprovisionamiento dinámico de los sistemas de archivos Lustre. Cifra los datos con una clave gestionada por el servicio de forma predeterminada, aunque existe la opción de proporcionar su propia CMK, como en este ejemplo:

```
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**  
A partir del 28 de mayo de 2020, todos los datos escritos en el volumen efímero de los módulos EKS Fargate se cifran de forma predeterminada mediante un algoritmo criptográfico estándar del sector. AES-256 No es necesario modificar la aplicación, ya que el servicio gestiona perfectamente el cifrado y el descifrado.

### Cifrado de datos en reposo
<a name="_encrypt_data_at_rest"></a>

Cifrar los datos en reposo se considera una práctica recomendada. Si no estás seguro de si el cifrado es necesario, cifra tus datos.

### Rota tus CMK periódicamente
<a name="_rotate_your_cmks_periodically"></a>

Configure KMS para que rote automáticamente sus CMK. De este modo, las claves se rotarán una vez al año y se guardarán las antiguas de forma indefinida para que los datos puedan seguir descifrándose. Para obtener más información, consulta Cómo [ rotar las claves maestras de los clientes ](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) 

### Utilice los puntos de acceso EFS para simplificar el acceso a los conjuntos de datos compartidos
<a name="_use_efs_access_points_to_simplify_access_to_shared_datasets"></a>

Si tiene conjuntos de datos compartidos con diferentes permisos de archivo POSIX o desea restringir el acceso a una parte del sistema de archivos compartido mediante la creación de diferentes puntos de montaje, considere la posibilidad de utilizar puntos de acceso EFS. Para obtener más información sobre cómo trabajar con puntos de acceso, consulte https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html. Hoy. Si desea utilizar un punto de acceso (AP), tendrá que hacer referencia al AP en el parámetro del `volumeHandle` PV.

**importante**  
A partir del 23 de marzo de 2021, el controlador CSI EFS admite el aprovisionamiento dinámico de los puntos de acceso EFS. Los puntos de acceso son puntos de entrada específicos de la aplicación a un sistema de archivos EFS que facilitan el intercambio de un sistema de archivos entre varios pods. Cada sistema de archivos EFS puede tener hasta 120 PVs. Consulte [ Introducción al aprovisionamiento dinámico CSI de Amazon EFS ](https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/) para obtener más información.

## Administración de secretos
<a name="_secrets_management"></a>

Los secretos de Kubernetes se utilizan para almacenar información confidencial, como certificados de usuario, contraseñas o claves de API. Se conservan en etcd como cadenas codificadas en base64. En EKS, los volúmenes de EBS para los nodos etcd se cifran con el cifrado [ EBS. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) Un pod puede recuperar los objetos secretos de Kubernetes haciendo referencia al secreto en. `podSpec` Estos secretos pueden asignarse a una variable de entorno o montarse como volumen. Para obtener información adicional sobre la creación de secretos, consulte https://kubernetes.io/docs/concepts/configuration/secret/.

**aviso**  
Todos los pods del espacio de nombres del secreto pueden hacer referencia a los secretos de un espacio de nombres determinado.

**aviso**  
El autorizador de nodos permite al Kubelet leer todos los secretos guardados en el nodo.

### Utilice AWS KMS para cifrar los secretos de Kubernetes en sobres
<a name="_use_aws_kms_for_envelope_encryption_of_kubernetes_secrets"></a>

Esto le permite cifrar sus secretos con una clave de cifrado de datos (DEK) única. A continuación, la DEK se cifra con una clave de cifrado de claves (KEK) de AWS KMS que se puede rotar automáticamente de forma periódica. Con el complemento KMS para Kubernetes, todos los secretos de Kubernetes se almacenan en etcd en texto cifrado, en lugar de en texto plano, y solo el servidor de API de Kubernetes puede descifrarlos. Para obtener más información, consulta el artículo Cómo utilizar el soporte del proveedor de cifrado EKS para una defensa en profundidad [https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/](https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/) 

### Audite el uso de Kubernetes Secrets
<a name="_audit_the_use_of_kubernetes_secrets"></a>

En EKS, activa el registro de auditoría y crea un filtro de CloudWatch métricas y una alarma para avisarte cuando se utilice un secreto (opcional). El siguiente es un ejemplo de un filtro de métricas para el registro de auditoría de Kubernetes. `{($.verb="get") && ($.objectRef.resource="secret")}` También puedes usar las siguientes consultas con 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"
```

La consulta anterior mostrará el número de veces que se ha accedido a un secreto en un período de tiempo 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
```

Esta consulta mostrará el secreto, junto con el espacio de nombres y el nombre de usuario del usuario que intentó acceder al secreto y el código de respuesta.

### Cambia tus secretos periódicamente
<a name="_rotate_your_secrets_periodically"></a>

Kubernetes no rota automáticamente los secretos. Si tiene que rotar los secretos, considere la posibilidad de utilizar un almacén de secretos externo, por ejemplo, Vault o AWS Secrets Manager.

### Utilice espacios de nombres independientes para aislar los secretos de diferentes aplicaciones
<a name="_use_separate_namespaces_as_a_way_to_isolate_secrets_from_different_applications"></a>

Si tiene secretos que no se pueden compartir entre aplicaciones de un espacio de nombres, cree un espacio de nombres independiente para esas aplicaciones.

### Utilice montajes de volumen en lugar de variables de entorno
<a name="_use_volume_mounts_instead_of_environment_variables"></a>

Los valores de las variables de entorno pueden aparecer involuntariamente en los registros. Los datos secretos montados como volúmenes se instancian como volúmenes tmpfs (un sistema de archivos con respaldo de RAM) que se eliminan automáticamente del nodo cuando se elimina el pod.

### Utilice un proveedor de secretos externo
<a name="_use_an_external_secrets_provider"></a>

Existen varias alternativas viables al uso de los secretos de Kubernetes, como [ AWS Secrets Manager ](https://aws.amazon.com/secrets-manager/) y Hashicorp's Vault. [https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/](https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/) Estos servicios ofrecen funciones como controles de acceso detallados, un cifrado sólido y la rotación automática de secretos que no están disponibles con Kubernetes Secrets. Los secretos [ sellados de Bitnami ](https://github.com/bitnami-labs/sealed-secrets) son otro enfoque que utiliza el cifrado asimétrico para crear «secretos sellados». Se utiliza una clave pública para cifrar el secreto, mientras que la clave privada utilizada para descifrar el secreto se guarda en el clúster, lo que permite almacenar de forma segura los secretos sellados en sistemas de control de código fuente como Git. Para obtener más información, consulta [ Cómo administrar la implementación de secretos en Kubernetes mediante secretos sellados. ](https://aws.amazon.com/blogs/opensource/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/)

A medida que ha crecido el uso de almacenes de secretos externos, también lo ha hecho la necesidad de integrarlos con Kubernetes. El controlador CSI de [ Secret Store ](https://github.com/kubernetes-sigs/secrets-store-csi-driver) es un proyecto comunitario que utiliza el modelo de controlador CSI para obtener información secreta de almacenes secretos externos. Actualmente, el controlador es compatible con [ AWS Secrets Manager](https://github.com/aws/secrets-store-csi-driver-provider-aws), Azure, Vault y GCP. El proveedor de AWS es compatible tanto con AWS Secrets Manager ** como con ** AWS Parameter Store. También se puede configurar para rotar los secretos cuando caduquen y para sincronizar los secretos de AWS Secrets Manager con los secretos de Kubernetes. La sincronización de los secretos puede resultar útil cuando necesita hacer referencia a un secreto como una variable de entorno en lugar de leerlo desde un volumen.

**nota**  
Cuando el controlador CSI del almacén secreto tiene que buscar un secreto, asume la función IRSA asignada al pod que hace referencia a ese secreto. El código de esta operación se puede encontrar aquí. [https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/credential_provider/](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/credential_provider/)

Para obtener información adicional sobre el proveedor de secretos y configuración de AWS (ASCP), consulte los siguientes recursos:
+  [Cómo usar AWS Secrets Configuration Provider con el controlador CSI de Kubernetes Secret Store ](https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-configuration-provider-with-kubernetes-secrets-store-csi-driver/) 
+  [Integración de los secretos de Secrets Manager con el controlador CSI de Kubernetes Secrets Store ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) 

 [external-secrets ](https://github.com/external-secrets/external-secrets) es otra forma de usar un almacén secreto externo con Kubernetes. Al igual que el controlador CSI, external-secrets funciona con una variedad de backends diferentes, incluido AWS Secrets Manager. La diferencia es que, en lugar de recuperar los secretos del almacén de secretos externo, external-secrets copia los secretos de estos backends a Kubernetes en forma de secretos. Esto te permite administrar los secretos usando tu almacén secreto preferido e interactuar con los secretos de alguna manera. Kubernetes-native 

## Herramientas y recursos
<a name="_tools_and_resources"></a>
+  [Taller de inmersión en seguridad de Amazon EKS: cifrado de datos y gestión de secretos ](https://catalog.workshops.aws/eks-security-immersionday/en-US/13-data-encryption-and-secret-management) 