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 el tráfico de Pods. Google proporciona y administra las claves de encriptación.

Con la encriptación transparente entre nodos para GKE, Google te brinda más control sobre las claves de encriptación que se usan a fin de encriptar el tráfico de Pods en los nodos de GKE. GKE realiza esta encriptación mediante WireGuard en GKE Dataplane V2, además de la encriptación predeterminada que proporcionan las NIC de VM.

Proporcionar este control sobre las claves de encriptación directamente en GKE es útil si te encuentras en una industria regulada y necesitas empresas para el cumplimiento y las auditorías de seguridad.

Puedes habilitar la encriptación transparente entre nodos en entornos de uno o 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 los requisitos de cumplimiento específicos, es posible que desees 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 las 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 para 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 se debe controlar 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 mediante 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 que se reenvía desde el primer nodo que recibe tráfico del cliente al Pod de backend no se encripta.
La cantidad máxima de nodos compatibles con la encriptación transparente entre nodos habilitada para configuraciones de un solo clúster o de varios clústeres es de 500.
La encriptación transparente entre nodos puede provocar que los nodos se suscriban en exceso. Puedes esperar un aumento promedio del 15% de la CPU en los nodos n2-standard-8 con el SO Ubuntu con 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 conoce. El pod con mayor tráfico puede 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 a los Pods que intentan ejecutar cargas de trabajo sensibles o que necesitan responder con rapidez a las solicitudes. 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 que 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 Pods, 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 capa 7 de GKE Dataplane V2. Como resultado, no puedes habilitar la política de red FQDN y 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 Kubernetes Engine de Google.

Habilitar la API de Kubernetes Engine de Google

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 versiones posteriores de Google Cloud CLI, y con 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 clúster único o en un entorno de varios clústeres.

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 la configuración, usa el siguiente comando a fin de 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)]
```
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 intercambios de tráfico debe ser 23. Si la cantidad de intercambios de tráfico no es uno menos que la cantidad de nodos del clúster, reinicia el agente anetd en tus nodos de nuevo.

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, haz lo siguiente:
```
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: 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 se habilita la encriptación entre nodos en GKE, se reiniciarán automáticamente los nodos. Es posible que el reinicio del nodo tarde varias horas en ocurrir y que los nuevos nodos 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 nodos nuevos.
Para verificar la configuración, puedes usar el siguiente comando a fin de 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 del clúster, reinicia el agente anetd en tus nodos nuevamente.

Habilita la encriptación transparente entre nodos en 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 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, sigue estos pasos:

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: Verifica 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, 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 del clúster, reinicia el agente anetd en tus nodos nuevamente.

Inhabilita la encriptación transparente entre nodos

En algunos casos, puede que quieras 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, considera 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 operación interrumpirá el tráfico del Pod.

En un solo clúster

Para inhabilitar la encriptación transparente entre nodos en un solo clúster, sigue estos pasos:

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 del clúster.

Inhabilita en un clúster que sea parte de una flota

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

Para quitar por completo el clúster de la flota, anula el registro de tu clúster.
Como alternativa, puedes mantener el clúster en la flota, pero inhabilitar 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 la herramienta de administración de clústeres o el siguiente comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Inhabilita para una flota completa de clústeres

Para inhabilitar la encriptación transparente entre nodos en una flota, sigue estos pasos:
```
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 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 ninguna otra API 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. Cancela el registro del clúster anterior de la flota antes de crear uno nuevo con el mismo nombre.
2. Vuelve a registrar el clúster nuevo durante su recreació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 se siguen 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 nodos diferentes, sin importar el 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 mediante el plano de control de GKE Dataplane V2 y es accesible para todos los nodos del mismo dominio de encriptación.

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 trabajes con los pares de claves públicas o privadas y la clave de sesión:

Par de claves públicas/privadas:
- La clave pública se distribuye en el clúster y todos los nodos del clúster pueden acceder a la clave pública.
- El par de claves se rota cuando se reinicia el nodo. GKE no rota las claves en 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 de forma periódica cada dos minutos.
- La clave de sesión es exclusiva de los nodos involucrados en el túnel.