Descripción general de seguridad

En esta página, se describe la arquitectura de seguridad de GKE en Azure, incluida la encriptación y la configuración de nodos.

Los clústeres de GKE ofrecen varias funciones para ayudar a proteger las cargas de trabajo, incluido el contenido de la imagen de contenedor, el entorno 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 en tus clústeres. Para obtener más información, consulta Responsabilidades compartidas de los clústeres de GKE.

Encriptación de datos en reposo

La encriptación de datos en reposo es la encriptación de los datos almacenados, a diferencia de los datos en tránsito. De forma predeterminada, GKE en Azure encripta datos en etcd y volúmenes de almacenamiento en reposo a través de claves administradas en la plataforma de Azure.

Los clústeres de GKE en Azure almacenan datos en volúmenes de Azure Disk. Estos volúmenes siempre se encriptan en reposo mediante claves de Azure Key Vault. Cuando creas clústeres y grupos de nodos, puedes proporcionar una clave de Keyvault administrada por el cliente para encriptar los volúmenes de discos subyacentes del clúster. Si no especificas una clave, Azure usa la clave predeterminada administrada por Azure dentro de la región de Azure en la que se ejecuta el clúster.

Además, todos los clústeres de GKE habilitan la encriptación de Secrets de la capa de la aplicación para datos sensibles, como objetos Secret de Kubernetes que se almacenan en etcd. Incluso si los atacantes obtienen acceso al volumen subyacente en el que se almacenan los datos de etcd, estos se encriptan.

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 la encriptación de los datos de tu aplicación. Si no proporcionas una clave durante la creación del clúster, GKE en Azure crea uno para tu clúster automáticamente. Este campo de recursos es inmutable y no se puede modificar una vez que se crea el clúster.

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

Cómo funciona la encriptación a nivel de la aplicación

Kubernetes ofrece encriptación a nivel de la aplicación con una técnica conocida como encriptación de sobre. Una clave local, que se suele llamar clave de encriptación de datos (DEK), se usa para encriptar un objeto Secret. La DEK se encripta con una segunda clave llamada clave de encriptación de claves (KEK). Kubernetes no almacena la KEK. Cuando creas un nuevo Secret de Kubernetes, tu clúster hace lo siguiente:

  1. El servidor de la API de Kubernetes genera una DEK única para el secreto mediante el uso de un generador de números al azar.

  2. El servidor de la API de Kubernetes encripta 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 su encriptación.

  4. Azure Key Vault usa una KEK generada con anterioridad para encriptar la DEK y muestra la DEK encriptada al complemento de Azure Key Vault del servidor de la API de Kubernetes.

  5. El servidor de la API de Kubernetes guarda el objeto Secret encriptado y la DEK encriptada en etcd. La DEK de texto simple no se guarda en el disco.

  6. El servidor de la API de Kubernetes crea una entrada de caché en la memoria para asignar la DEK encriptada a la DEK de texto simple. Esto permite que el servidor de la API desencripte los objetos Secret a los que se accedió recientemente sin consultar Azure Key Vault.

Cuando un cliente solicita un Secret del servidor de la API de Kubernetes, sucede lo siguiente:

  1. El servidor de la API de Kubernetes recupera el Secret encriptado y la DEK encriptada de etcd.

  2. El servidor de la API de Kubernetes verifica la caché para encontrar una entrada de mapa existente y, si la encuentra, desencripta el Secret con la entrada.

  3. Si no hay una entrada de caché que coincida, el servidor de la API envía la DEK a Azure Key Vault para su desencriptación con KEK. La DEK desencriptada luego se usa para desencriptar el Secret.

  4. Por último, el servidor de la API de Kubernetes muestra el Secret desencriptado al cliente.

Encriptación de configuración con firewall de Key Vault

Si pasas una clave pública para la encriptación, el principal del servicio no necesita el permiso para la encriptación, pero necesita el permiso para administrar las asignaciones de funciones. La manera más sencilla de hacerlo es asignar la función integrada User Access Administrator de Azure a la principal del servicio.

Para proteger aún más tu Azure Key Vault, puedes habilitar el firewall de Azure Key Vault. GKE en Azure puede usar una clave pública para la encriptación y evitar el acceso de red a la bóveda de clave.

Para configurar el firewall, descarga la clave de Key Vault con la CLI de Azure. Pasas la clave a --config-encryption-public-key cuando creas un clúster con Google Cloud CLI.

Aún debes habilitar los extremos de servicio para Key Vault en todas las subredes que se usan en tu clúster. Si deseas obtener más información, consulta Extremos del 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 cambio del material criptográfico subyacente contenido en una clave de encriptación de claves (KEK). Se puede activar de forma automática como parte de una rotación programada o de forma manual, por lo general, después de un incidente de seguridad en el que las claves se ven comprometidas. La rotación de claves reemplaza solo el campo único en la clave que contiene los datos de claves de encriptación y desencriptación sin procesar.

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

Confianza del clúster

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

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

Cada clúster tiene una CA raíz única. Si la CA de un clúster está comprometida, ninguna CA de otro clúster se ve afectada. Todas las CA raíz tienen un período de validez de 30 años.

Seguridad de nodos

GKE en Azure implementa tus cargas de trabajo en grupos de nodos de instancias de VM 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 SO Ubuntu para ejecutar el plano de control y los nodos de Kubernetes. Para obtener más información, consulta las características de seguridad en la documentación de Ubuntu.

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

Las guías de seguridad adicionales están disponibles para Ubuntu, como las que se mencionan a continuación:

Protege las cargas de trabajo

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

Limita los privilegios del proceso de contenedor del Pod

Limitar los privilegios de los procesos alojados en contenedores es importante para la seguridad del clúster. Puedes configurar opciones relacionadas con la seguridad con un contexto de seguridad. Esta configuración te permite cambiar la configuración de seguridad de los procesos:

  • Usuario y grupo que ejecuta el proceso
  • Funciones de Linux disponibles
  • Elevación de privilegios

El sistema operativo predeterminado del nodo de GKE en Azure, Ubuntu, usa las políticas de seguridad de Docker AppArmor predeterminadas para todos los contenedores. Puedes ver la plantilla del perfil en GitHub. Entre otros aspectos, este perfil les niega las siguientes capacidades a los contenedores:

  • 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*
  • Activar sistemas de archivos

Restringe la capacidad de las cargas de trabajo de realizar modificaciones automáticas

Algunas cargas de trabajo de Kubernetes, en especial las del sistema, tienen permiso para realizar modificaciones automáticas. Por ejemplo, algunas cargas de trabajo se escalan automáticamente. Si bien es conveniente, esto puede permitir que un atacante que ya haya vulnerado un nodo pueda escalar más a fondo en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo en el nodo se modifique a sí misma para ejecutarse como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Lo ideal es que, en primer lugar, no se les otorgue a las cargas de trabajo permiso para modificarse a sí mismas. Cuando la modificación automática es necesaria, puedes limitar los permisos si instalas Policy Controller o Gatekeeper en tu clúster y aplicas restricciones, como NoUpdateServiceAccount de la biblioteca de código abierto de Gatekeeper, que proporciona varias políticas de seguridad útiles.

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

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

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

Aísla las cargas de trabajo en grupos de nodos dedicados

Puedes usar taints y tolerancias de Kubernetes para designar grupos de nodos específicos para ejecutar tipos específicos de cargas de trabajo. Por ejemplo, puedes indicarle a GKE en Azure que programe las cargas de trabajo de los usuarios 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 grupos de nodos distintos.

El aislamiento de las cargas de trabajo a través de taints y tolerancias no es una medida de seguridad garantizada. Solo usa esto junto con las otras medidas de endurecimiento que ofrece GKE en Azure.

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

¿Qué sigue?