Encriptar secretos en la capa de aplicación

En este tutorial se muestra cómo encriptar secretos de Kubernetes en la capa de aplicación mediante una clave que gestionas en Cloud Key Management Service (Cloud KMS). El proceso de cifrado de secretos proporciona una capa adicional de seguridad para las cargas de trabajo sensibles.

Esta página está dirigida a especialistas en seguridad que quieran cifrar secretos. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Trusted Cloud by S3NS

Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:

• Rotación de claves
• Encriptado envolvente

Información general

De forma predeterminada, Google Kubernetes Engine (GKE) cifra el contenido de los clientes almacenado en reposo, incluidos los secretos. GKE gestiona este cifrado predeterminado por ti sin que tengas que hacer nada más. El encriptado de secretos en la capa de aplicación ofrece un estrato más de seguridad para los datos sensibles, como los secretos. Utilizas una clave gestionada con Cloud KMS para cifrar los datos en reposo en la capa de aplicación.

El estado de los objetos de la API de Kubernetes de tu clúster, como los secretos, se almacena en una base de datos. Esta base de datos de estado del clúster usa una de las siguientes tecnologías:

• etcd: las instancias de la base de datos etcd se ejecutan en todas las VMs del plano de control. El encriptado de secretos de la capa de aplicación ayuda a protegerse frente a los atacantes que obtienen acceso a una copia sin conexión de etcd.
• Spanner: GKE ejecuta una base de datos de Spanner en la infraestructura de Google. La base de datos está separada de las VMs del plano de control del clúster y no se puede descargar como copia sin conexión.

Para usar el cifrado de secretos de la capa de aplicación, primero debes crear una clave de Cloud KMS y dar acceso a la clave a la cuenta de servicio de GKE. Puedes usar una clave que tenga cualquiera de los niveles de protección admitidos por Cloud KMS.

Asegúrate de que la clave esté en la misma ubicación que el clúster para reducir la latencia y evitar casos en los que los recursos dependan de servicios distribuidos en varios dominios de errores. Después de crear una clave, puede habilitar la función en un clúster nuevo o en uno que ya tenga especificando la clave que quiera usar. Cuando habilitas la función, GKE cifra todos los secretos nuevos y actuales con tu clave de cifrado.

Encriptado en sobre

Kubernetes ofrece el cifrado envolvente de secretos con un proveedor de KMS, lo que significa que se usa una clave local, denominada clave de cifrado de datos (DEK), para cifrar los secretos. La DEK se cifra con otra clave llamada clave de cifrado de claves (KEK). Kubernetes no almacena la KEK.

El cifrado de envolvente tiene las siguientes ventajas:

• Rendimiento mejorado en comparación con el cifrado de clave pública: GKE solo usa la API de Cloud KMS para cifrar nuevas DEKs con la KEK o para descifrar una DEK cuando la caché local está vacía.
• Mejor gestión de las claves a gran escala: una sola KEK puede cifrar varias DEKs. El número de claves que necesitas almacenar en el servicio Cloud KMS es mucho menor que el número de claves que encriptan tus datos.
• Posibilidad de usar una raíz de confianza central: los secretos almacenados en Kubernetes pueden depender de una raíz de confianza externa. Esto significa que puedes usar una raíz de confianza central, por ejemplo, un módulo de seguridad de hardware, para todos tus secretos. Un atacante que acceda a tus contenedores sin conexión no podrá obtener tus secretos.

Con el cifrado de secretos de la capa de aplicación en GKE, GKE cifra tus secretos mediante DEKs locales y el proveedor AES-CBC. GKE encripta las DEKs con una KEK que gestionas en Cloud KMS.

Para obtener más información sobre el cifrado envolvente, consulta Cifrado envolvente.

Qué ocurre cuando creas un secreto

Cuando creas un secreto, ocurre lo siguiente:

1. El servidor de la API de Kubernetes genera una DEK única para el secreto mediante un generador de números aleatorios.

2. El servidor de la API de Kubernetes usa la DEK de forma local para cifrar el Secret.

3. El complemento KMS envía la DEK a Cloud KMS para encriptarla. El complemento KMS usa la cuenta de servicio de GKE de tu proyecto para autenticarse en Cloud KMS.

4. Cloud KMS encripta la DEK con la KEK y la envía de vuelta al complemento KMS.

5. El servidor de la API de Kubernetes guarda el Secret encriptado y la DEK encriptada. La DEK en texto sin formato no se guarda en un disco y solo se almacena en la memoria del servidor de la API.

6. El servidor de la API de Kubernetes crea una entrada de caché que asigna la DEK cifrada a la DEK de texto sin formato en memoria. De esta forma, el servidor de la API puede descifrar el secreto sin usar Cloud KMS.

Cuando un cliente solicita un secreto al servidor de la API de Kubernetes, ocurre lo siguiente:

1. El servidor de la API de Kubernetes recupera el secreto cifrado y la DEK cifrada.

2. El servidor de la API de Kubernetes comprueba si hay una entrada de asignación en la caché y descifra el secreto sin usar Cloud KMS.

3. Si no se encuentra ninguna entrada en la caché, el complemento KMS envía la DEK a Cloud KMS para descifrarla con la KEK. A continuación, la DEK descifrada se usa para descifrar el secreto.

4. El servidor de la API de Kubernetes devuelve el secreto descifrado al cliente.

Qué ocurre cuando destruyes una clave

Si tienes previsto destruir una versión antigua de la KEK después de una rotación de claves, usa la nueva versión de la KEK para volver a cifrar el secreto primero. Si quieres, puedes conservar la versión anterior de la KEK para evitar volver a encriptar los secretos, pero se te seguirá facturando por todas las KEKs activas en Cloud KMS. Para obtener información sobre los precios, consulta los precios de Cloud KMS.

A menos que uses una proyección de volumen de token de cuenta de servicio, las cuentas de servicio que usan tus cargas de trabajo en GKE también usan secretos y, si se destruye una clave, dejan de estar disponibles. Si no se puede acceder a ellos, las cargas de trabajo fallarán.

Se aplican las siguientes excepciones:

• Los pods que ya tengan acceso a los secretos como volúmenes montados o variables de entorno conservarán el acceso.

• El servidor de la API de Kubernetes puede seguir usando entradas de asignación de DEK almacenadas en caché para descifrar un secreto después de destruir la KEK. Esto permite que los pods reiniciados o reprogramados accedan al secreto, a menos que se dé una de las siguientes situaciones:

  • Se reinicia el plano de control del clúster.
  • Se reinicia el pod del servidor de la API de Kubernetes.
  • La entrada de asignación de DEK del secreto no está en la caché del servidor de la API de Kubernetes.

Antes de destruir una KEK, comprueba si la está usando tu clúster. También puedes crear una política de alertas para la destrucción de claves en Cloud KMS. Destruye las versiones anteriores de KEK solo cuando tengas la certeza de que no hay datos en tu clúster cifrados con la versión anterior. Antes de destruir una KEK, comprueba si la clave está en uso. Para obtener más información, consulta Destruir y restaurar versiones de claves.

Puedes programar la eliminación de una versión de clave después de un periodo configurable. Durante ese tiempo, si cambias de opinión, puedes restaurar la versión de la clave para evitar que se elimine. Sin embargo, una vez que llegue la hora programada para la eliminación y se elimine la versión de la clave, esta acción será irreversible. Los datos cifrados con esta versión de la clave no se podrán descifrar de forma permanente.

Antes de empezar

• Para hacer los ejercicios de este tema, necesitas dos proyectos: Trusted Cloud

  • Proyecto de claves: aquí es donde se crea una KEK.

  • Proyecto de clúster: aquí es donde se crea un clúster que habilita el cifrado de secretos en la capa de aplicación.

  Puedes usar el mismo proyecto para tu proyecto de clave y tu proyecto de clúster. Sin embargo, lo recomendable es usar proyectos independientes.

• En tu proyecto de claves, comprueba que hayas habilitado la API Cloud KMS.

  Habilitar la API Cloud KMS

• En tu proyecto de claves, el usuario que cree el conjunto de claves y la clave debe tener los siguientes permisos de gestión de identidades y accesos:

  • cloudkms.keyRings.getIamPolicy
  • cloudkms.keyRings.setIamPolicy

  Estos permisos (y muchos más) se conceden al rol de gestión de identidades y accesos predefinido roles/cloudkms.admin. Puedes consultar más información sobre cómo conceder permisos para gestionar claves en la documentación de Cloud KMS.

• En el proyecto de tu clúster, comprueba que has habilitado la API de Google Kubernetes Engine.

  Habilitar la API de Google Kubernetes Engine

• Asegúrate de que has instalado Google Cloud CLI.

• Actualiza gcloud a la versión más reciente:

  gcloud components update

Crear una clave de Cloud KMS

Para crear una clave de Cloud KMS, primero debes crear un conjunto de claves. Las claves y los conjuntos de claves son recursos regionales. Cuando crees un conjunto de claves, especifica una ubicación que coincida con la de tu clúster de GKE:

• Un clúster zonal debe usar un conjunto de claves de una región de superconjunto. Por ejemplo, un clúster de la zona us-central1-a solo puede usar una clave de la región us-central1.

• Un clúster regional debe usar un conjunto de claves de la misma ubicación. Por ejemplo, un clúster de la región asia-northeast1 debe protegerse con un conjunto de claves de la región asia-northeast1.

La región global de Cloud KMS no se puede usar con GKE.

Puedes usar gcloud CLI o la Trusted Cloud consola.

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

Concede permiso para usar la llave

La cuenta de servicio de GKE de tu proyecto de clúster tiene el siguiente nombre:

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com

Sustituye CLUSTER_PROJECT_NUMBER por el número de proyecto de tu clúster. Para encontrar el número de tu proyecto con la CLI de gcloud, ejecuta el siguiente comando:

gcloud projects describe CLUSTER_PROJECT_ID \
    --format="value(projectNumber)"

Para conceder acceso a la cuenta de servicio, puedes usar la consola o la CLI de gcloud. Trusted Cloud

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

Asegúrate de que la clave tenga suficiente cuota si es una clave de Cloud HSM

Si usas una clave de Cloud HSM, el Trusted Cloud by S3NS proyecto que contiene la clave Trusted Cloud by S3NS está limitado por tu cuota de claves. Asegúrate de tener suficiente cuota para usar tus claves de Cloud HSM con el encriptado de secretos de la capa de aplicación. Si se agota tu cuota, es posible que tus nodos pierdan la conectividad con el plano de control de tu clúster.

Habilita el encriptado de secretos de la capa de aplicación

Puedes habilitar el encriptado de secretos de la capa de aplicación en clústeres estándar y Autopilot de GKE nuevos o ya creados mediante la CLI de gcloud o la consola de Trusted Cloud .

Habilitar en un clúster nuevo

Puedes crear un clúster con el cifrado de secretos de la capa de aplicación habilitado mediante laTrusted Cloud consola o la CLI de gcloud.

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Habilitar en un clúster disponible

Puedes usar la CLI de gcloud o la Trusted Cloud consola para actualizar un clúster y usar el cifrado de secretos de la capa de aplicación. GKE cifra todos tus secretos, tanto los que ya tienes como los nuevos, con la clave de cifrado que especifiques.

Si actualizas un clúster para que use el cifrado de secretos de la capa de aplicación, se reiniciará el plano de control del clúster. En los clústeres zonales, el plano de control deja de estar disponible.

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Actualizar una clave de Cloud KMS

Puedes usar la CLI de gcloud o la Trusted Cloud consola para actualizar un clúster y usar una nueva clave de Cloud KMS.

Si actualizas un clúster para que use una nueva clave de Cloud KMS, se reiniciará el plano de control del clúster. En los clústeres zonales, el plano de control deja de estar disponible.

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Inhabilita el encriptado de secretos de la capa de aplicación

Para inhabilitar el cifrado de secretos de la capa de aplicación, puedes usar la CLI de gcloud o laTrusted Cloud consola.

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Verificar que el encriptado de secretos de la capa de aplicación esté habilitado

Puedes comprobar si un clúster usa el cifrado de secretos de la capa de aplicación mediante la consola deTrusted Cloud o la CLI de gcloud.

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

keyName=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME;state=ENCRYPTED

Rotar las claves

Cuando realizas una rotación de claves, tus secretos se mantienen cifrados con la versión anterior de la clave de cifrado de claves (KEK). Para asegurarte de que una versión más reciente de la KEK envuelve un secreto, vuelve a cifrar el secreto después de la rotación de claves.

Por ejemplo, creas y almacenas un secreto, Secret1. Se cifra con DEK1, que a su vez se envuelve con KEKv1.

Después de que rote la KEK, vuelve a cifrar Secret1 para que se encapsule con DEK2, que a su vez se encapsula con KEKv2, la KEK rotada.

La rotación de la versión de la clave es una operación de coherencia eventual y puede haber un retraso antes de que la nueva versión de la clave entre en vigor. Para obtener más información, consulta Coherencia de las versiones de clave.

Volver a cifrar tus secretos

Después de rotar una clave, debes volver a cifrar tus secretos para envolverlos con la nueva versión de la KEK. Puedes volver a cifrar tus secretos de una de las siguientes formas:

• Manualmente, ejecutando un comando kubectl en un terminal.
• Automáticamente, mediante el uso de una carga de trabajo recurrente, como un CronJob, para ejecutar un kubectl comando a intervalos regulares.

Después de rotar una clave, espera al menos tres horas para que la nueva versión sea coherente. A continuación, activa el nuevo cifrado ejecutando un comando como el siguiente:

kubectl get secrets --namespace=NAMESPACE -o json \
    | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Haz los cambios siguientes:

• NAMESPACE: el espacio de nombres en el que se van a actualizar los secretos. En los clústeres estándar, también puedes usar la marca --all-namespaces para actualizar todos los secretos del clúster con el mismo comando. En los clústeres de Autopilot, solo puedes actualizar los espacios de nombres que te pertenezcan.
• TIME: cadena que indica cuándo se produce la rotación (por ejemplo, 20200909-090909).

Después de rotar las claves, la versión anterior seguirá existiendo y puede generar costes. La eliminación de una versión de clave es permanente, así que asegúrate de que la versión de clave anterior ya no se esté usando antes de eliminarla. Para obtener más información, consulta Ver el uso de las claves.

Limitaciones

• GKE admite hasta 30.000 secretos por clúster para el cifrado de secretos de la capa de aplicación. Si almacenas más de 30.000 secretos, es posible que tu clúster se vuelva inestable durante la actualización, lo que podría provocar una interrupción en tus cargas de trabajo.
• Asegúrate de que el tamaño medio de los metadatos de un secreto en cada espacio de nombres sea inferior a 5 KiB. Si el tamaño medio de los metadatos supera los 5 KiB, es posible que tu clúster entre en un estado incorrecto en el que algunos secretos se cifren y otros se descifren después de habilitar o inhabilitar la función.

• Debes seleccionar una clave en la misma región que el clúster. Por ejemplo, un clúster zonal de us-central1-a solo puede usar una clave de la región us-central1. En el caso de los clústeres regionales, las claves deben estar en la misma ubicación para reducir la latencia y evitar que los recursos dependan de servicios distribuidos en varios dominios de fallos.

  No es necesario que la clave esté en el mismo proyecto que el clúster. Para obtener más información sobre las ubicaciones admitidas de Cloud KMS, consulta las Trusted Cloud by S3NS ubicaciones.

• GKE solo admite claves de Cloud KMS. No puedes usar otro proveedor de KMS de Kubernetes ni otro proveedor de cifrado.

Solución de problemas

Para obtener información sobre cómo solucionar problemas relacionados con el encriptado de secretos en la capa de aplicación, incluidos los problemas con las actualizaciones de encriptado de secretos fallidas, consulta el artículo Solucionar problemas relacionados con el encriptado de secretos en la capa de aplicación.

La clave de Cloud KMS está inhabilitada

La cuenta de servicio predeterminada de GKE no puede usar una clave de Cloud KMS inhabilitada para el encriptado de secretos de la capa de aplicación.

Para volver a habilitar una clave inhabilitada, consulta Habilitar una versión de clave inhabilitada.

La versión de la clave de Cloud KMS se ha destruido

Si el estado del clúster contiene el mensaje: KEY_VERSION_URI is not enabled, current state is: DESTROYED, significa que la versión de la clave utilizada para el cifrado de secretos de la capa de aplicación se ha destruido.

Sustituye KEY_VERSION_URI por el URI de la versión de la clave.

Siguientes pasos

• Consulta más información sobre los secretos de Kubernetes.
• Más información sobre la gestión de secretos con Cloud KMS
• Consulta cómo proteger tu clúster.