Descripción general de la seguridad

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

Los clústeres de GKE ofrecen funciones que te ayudan a proteger tus cargas de trabajo, incluido el contenido de tu imagen de contenedor, el tiempo de ejecución del contenedor, la red del clúster y el acceso al servidor de la API del clúster.

Cuando usas clústeres de GKE, aceptas asumir ciertas responsabilidades por 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 es el cifrado de 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 con claves gestionadas por la plataforma Azure.

Los clústeres de GKE en Azure almacenan datos en volúmenes de discos de Azure. Estos volúmenes siempre están cifrados en reposo mediante claves de Azure Key Vault. Cuando creas clústeres y grupos de nodos, puedes proporcionar una clave de Key Vault gestionada por el cliente para cifrar los volúmenes de disco subyacentes del clúster. Si no especificas ninguna clave, Azure usará la clave predeterminada gestionada por Azure en la región de Azure en la que se ejecute el clúster.

Además, todos los clústeres de GKE habilitan el encriptado de secretos en la capa de aplicación para los datos sensibles, como los objetos Secret de Kubernetes, que se almacenan en etcd. Aunque los atacantes consigan acceder al volumen subyacente donde se almacenan los datos de etcd, estos datos estarán cifrados.

Cuando creas un clúster, puedes proporcionar una clave de Azure Key Vault en el parámetro --database-encryption-kms-key-arn. Esta clave se usa para cifrar los datos de tu aplicación. Si no proporcionas una clave durante la creación del clúster, GKE en Azure creará una automáticamente para tu clúster. Este campo de recurso es inmutable y no se puede modificar una vez creado el clúster.

También puedes crear manualmente una clave de Key Vault o incorporar tu propia clave (BYOK) con un módulo de seguridad de hardware (HSM). Para obtener más información, consulta Traer tu propia clave.

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

Kubernetes ofrece cifrado a nivel de aplicación con una técnica conocida como cifrado envolvente. Una clave local, que se suele denominar clave de cifrado de datos (DEK), se usa para cifrar un secreto. La DEK se cifra con una segunda clave llamada clave de cifrado de claves (KEK). Kubernetes no almacena la KEK. Cuando creas un nuevo secreto de Kubernetes, tu clúster hace 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 cifra el Secret de forma local con la DEK.

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

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

  5. El servidor de la API de Kubernetes guarda el secreto cifrado y la DEK cifrada en etcd. La DEK sin cifrar no se guarda en el disco.

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

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

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

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

  3. Si no hay ninguna entrada de caché coincidente, el servidor de la API envía la DEK a Azure Key Vault para descifrarla con la KEK. A continuación, se usa la DEK desencriptada para desencriptar el secreto.

  4. Por último, el servidor de la API de Kubernetes devuelve el secreto descifrado al cliente.

Configurar el cifrado con el cortafuegos de Key Vault

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

Para proteger aún más tu instancia de Azure Key Vault, puedes habilitar el firewall de Azure Key Vault. GKE en Azure puede usar una clave pública para el cifrado y evitar el acceso a la red del almacén de claves.

Para configurar el cortafuegos, descarga la clave de Key Vault con la CLI de Azure. Cuando creas un clúster con la CLI de Google Cloud, debes pasar la clave a --config-encryption-public-key.

Aún tienes que habilitar los endpoints de servicio de Key Vault en todas las subredes que se usen en tu clúster. Para obtener más información, consulta Endpoints 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 es el proceso de cambiar el material criptográfico subyacente contenido en una clave de cifrado de claves (KEK). Se puede activar automáticamente como parte de una rotación programada o manualmente, normalmente después de un incidente de seguridad en el que las claves se hayan podido ver comprometidas. La rotación de claves solo sustituye el campo de la clave que contiene los datos de la clave de cifrado o descifrado sin procesar.

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

Confianza de los clústeres

Todas las comunicaciones del clúster utilizan Seguridad en la capa de transporte (TLS). Cada clúster se aprovisiona con las siguientes autoridades de certificación (CAs) raíz autofirmadas principales:

  • La CA raíz del clúster se usa para validar las solicitudes enviadas al servidor de la API.
  • La autoridad de certificación raíz de etcd se usa para validar las solicitudes enviadas a las réplicas de etcd.

Cada clúster tiene una CA raíz única. Si se vulnera la CA de un clúster, no se verá afectada la CA de ningún otro clúster. Todas las autoridades de certificación raíz tienen un periodo de validez de 30 años.

Seguridad de los nodos

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

Ubuntu

Tus 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, consulta las funciones de seguridad en la documentación de Ubuntu.

Los clústeres de GKE implementan varias funciones de seguridad, entre las que se incluyen las siguientes:

  • Paquete optimizado

  • Google Cloud-kernel de Linux personalizado

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

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

Protege tus cargas de trabajo

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

Limitar los privilegios de proceso de los contenedores de pods

Limitar los privilegios de los procesos en contenedores es importante para la seguridad de tu clúster. Puedes definir opciones relacionadas con la seguridad con un contexto de seguridad. Estos ajustes te permiten cambiar la configuración de seguridad de tus procesos, como los siguientes:

  • Usuario y grupo que ejecutan el proceso
  • Funciones de Linux disponibles
  • Apropiación de privilegios

El sistema operativo de nodo predeterminado de GKE en Azure, Ubuntu, usa políticas de seguridad de Docker AppArmor predeterminadas para todos los contenedores. Puedes 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 de /proc/sys que no sean /proc/sys/kernel/shm*
  • Montar sistemas de archivos

Restringir la capacidad de las cargas de trabajo para modificarse a sí mismas

Algunas cargas de trabajo de Kubernetes, especialmente las del sistema, tienen permiso para modificarse a sí mismas. Por ejemplo, algunas cargas de trabajo se escalan verticalmente de forma automática. Aunque es una opción cómoda, puede permitir que un atacante que ya haya vulnerado un nodo siga escalando en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo de un nodo se ejecute como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Lo ideal es que no se conceda a las cargas de trabajo el permiso para modificarse a sí mismas. Cuando sea necesario modificar el clúster, puedes limitar los permisos instalando Policy Controller o Gatekeeper en tu clúster y aplicando restricciones, como NoUpdateServiceAccount de la biblioteca de código abierto de Gatekeeper, que proporciona varias políticas de seguridad útiles.

Cuando implementas políticas, suele ser necesario permitir que los controladores que gestionan el ciclo de vida del clúster omitan las políticas. Esto es necesario para que los controladores puedan hacer cambios en el clúster, como aplicar actualizaciones del clúster. Por ejemplo, si implementas la política NoUpdateServiceAccount en GKE en Azure, debes definir los siguientes parámetros en Constraint:

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

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

Aísla cargas de trabajo en grupos de nodos dedicados

Puedes usar las intolerancias y las tolerancias de Kubernetes para designar grupos de nodos específicos para ejecutar tipos de cargas de trabajo concretos. Por ejemplo, puedes indicar a GKE en Azure que programe las cargas de trabajo de los usuarios lejos de la mayoría de las cargas de trabajo gestionadas por el sistema o que coloque cargas de trabajo con diferentes niveles de confianza en diferentes grupos de nodos.

El aislamiento de cargas de trabajo mediante taints y tolerancias no es una medida de seguridad garantizada. Úsalo junto con las demás medidas de protección que ofrece GKE en Azure.

Para obtener más información, consulta Aísla cargas de trabajo en grupos de nodos dedicados.

Siguientes pasos