Esta página se ha traducido con Cloud Translation API.

Encriptar datos en tránsito en GKE con claves de encriptado gestionadas por el usuario

Estándar

En esta página se muestra cómo encriptar los datos en tránsito para las comunicaciones de pods entre nodos de Google Kubernetes Engine (GKE) mediante claves de encriptado gestionadas por el usuario. Este nivel de control sobre tus claves de cifrado es útil si trabajas en un sector regulado y tu empresa necesita cumplir auditorías de seguridad. En esta página, se explica cómo configurar entornos de un solo clúster y de varios clústeres, así como las prácticas recomendadas y las limitaciones.

Esta página está dirigida a especialistas en seguridad que necesitan un control preciso de las claves de cifrado para cumplir los requisitos de cumplimiento y seguridad. 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. Google Cloud

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

Datos en tránsito.
WireGuard, que GKE usa para cifrar en GKE Dataplane V2, además del cifrado predeterminado que proporcionan las NICs de las VMs.

De forma predeterminada, Google cifra todos los datos en tránsito entre las VMs a nivel del controlador de interfaz de red (NIC) para garantizar la confidencialidad de los datos en tránsito, independientemente del servicio o la aplicación que se ejecute en la VM (incluido GKE). Esta capa de cifrado se aplica a todos los nodos de GKE y al tráfico de pods. Google proporciona y gestiona las claves de cifrado.

Puedes habilitar el cifrado transparente entre nodos en entornos de un solo clúster y de varios clústeres. Para obtener más información sobre cómo funciona esta función, consulta Cómo funciona el cifrado transparente entre nodos con GKE.

Limitaciones

Esta función por sí sola no garantiza que Google no pueda acceder a las claves de cifrado almacenadas en la memoria de los nodos de GKE. En algunos entornos o jurisdicciones regulados, o para cumplir requisitos de cumplimiento específicos, es posible que quieras cifrar aún más estas claves y controlar el acceso. Para ello, te recomendamos que uses el cifrado transparente entre nodos con nodos de Confidential GKE.
El cifrado transparente entre nodos de GKE solo se admite en clústeres de GKE Dataplane V2.
No se admite Autopilot de GKE.
El cifrado transparente entre nodos de GKE usa WireGuard. WireGuard no cumple los requisitos de FIPS.
Las claves de cifrado no se rotan de forma dinámica. La rotación de claves debe gestionarse manualmente reiniciando los nodos.
El cifrado transparente entre nodos junto con los nodos confidenciales de GKE solo funciona en Container-Optimized OS (COS) y Ubuntu, no en Windows.
El cifrado transparente entre nodos no cifra el tráfico de red iniciado por el nodo de GKE o un pod que utilice hostNetwork.
El cifrado transparente entre nodos no cifra el tráfico de red enviado a un pod expuesto en un puerto de nodo. Aunque ExternalTrafficPolicy: Cluster esté configurado en el servicio, el tráfico reenviado desde el primer nodo que recibe tráfico del cliente al pod de backend no está cifrado.
El número máximo de nodos admitidos con el cifrado transparente entre nodos habilitado en configuraciones de un solo clúster o de varios clústeres es 500.
El cifrado transparente entre nodos puede provocar que los nodos estén sobreasignados. Es posible que se produzca un aumento medio del 15% de la CPU en los nodos n2-standard-8 con el SO Ubuntu y un rendimiento de 2 Gbps.

El aumento de la utilización de la CPU no se atribuye a ningún pod porque el kube-scheduler no lo detecta. El pod con más tráfico podría usar todos los recursos de CPU del nodo. Esto puede impedir que otros pods obtengan los recursos de CPU que necesitan, aunque estén configurados correctamente. Esto puede causar problemas en los pods que intentan ejecutar cargas de trabajo sensibles o que necesitan responder rápidamente a las solicitudes. Como solución alternativa, puedes dejar una cantidad significativa de CPU sin programar en los nodos que tengan habilitado el cifrado transparente entre nodos. También puedes programar un pod con una PriorityClass baja que tenga una solicitud de CPU grande, pero que nunca use esta CPU.
El cifrado transparente entre nodos conlleva una latencia de 150 microsegundos en dos nodos de la misma zona que no usan nodos confidenciales de GKE.
Si habilitas el cifrado transparente entre nodos, es posible que las funciones de observabilidad del tráfico que se usan para monitorizar el tráfico en los pods no funcionen como se espera, ya que los datos en tránsito se cifran con claves a las que no puede acceder la infraestructura de Google subyacente.
Cuando habilitas el cifrado transparente entre nodos, las direcciones IP de los pods no se ven en la VPC. Las funciones que dependen de la inspección de paquetes, como la creación de réplicas de paquetes y las reglas de cortafuegos de VPC basadas en CIDR de pods, no son compatibles con el cifrado transparente entre nodos.
Cuando habilitas el cifrado transparente entre nodos en clústeres conectados a diferentes subredes de VPC, debes crear manualmente reglas de cortafuegos para permitir las comunicaciones entre los nodos del clúster.
El cifrado transparente entre nodos desactiva algunas funciones de la capa 7 de GKE Dataplane V2. Por lo tanto, no puedes habilitar la política de red FQDN y el cifrado transparente entre nodos al mismo tiempo.
No puedes habilitar esta función al mismo tiempo que la visibilidad intranodo.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

El cifrado transparente entre nodos de GKE solo se admite en la versión 458.0.0 y posteriores de la CLI de Google Cloud, así como en las siguientes versiones de GKE:
- 1.26.10-gke.1024000 o versiones posteriores
- 1.27.7-gke.1506000 o versiones posteriores
- 1.28.2-gke.1098000 o versiones posteriores

Habilitar el cifrado transparente entre nodos con GKE

Puedes habilitar el cifrado transparente entre nodos con GKE en un solo clúster o en un entorno de varios clústeres.

Habilitar en un clúster nuevo

Para habilitar el cifrado transparente entre nodos en un clúster nuevo, sigue estos pasos:
```
gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Haz los cambios siguientes:
- CLUSTER_NAME por el nombre de tu clúster.
- CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
Nota: Te recomendamos que crees clústeres con el cifrado entre nodos habilitado en lugar de crearlos con el cifrado entre nodos inhabilitado y habilitarlo posteriormente. Si habilitas el cifrado entre nodos más adelante, es posible que se reinicien los grupos de nodos.
Para verificar la configuración, usa el siguiente comando para comprobar el estado del cifrado:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
El resultado debería ser similar al siguiente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Nota: Comprueba que el número de peers sea uno menos que el número de nodos de tu clúster. Por ejemplo, en un clúster con 24 nodos, el número de peers debe ser 23. Si el número de peers no es uno menos que el número de nodos del clúster, vuelve a reiniciar el agente anetd en tus nodos.

Habilitar en un clúster disponible

Para habilitar el cifrado transparente entre nodos en un clúster ya creado, sigue estos pasos:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --location=CONTROL_PLANE_LOCATION
```
Haz los cambios siguientes:
- CLUSTER_NAME por el nombre de tu clúster.
- CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
Nota: Te recomendamos que realices esta operación durante una ventana de mantenimiento, ya que podría interrumpir el tráfico a tu pod. La actualización del clúster y la instalación de la red de cifrado entre nodos pueden tardar varias horas en completarse.
Para comprobar que el comando de Google Cloud CLI se ha completado correctamente, sigue estos pasos :
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format json | jq .status
```
Haz los cambios siguientes:
- CLUSTER_NAME por el nombre de tu clúster.
- CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
Espera hasta que el estado sea "RUNNING". Si habilitas el cifrado entre nodos en GKE, los nodos se reiniciarán automáticamente. El reinicio del nodo y la aplicación de las políticas en los nodos nuevos pueden tardar varias horas.
Para confirmar que los nodos se han reiniciado, haz lo siguiente:
```
kubectl get nodes
```
Comprueba el campo AGE de cada nodo y continúa si el campo AGE refleja los nodos nuevos.
Para verificar la configuración, puedes usar el siguiente comando para comprobar el estado del cifrado:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
El resultado debería ser similar al siguiente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Verifica que el número de pares sea uno menos que el número de nodos de tu clúster. Por ejemplo, en un clúster con 24 nodos, el número de peers debe ser 23. Si el número de peers no es uno menos que el número de nodos del clúster, reinicia de nuevo el agente anetd en tus nodos.

Habilitar en varios clústeres

El cifrado transparente entre nodos no se admite en clústeres de Autopilot. Si tu flota incluye clústeres Autopilot, estos no podrán comunicarse con los clústeres estándar que tengan el cifrado habilitado.

Para habilitar el cifrado transparente entre nodos en un entorno de varios clústeres, sigue estos pasos:

Habilita el cifrado transparente entre nodos en un clúster nuevo o en un clúster ya creado.
Registre su clúster en una flota.
Habilita el cifrado transparente entre nodos para la flota:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Sustituye PROJECT_ID por el ID del proyecto.
Verifica el estado de todos los nodos:
```
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
```
El resultado debería ser similar al siguiente:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Nota: Comprueba que el número de peers sea uno menos que el número de nodos de todos los clústeres registrados. Por ejemplo, en un clúster con 24 nodos, el número de peers debe ser 23. Si el número de peers no es uno menos que el número de nodos del clúster, reinicia el agente anetd en tus nodos.

Inhabilitar el cifrado transparente entre nodos

En algunos casos, puede que quieras inhabilitar el cifrado transparente entre nodos en tu clúster de GKE para mejorar el rendimiento o solucionar problemas de conectividad de tu aplicación. Antes de continuar con esta operación, ten en cuenta lo siguiente:

El cifrado transparente entre nodos está habilitado en todo el clúster y no se puede inhabilitar parcialmente en recursos de Kubernetes concretos, como espacios de nombres o pods.
Realiza esta operación durante una ventana de mantenimiento, ya que interrumpirá el tráfico de tu pod.

Inhabilitar en un solo clúster

Para inhabilitar el cifrado transparente entre nodos en un solo clúster, sigue estos pasos:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --in-transit-encryption none

Haz los cambios siguientes:

CLUSTER_NAME: con el nombre de tu clúster.
CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

Inhabilitar en un clúster que forma parte de una flota

Puedes desactivar el cifrado de un clúster de una flota con cualquiera de las dos opciones siguientes:

Para eliminar completamente el clúster de la flota, dalo de baja.
También puedes mantener el clúster en la flota, pero inhabilitar el cifrado:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sustituye PROJECT_ID por el ID del proyecto.

Si inhabilitas el cifrado con este comando, se iniciará la eliminación de los nodos remotos de la lista de peers de Wireguard de cada clúster. Este proceso puede tardar varios minutos en completarse, en función del número de clústeres y nodos implicados. Para ver el número de peers actualizado, tendrás que actualizar manualmente la lista de peers de WireGuard en cada clúster. Puedes usar tu herramienta de gestión de clústeres o el siguiente comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Inhabilitar en toda una flota de clústeres

Para inhabilitar el cifrado transparente entre nodos en una flota, sigue estos pasos:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sustituye PROJECT_ID por el ID del proyecto.
Para inhabilitar el cifrado transparente entre nodos y quitar la API que ya no se usa, inhabilita la API de Dataplane V2 de GKE a nivel de flota. Se desactivará el controlador de GKE Dataplane V2 que se esté ejecutando en tu flota.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Sustituye PROJECT_ID por el ID del proyecto.

Nota: Esta API se encarga de la función de cifrado transparente entre nodos de tu flota. Antes de inhabilitar esta API, asegúrate de que no la use ningún otro elemento de tu flota para evitar comportamientos inesperados.

Para gestionar de forma eficiente los clústeres con el mismo nombre y activar el cifrado multiclúster, sigue estos pasos:
1. Anula el registro del clúster antiguo de la flota antes de crear uno nuevo con el mismo nombre.
2. Vuelve a registrar el nuevo clúster cuando lo hayas recreado.
3. Si olvidas anular el registro de un clúster, elimina la suscripción antigua y vuelve a crear el clúster con una suscripción nueva.
Si no sigues estos pasos, es posible que el cifrado multiclúster no se active en el nuevo clúster hasta que se vuelva a crear la pertenencia a la flota.

Cómo funciona el cifrado transparente entre nodos con GKE

En las siguientes secciones se describe cómo funciona el cifrado transparente entre nodos cuando lo habilitas en tu clúster:

Cifrado del tráfico de red entre dos pods de nodos diferentes

Si el cifrado transparente entre nodos está habilitado, GKE Dataplane V2 cifra el tráfico de pod a pod si los pods están en nodos diferentes, independientemente del clúster al que pertenezcan esos nodos. Cuando los clústeres forman parte de la misma flota, pertenecen al mismo dominio de cifrado.

Los clústeres con diferentes configuraciones de cifrado transparente entre nodos pueden coexistir en la misma flota. Si tienes un entorno de varios clústeres en el que solo algunos clústeres usan el cifrado transparente entre nodos, se aplican las siguientes consideraciones:

La comunicación entre pods de nodos del mismo clúster se cifra mediante el par de claves pública y privada.
Falla la comunicación entre pods de un nodo de un clúster que tiene habilitado el cifrado transparente entre nodos y un nodo de un clúster que no tiene habilitado el cifrado transparente entre nodos.

Generación y uso de claves de cifrado

Cuando la función está habilitada, cada nodo de GKE del clúster genera automáticamente un par de claves pública y privada, conocidas como claves de cifrado.

La clave privada se almacena en la memoria (no en el disco) y nunca sale del nodo. Si usas nodos de Confidential GKE Nodes, se reduce aún más el riesgo de que las claves se vean comprometidas, ya que la memoria del nodo también está cifrada (con claves diferentes).
La clave pública se comparte con otros nodos mediante el plano de control de GKE Dataplane V2 y todos los nodos del mismo dominio de cifrado pueden acceder a ella.

Una vez que se han intercambiado las claves, cada nodo puede establecer un túnel WireGuard con otros nodos del mismo dominio de cifrado. Cada túnel es único para un par de nodos determinado.

Ten en cuenta lo siguiente cuando trabajes con los pares de claves privadas o públicas y la clave de sesión:

Par de claves privada y pública:
- La clave pública se distribuye en el clúster y todos los nodos del clúster pueden acceder a ella.
- El par de claves se rota cuando se reinicia el nodo. GKE no rota las claves a intervalos periódicos. Para activar manualmente una rotación de claves, agota la batería y reinicia el nodo. De esta forma, se invalidará el par de claves original y se generará uno nuevo.
Clave de sesión:
- Esta clave no se puede configurar.
- Esta clave se rota periódicamente cada dos minutos.
- La clave de sesión es exclusiva de los nodos implicados en el túnel.