Encripta los datos en tránsito en GKE con claves de encriptación administradas por el usuario

Estándar

En esta página, se muestra cómo habilitar la encriptación de datos en tránsito para las comunicaciones de Pods en nodos de Google Kubernetes Engine (GKE) con claves de encriptación administradas por el usuario.

De forma predeterminada, Googleencripta todos los datos en tránsito entre VMs a nivel del controlador de interfaz de red (NIC) para garantizar la confidencialidad de los datos en tránsito, sin importar qué servicio o aplicación se ejecute en la VM (incluido GKE). Esta capa de encriptación se aplica a todos los nodos de GKE y al tráfico de Pods. Google proporciona y administra las claves de encriptación.

Con la encriptación transparente entre nodos para GKE, Google te proporciona más control sobre las claves de encriptación utilizadas para encriptar el tráfico de Pods entre los nodos de GKE. GKE realiza esta encriptación con WireGuard en GKE Dataplane V2, además de la encriptación predeterminada proporcionada por los NIC de las VMs.

Proporcionar este control sobre las claves de encriptación directamente en GKE es útil si estás en una industria regulada y tienes la necesidad empresarial de realizar auditorías de cumplimiento y seguridad.

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

Limitaciones

Esta función por sí sola no garantiza que Google no pueda acceder a las claves de encriptación almacenadas en la memoria del nodo de GKE. En algunos entornos o jurisdicciones regulados, o para cumplir con requisitos de cumplimiento específicos, es posible que debas encriptar aún más estas claves y controlar el acceso. Para ello, te recomendamos que uses la encriptación transparente entre nodos con Confidential GKE Nodes que usan claves de encriptación administradas por el cliente (CMEK). Los Confidential GKE Nodes que usan CMEK encriptan el contenido de la memoria de los nodos con claves que administras.
La encriptación transparente entre nodos para GKE solo es compatible con los clústeres de GKE Dataplane V2.
Autopilot de GKE no es compatible.
La encriptación transparente entre nodos de GKE usa WireGuard. WireGuard no cumple con FIPS.
Las claves de encriptación no se rotan de forma dinámica. La rotación de claves debe controlarse de forma manual mediante el reinicio de los nodos.
La encriptación transparente entre nodos junto con los Confidential GKE Nodes funciona solo en Container-Optimized OS (COS) y Ubuntu, y no en Windows.
La encriptación transparente entre nodos no encripta el tráfico de red que inicia el nodo de GKE o un Pod con hostNetwork.
La encriptación transparente entre nodos no encripta el tráfico de red enviado a un Pod expuesto en un puerto de nodo. Incluso cuando ExternalTrafficPolicy: Cluster se configura en el Service, el tráfico reenviado desde el primer nodo que recibe tráfico del cliente hacia el Pod de backend no está encriptado.
La cantidad máxima de nodos que se admiten con la encriptación transparente entre nodos habilitada para configuraciones de un solo clúster o de varios clústeres es 500.
La encriptación transparente entre nodos puede provocar que los nodos se suscriban en exceso. Se espera un aumento del 15% de la CPU en promedio en los nodos n2-standard-8 con el SO Ubuntu y una capacidad de procesamiento de 2 Gbps.

El aumento en el uso de CPU no se atribuye a ningún Pod porque kube-scheduler no lo detecta. El pod con mayor tráfico podría usar todos los recursos de CPU del nodo. Esto puede evitar que otros Pods obtengan los recursos de CPU que necesitan, incluso si están configurados de forma correcta. Esto puede causar problemas para los Pods que intentan ejecutar cargas de trabajo sensibles o que necesitan poder responder a las solicitudes con rapidez. Como solución alternativa, puedes mantener una cantidad significativa de CPU sin programar en los nodos que tienen habilitada la encriptación transparente entre nodos. Como alternativa, puedes programar un Pod con una PriorityClass baja que tenga una solicitud de CPU grande, pero nunca use esta CPU.
La encriptación transparente entre nodos genera 150 microsegundos de latencia en dos nodos de la misma zona que no usan Confidential GKE Nodes.
Cuando habilitas la encriptación transparente entre nodos, es posible que las funciones de observabilidad del tráfico que se usan para realizar un seguimiento del tráfico en los Pods no funcionen como se espera porque los datos en tránsito se encriptan con claves a las que no puede acceder la infraestructura de Google subyacente.
Cuando habilitas la encriptación transparente entre nodos, las direcciones IP de Pod no son visibles en la VPC. Las funciones que dependen de la inspección de paquetes, como la duplicación de paquetes y las reglas de firewall de VPC basadas en CIDR de Pod, no son compatibles con la encriptación transparente entre nodos.
Cuando habilitas la encriptación transparente entre nodos en los clústeres conectados a diferentes subredes de VPC, debes crear de forma manual reglas de firewall para permitir las comunicaciones entre los nodos del clúster.
La encriptación transparente entre nodos desactiva algunas capacidades de la capa 7 de GKE Dataplane V2. Como resultado, no puedes habilitar la política de red de FQDN ni la encriptación transparente entre nodos al mismo tiempo.
No puedes habilitar esta función al mismo tiempo que la visibilidad dentro de los nodos.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Sigue las instrucciones para habilitar GKE Enterprise.
La encriptación transparente entre nodos de GKE solo es compatible con la versión 458.0.0 y posteriores de Google Cloud CLI y las siguientes versiones de GKE:
- 1.26.10-gke.1024000 o superior
- 1.27.7-gke.1506000 o superior
- 1.28.2-gke.1098000 o superior

Habilita la encriptación transparente entre nodos con GKE

Puedes habilitar la encriptación transparente entre nodos con GKE en un solo clúster o en un entorno multiclúster.

Habilita la encriptación transparente entre nodos en un clúster nuevo

Para habilitar la encriptación transparente entre nodos en un clúster nuevo, sigue estos pasos:
```
gcloud container clusters create CLUSTER_NAME \
    --region=REGION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Reemplaza lo siguiente:
- CLUSTER_NAME por el nombre del clúster.
- REGION por la región de procesamiento del clúster.
Nota: Recomendamos que crees clústeres nuevos con la encriptación entre nodos habilitada, en lugar de crearlos con la encriptación entre nodos inhabilitada y habilitarla posteriormente. Habilitar la encriptación entre nodos más adelante puede provocar que se reinicie el grupo de nodos.
Para verificar tu configuración, usa el siguiente comando para comprobar el estado de la encriptación:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
El resultado es similar al siguiente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Nota: Verifica que la cantidad de intercambios de tráfico sea uno menos que la cantidad de nodos de tu clúster. Por ejemplo, en un clúster con 24 nodos, la cantidad de pares debe ser 23. Si la cantidad de intercambios de tráfico no es uno menos que la cantidad de nodos en el clúster, vuelve a reiniciar el agente anetd en tus nodos.

Habilita la encriptación transparente entre nodos en un clúster existente

Para habilitar la encriptación transparente entre nodos en un clúster existente, sigue estos pasos:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --region=REGION
```
Reemplaza lo siguiente:
- CLUSTER_NAME por el nombre del clúster.
- REGION por la región de procesamiento del clúster.
Nota: Te recomendamos que realices esta operación durante un período de mantenimiento, ya que esta operación puede interrumpir el tráfico a tu Pod. La actualización del clúster y la instalación de la red de encriptación entre nodos pueden requerir varias horas para completarse.
Para verificar que el comando de Google Cloud CLI se haya completado correctamente, sigue estos pasos:
```
gcloud container clusters describe CLUSTER_NAME \
    --region=REGION \
    --format json | jq .status
```
Reemplaza lo siguiente:
- CLUSTER_NAME por el nombre del clúster.
- REGION por la región de procesamiento del clúster.
Espera hasta que el estado muestre "En ejecución". Si habilitas la encriptación entre nodos en GKE, se reiniciarán automáticamente los nodos. Es posible que el reinicio del nodo tarde varias horas y que los nodos nuevos apliquen políticas.
Para confirmar que los nodos se reiniciaron, haz lo siguiente:
```
kubectl get nodes
```
Verifica el campo AGE de cada nodo y continúa si el campo AGE refleja los nodos nuevos
Para verificar tu configuración, puedes usar el siguiente comando para verificar el estado de la encriptación:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
El resultado es similar al siguiente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Verifica que la cantidad de intercambios de tráfico sea uno menos que la cantidad de nodos en tu clúster. Por ejemplo, en un clúster con 24 nodos, la cantidad de intercambios de tráfico debe ser 23. Si la cantidad de intercambios de tráfico no es uno menos que la cantidad de nodos en el clúster, vuelve a reiniciar el agente anetd en tus nodos.

Habilita la encriptación transparente entre nodos en varios clústeres

La encriptación transparente entre nodos no es compatible con los clústeres de Autopilot. Si tu flota incluye clústeres de Autopilot, no podrán comunicarse con los clústeres de Standard que tengan habilitada la encriptación.

Para habilitar la encriptación transparente entre nodos en un entorno de varios clústeres, haz lo siguiente:

Habilita la encriptación transparente entre nodos en un clúster nuevo o en un clúster existente.
Registra tu clúster en una flota.
Habilita la encriptación transparente entre nodos para la flota:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Reemplaza PROJECT_ID con el ID del proyecto.
Verifica el estado en 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 es similar al siguiente:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Nota: VVerifica que la cantidad de intercambios de tráfico sea uno menor que la cantidad de nodos de todos los clústeres registrados. Por ejemplo, en un clúster con 24 nodos, el número de intercambios de tráfico debe ser 23. Si la cantidad de intercambios de tráfico no es uno menos que la cantidad de nodos en el clúster, vuelve a reiniciar el agente anetd en tus nodos.

Inhabilita la encriptación transparente entre nodos

En algunos casos, es posible que desees inhabilitar la encriptación 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:

La encriptación transparente entre nodos está habilitada para todo el clúster y no puedes inhabilitarla de forma parcial en recursos individuales de Kubernetes, como espacios de nombres o Pods
Realiza esta operación durante un período de mantenimiento, ya que esta interrumpirá el tráfico del Pod.

En un solo clúster

Para inhabilitar la encriptación transparente entre nodos en un solo clúster, haz lo siguiente:

gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --in-transit-encryption none

Reemplaza lo siguiente:

CLUSTER_NAME: por el nombre del clúster.
REGION: por la región de procesamiento de tu clúster.

Inhabilita la función en un clúster que forma parte de una flota

Puedes desactivar la encriptación para un clúster de una flota mediante una de las siguientes dos opciones:

Para quitar por completo el clúster de la flota, anula el registro de tu clúster.
Como alternativa, mantén el clúster en la flota, pero inhabilita la encriptación:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Reemplaza PROJECT_ID con el ID del proyecto.

La inhabilitación de la encriptación con este comando inicia la eliminación de nodos remotos de la lista de intercambios de tráfico de WireGuard en cada clúster. Este proceso puede tomar varios minutos en completarse, según la cantidad de clústeres y nodos involucrados. Para ver el recuento de intercambios de tráfico actualizado, deberás actualizar de forma manual la lista de intercambios de tráfico de WireGuard en cada clúster. Puedes usar tu herramienta de administración de clústeres o el siguiente comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Inhabilita la función para toda una flota de clústeres

Para inhabilitar la encriptación transparente entre nodos en una flota, haz lo siguiente:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Reemplaza PROJECT_ID con el ID del proyecto.
Para inhabilitar la encriptación transparente entre nodos y quitar la API que ahora no se usa, inhabilita la API de GKE Dataplane V2 a nivel de la flota. Esto desactivará el controlador de GKE Dataplane V2 que se ejecuta en tu flota.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Reemplaza PROJECT_ID con el ID del proyecto.

Nota: Esta API es responsable de la función de encriptación transparente entre nodos de tu flota. Asegúrate de verificar que ningún otro elemento de tu flota use esta API antes de inhabilitarla para evitar comportamientos inesperados.

Para administrar de manera eficiente los clústeres con el mismo nombre y garantizar la activación de la encriptación de varios clústeres, sigue estos pasos:
1. Anula el registro del clúster anterior en la flota antes de crear uno nuevo con el mismo nombre.
2. Vuelve a registrar el clúster nuevo cuando estés en el proceso de creación.
3. Si te olvidas de cancelar el registro de un clúster, borra la membresía anterior y vuelve a crear el clúster nuevo con una membresía nueva.
Si no sigues estos pasos, es posible que la encriptación de varios clústeres no se active en el clúster nuevo hasta que se vuelva a crear la membresía de la flota.

Cómo funciona la encriptación transparente entre nodos con GKE

En las siguientes secciones, se describe cómo funciona la encriptación transparente entre nodos cuando la habilitas en tu clúster:

Encriptación del tráfico de red entre dos Pods en nodos diferentes

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

Los clústeres con diferentes opciones de configuración de encriptación 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 la encriptación transparente entre nodos, se aplican las siguientes consideraciones:

La comunicación de Pod a Pod entre nodos del mismo clúster se encripta con el par de claves públicas/privadas.
La comunicación de pod a pod entre un nodo de un clúster que tiene habilitada la encriptación transparente entre nodos y un nodo de un clúster que no tiene habilitada la encriptación transparente entre nodos falla.

Generación y uso de claves de encriptación

Cuando la función está habilitada, cada nodo de GKE en el clúster genera de forma automática un par de claves públicas/privadas conocidas como claves de encriptación.

La clave privada se almacena en la memoria (no en el disco) y nunca sale del nodo. El uso de GKE Confidential Nodes disminuye aún más el riesgo de que las claves se vean comprometidas porque la memoria del nodo también está encriptada (con claves diferentes).
La clave pública se comparte con otros nodos a través del plano de control de GKE Dataplane V2, y todos los nodos del mismo dominio de encriptación pueden acceder a ella.

Después de intercambiar las claves, cada nodo puede establecer un túnel WireGuard con otros nodos en el mismo dominio de encriptación. Cada túnel es único para un par de nodos determinado.

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

Par de claves pública y privada:
- 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 regulares. Para activar una rotación de claves de forma manual, desvía y reinicia el nodo. Esto invalida el par de claves original y genera uno nuevo.
Clave de la 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 involucrados en el túnel.