Cifrado de datos y gestión de secretos - Amazon EKS

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

Cifrado en reposo

Hay tres opciones diferentes de almacenamiento nativo de AWS que puede usar con Kubernetes: EBS, EFS y for Lustre. FSx Las tres ofrecen cifrado en reposo mediante una clave gestionada por el servicio o una clave maestra del cliente (CMK). Para EBS, puede utilizar el controlador de almacenamiento integrado en el árbol o el controlador CSI de EBS. Ambos incluyen parámetros para cifrar volúmenes y suministrar una CMK. Para EFS, puede utilizar el controlador CSI de EFS; sin embargo, a diferencia de EBS, el controlador CSI de EFS no admite el aprovisionamiento dinámico. Si desea utilizar EFS con EKS, tendrá que aprovisionar y configurar el cifrado en reposo para el 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. 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 admite el aprovisionamiento dinámico de los sistemas de archivos Lustre. De forma predeterminada, cifra los datos con una clave gestionada por el servicio, 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 pods de EKS Fargate se cifran de forma predeterminada mediante un algoritmo criptográfico AES-256 estándar del sector. No es necesario realizar ninguna modificación en la aplicación, ya que el servicio gestiona el cifrado y el descifrado sin problemas.

Cifre los datos en reposo

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

Gire los suyos periódicamente CMKs

Configure KMS para que rote automáticamente su CMKs. De este modo, las claves se rotarán una vez al año y se guardarán las antiguas indefinidamente para poder seguir descifrando los datos. Para obtener información adicional, consulte Rotación de las claves maestras del cliente

Utilice los puntos de acceso EFS para simplificar el acceso a los conjuntos de datos compartidos

Si ha compartido conjuntos de datos con diferentes permisos de archivos 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 en día, si quieres usar un punto de acceso (AP), tendrás que hacer referencia al AP en el volumeHandle parámetro del PV.

importante

A partir del 23 de marzo de 2021, el controlador CSI de EFS admite el aprovisionamiento dinámico de 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 uso compartido 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 de Amazon EFS CSI para obtener más información.

Administración de secretos

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 cifrado EBS. Un pod puede recuperar un objeto secreto de Kubernetes haciendo referencia al secreto de. 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 concreto.

aviso

El autorizador de nodos permite al Kubelet leer todos los secretos almacenados en el nodo.

Utilice AWS KMS para el cifrado de sobres de los secretos de Kubernetes

Esto le permite cifrar sus secretos con una clave de cifrado de datos (DEK) única. A continuación, el DEK se cifra con una clave de cifrado clave (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 texto plano y solo el servidor API de Kubernetes puede descifrarlos. Para obtener más información, consulta el artículo sobre cómo utilizar el soporte del proveedor de cifrado EKS para obtener más información sobre la defensa

Audite el uso de Kubernetes Secrets

En EKS, active el registro de auditoría y cree un filtro de CloudWatch métricas y una alarma que le avisen 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

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

Utilice espacios de nombres separados para aislar los secretos de distintas aplicaciones

Si tiene secretos que no se pueden compartir entre las 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

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

Utilice un proveedor de secretos externo

Existen varias alternativas viables al uso de los secretos de Kubernetes, como AWS Secrets Manager y Hashicorp's Vault. Estos servicios ofrecen funciones como controles de acceso detallados, cifrado seguro y rotación automática de los secretos que no están disponibles en Kubernetes Secrets. Sealed Secrets de Bitnami es otro enfoque que utiliza el cifrado asimétrico para crear «secretos sellados». Se usa una clave pública para cifrar el secreto, mientras que la clave privada que se usa para descifrar el secreto se guarda dentro del clúster, lo que le permite almacenar secretos sellados de forma segura en sistemas de control de código fuente como Git. Para obtener más información, consulta Cómo gestionar el despliegue de secretos en Kubernetes mediante 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. The Secret Store CSI Driver es un proyecto comunitario que utiliza el modelo de controladores CSI para recuperar secretos de almacenes secretos externos. Actualmente, el controlador es compatible con AWS Secrets Manager, Azure, Vault y GCP. El proveedor de AWS es compatible con AWS Secrets Manager y AWS Parameter Store. También se puede configurar para rotar los secretos cuando caduquen y puede sincronizar los secretos de AWS Secrets Manager con los secretos de Kubernetes. La sincronización de secretos puede resultar útil cuando necesita hacer referencia a un secreto como variable de entorno en lugar de leerlo de un volumen.

nota

Cuando el controlador CSI del almacén de secretos tiene que buscar un secreto, asume la función IRSA asignada al módulo que hace referencia a un secreto. El código de esta operación se encuentra aquí.

Para obtener información adicional sobre el proveedor de secretos y configuración de AWS (ASCP), consulte los siguientes recursos:

external-secrets es otra forma de utilizar 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 secreto externo, external-secrets copia los secretos de estos backends a Kubernetes como secretos. Esto te permite gestionar los secretos con tu tienda de secretos preferida e interactuar con ellos de una forma nativa de Kubernetes.

Herramientas y recursos