Descripción general de seguridad

Esta página describe la arquitectura de seguridad de GKE en Azure, incluido el cifrado y la configuración de nodos.

Los clústeres de GKE ofrecen funciones para ayudar a proteger sus cargas de trabajo, incluido el contenido de la imagen de su contenedor, el tiempo de ejecución del contenedor, la red del clúster y el acceso al servidor de API del clúster.

Al usar clústeres de GKE, aceptas asumir ciertas responsabilidades sobre tus clústeres. Para obtener más información, consulta Responsabilidades compartidas de los clústeres de GKE .

Cifrado de datos en reposo

El cifrado de datos en reposo consiste en cifrar los datos almacenados, a diferencia de los datos en tránsito. De forma predeterminada, GKE en Azure cifra los datos en etcd y los volúmenes de almacenamiento en reposo mediante claves administradas por la plataforma de Azure.

Los clústeres de GKE en Azure almacenan datos en volúmenes de disco de Azure. Estos volúmenes siempre se cifran en reposo mediante claves de Azure Key Vault. Al crear clústeres y grupos de nodos, puede proporcionar una clave de Key Vault administrada por el cliente para cifrar los volúmenes de disco subyacentes del clúster. Si no especifica una clave, Azure usa la clave administrada predeterminada de Azure dentro de la región de Azure donde se ejecuta el clúster.

Además, todos los clústeres de GKE habilitan el cifrado de secretos de la capa de aplicación para datos confidenciales, como los objetos secretos de Kubernetes, que se almacenan en etcd . Incluso si los atacantes obtienen acceso al volumen subyacente donde se almacenan los datos de etcd, estos se cifran.

También puede crear manualmente una clave de Key Vault o traer su propia clave (BYOK) con un módulo de seguridad de hardware (HSM). Para más información, consulte Traer su propia clave .

Cómo funciona el cifrado a nivel de aplicación

Kubernetes ofrece cifrado a nivel de aplicación mediante una técnica conocida como cifrado de sobre . Se utiliza una clave local, comúnmente llamada clave de cifrado de datos (DEK) , para cifrar un secreto. La DEK se cifra con una segunda clave, llamada clave de cifrado de claves (KEK) . Kubernetes no almacena la KEK. Al crear un nuevo secreto de Kubernetes, el clúster realiza lo siguiente:

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

2. El servidor de API de Kubernetes cifra el secreto localmente con la DEK.

3. El servidor de API de Kubernetes envía la DEK a Azure Key Vault para su cifrado.

4. Azure Key Vault usa una KEK generada previamente para cifrar la DEK y devuelve la DEK cifrada al complemento de Azure Key Vault del servidor de API de Kubernetes.

5. El servidor de la API de Kubernetes guarda el secreto y la DEK cifrados en etcd. La DEK en texto plano no se guarda en el disco.

6. El servidor de API de Kubernetes crea una entrada de caché en memoria para asignar la DEK cifrada a la DEK de texto sin formato. Esto permite al servidor de API descifrar los secretos a los que se ha accedido recientemente sin consultar Azure Key Vault.

Cuando un cliente solicita un secreto del servidor de API de Kubernetes, esto es lo que sucede:

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

2. El servidor de API de Kubernetes verifica el caché en busca de una entrada de mapa existente y, si la encuentra, descifra el secreto con ella.

3. Si no hay ninguna entrada de caché coincidente, el servidor API envía la DEK a Azure Key Vault para su descifrado mediante la KEK. La DEK descifrada se utiliza para descifrar el secreto.

4. Finalmente, el servidor API de Kubernetes devuelve el secreto descifrado al cliente.

Cifrado de configuración con Key Vault Firewall

Si se pasa una clave pública para el cifrado, la entidad de servicio no necesita permiso para cifrar, pero sí para administrar las asignaciones de roles. La forma más sencilla de hacerlo es asignar el rol integrado User Access Administrator de Azure a la entidad de servicio.

Para proteger aún más su almacén de claves de Azure, puede habilitar el firewall de Azure Key Vault . De esta forma, GKE en Azure puede usar una clave pública para el cifrado y evitar el acceso de red al almacén de claves.

Para configurar el firewall, descargue la clave de Key Vault con la CLI de Azure . Transfiera la clave a --config-encryption-public-key al crear un clúster con la CLI de Google Cloud.

Aún debe habilitar los puntos de conexión de servicio para Key Vault en todas las subredes utilizadas para el clúster. Para obtener más información, consulte Puntos de conexión de servicio de red virtual para Azure Key Vault .

Rotación de claves

A diferencia de la rotación de certificados, la rotación de claves consiste en modificar el material criptográfico subyacente contenido en una clave de cifrado (KEK) . Puede activarse automáticamente como parte de una rotación programada o manualmente, generalmente tras un incidente de seguridad en el que las claves podrían haberse visto comprometidas. La rotación de claves reemplaza únicamente el campo de la clave que contiene los datos sin procesar de la clave de cifrado/descifrado.

Para obtener más información, consulte Rotación de claves .

confianza del clúster

Toda la comunicación del clúster utiliza Seguridad de la Capa de Transporte (TLS). Cada clúster cuenta con las siguientes autoridades de certificación raíz (CA) autofirmadas principales:

• La CA raíz del clúster se utiliza para validar las solicitudes enviadas al servidor API.
• La CA raíz de etcd se utiliza para validar las solicitudes enviadas a las réplicas de etcd.

Cada clúster tiene una CA raíz única. Si la CA de un clúster se ve comprometida, ninguna de las demás se verá afectada. Todas las CA raíz tienen un periodo de validez de 30 años.

Seguridad del nodo

GKE en Azure implementa sus cargas de trabajo en grupos de nodos de instancias de máquinas virtuales de Azure. En la siguiente sección se explican las características de seguridad de los nodos.

Ubuntu

Sus nodos ejecutan una versión optimizada del sistema operativo Ubuntu para ejecutar el plano de control y los nodos de Kubernetes. Para obtener más información, consulte las características de seguridad en la documentación de Ubuntu.

Los clústeres de GKE implementan varias funciones de seguridad, incluidas las siguientes:

• Conjunto de paquetes optimizado

• Google Cloud-núcleo Linux personalizado

• Cuentas de usuario limitadas e inicio de sesión root deshabilitado

Hay guías de seguridad adicionales disponibles para Ubuntu, como las siguientes:

• Punto de referencia del CIS

• DISA STIG

• FIPS 140-2

Asegure sus cargas de trabajo

Kubernetes permite a los usuarios aprovisionar, escalar y actualizar rápidamente cargas de trabajo basadas en contenedores. Esta sección describe las tácticas que puede usar para limitar los efectos secundarios de ejecutar contenedores en clústeres y... Google Cloud servicios.

Limitar los privilegios del proceso del contenedor Pod

Limitar los privilegios de los procesos contenedorizados es importante para la seguridad del clúster. Puede configurar opciones de seguridad con un contexto de seguridad . Estas configuraciones le permiten cambiar la configuración de seguridad de sus procesos, como las siguientes:

• Usuario y grupo que ejecutan el proceso
• Capacidades de Linux disponibles
• escalada de privilegios

El sistema operativo predeterminado de GKE en el nodo de Azure, Ubuntu, utiliza las políticas de seguridad predeterminadas de Docker AppArmor para todos los contenedores. Puede ver la plantilla del perfil en GitHub . Entre otras cosas, este perfil deniega a los contenedores las siguientes funciones:

• Escribir en archivos directamente en un directorio de ID de proceso ( /proc/ )
• Escribir en archivos que no están en /proc/
• Escribir en archivos en /proc/sys distintos de /proc/sys/kernel/shm*
• Montaje de sistemas de archivos

Restringir la capacidad de las cargas de trabajo para automodificarse

Ciertas cargas de trabajo de Kubernetes, especialmente las del sistema, tienen permiso para automodificarse. Por ejemplo, algunas cargas de trabajo se escalan automáticamente verticalmente. Si bien esto resulta conveniente, puede permitir que un atacante que ya haya comprometido un nodo escale aún más en el clúster. Por ejemplo, un atacante podría modificar una carga de trabajo en el nodo para ejecutarse como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Idealmente, no se debería conceder a las cargas de trabajo el permiso para automodificarse. Cuando sea necesario, puede limitar los permisos instalando Policy Controller o Gatekeeper en su clúster y aplicando restricciones, como NoUpdateServiceAccount de la biblioteca de código abierto Gatekeeper, que proporciona varias políticas de seguridad útiles.

Al implementar directivas, suele ser necesario permitir que los controladores que administran el ciclo de vida del clúster las omitan. Esto es necesario para que los controladores puedan realizar cambios en el clúster, como aplicar actualizaciones. Por ejemplo, si implementa la directiva NoUpdateServiceAccount en GKE en Azure, debe configurar los siguientes parámetros en la Constraint :

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Reemplace PROJECT_NUMBER con el número (no ID) del proyecto que aloja el clúster.

Aislar cargas de trabajo en grupos de nodos dedicados

Puede usar las tolerancias y los valores de contaminación de Kubernetes para designar grupos de nodos específicos que ejecuten tipos específicos de cargas de trabajo. Por ejemplo, puede indicar a GKE en Azure que programe las cargas de trabajo de los usuarios fuera de la mayoría de las cargas de trabajo administradas por el sistema, o que coloque cargas de trabajo con diferentes niveles de confianza en distintos grupos de nodos.

El aislamiento de cargas de trabajo mediante tolerancias y contaminaciones no garantiza la seguridad. Úselo únicamente junto con las demás medidas de refuerzo que ofrece GKE en Azure.

Para obtener más información, consulte Aislar cargas de trabajo en grupos de nodos dedicados .

¿Qué sigue?

• Obtenga más información sobre la rotación de claves .