Información general sobre seguridad

En esta página se describe la arquitectura de seguridad de GKE en AWS, incluidos 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 AWS KMS

GKE on AWS usa claves simétricas de AWS Key Management Service (KMS) gestionadas por el cliente para encriptar lo siguiente:

  • Datos de estado de Kubernetes en etcd
  • Datos de usuario de la instancia EC2
  • Volúmenes de EBS para el cifrado en reposo de los datos del plano de control y del grupo de nodos

En los entornos de producción, recomendamos usar claves diferentes para la configuración y el cifrado de volúmenes. Para minimizar aún más los riesgos si se vulnera una clave, también puedes crear claves diferentes para cada uno de los siguientes elementos:

Para aumentar la seguridad, puede crear una política de claves de KMS de AWS que asigne solo el conjunto mínimo de permisos necesarios. Para obtener más información, consulta Crear claves de KMS con permisos específicos.

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 on AWS cifra los datos en reposo de etcd y los volúmenes de almacenamiento con claves gestionadas por la plataforma de AWS.

Los clústeres de GKE on AWS almacenan datos en volúmenes de AWS Elastic Block Storage (EBS). Estos volúmenes de EBS siempre están cifrados en reposo con claves de AWS Key Management System (AWS KMS). Cuando creas clústeres y grupos de nodos, puedes proporcionar una clave de KMS gestionada por el cliente (CMK) para cifrar los volúmenes de EBS subyacentes. Si no especifica ninguna clave, AWS usará la clave predeterminada gestionada por AWS en la región de AWS 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, debes pasar una clave de KMS de AWS al campo --database-encryption-kms-key-arn. Esta clave se usa para el cifrado envolvente de los datos de la aplicación. Como este campo de recurso es inmutable y no se puede modificar una vez creado el clúster, te recomendamos que uses un alias de clave de KMS. Puedes usar alias de clave para rotar las claves que se usan para el cifrado en reposo durante todo el ciclo de vida del clúster.

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 AWS KMS para cifrarla.

  4. AWS KMS usa una KEK pregenerada para cifrar la DEK y devuelve la DEK cifrada al complemento de AWS KMS 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. De esta forma, el servidor de la API puede descifrar los secretos a los que se ha accedido recientemente sin consultar AWS KMS.

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 AWS KMS para que la desencripte 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.

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.

Rotación de claves de KMS

AWS KMS admite la rotación automática de claves de KMS. Si está habilitada, AWS genera automáticamente material de clave criptográfica nuevo para tu clave una vez al año. No es necesario realizar ninguna acción manual.

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 AWS implementa tus cargas de trabajo en grupos de nodos de instancias de EC2 de AWS. 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 AWS, 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 AWS, 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.

Usar autorización binaria

Otra forma de proteger tus cargas de trabajo es habilitar la autorización binaria. La autorización binaria es una función de seguridad que garantiza que solo se desplieguen imágenes de contenedor de confianza en los clústeres de GKE.

El proceso es el siguiente:

  1. Los administradores crean una política que define los requisitos para implementar una imagen. Esto incluye especificar las entidades de confianza y autorizadas (los certificadores) que pueden firmar imágenes, y puede incluir otros criterios que debe cumplir una imagen para considerarse segura para la implementación.

  2. Un verificador (por ejemplo, un desarrollador o un sistema automatizado) usa un algoritmo criptográfico para generar un par de claves (claves privada y pública).

  3. La clave privada, que se mantiene en secreto, se usa para generar una firma digital (es decir, un conjunto único de caracteres) de una imagen. Esta firma actúa como sello de aprobación: es una señal de que la imagen ha superado todas las comprobaciones y validaciones necesarias.

  4. A continuación, la firma digital se "adjunta" a la imagen. Es decir, la firma se almacena en los metadatos de la imagen, normalmente en el registro de imágenes.

  5. La clave pública se registra en el sistema de autorización binaria para que este pueda usarla en la verificación de firmas.

  6. Cuando se hace una solicitud para desplegar un contenedor, el sistema de autorización binaria recupera la firma digital adjunta a la imagen en el registro.

  7. El sistema de autorización binaria usa la clave pública registrada para verificar la firma digital adjunta a la imagen. También comprueba si la imagen cumple todos los demás criterios definidos en la política. Si la firma digital se puede verificar correctamente con la clave pública y los datos de la imagen, y la imagen cumple todos los demás criterios definidos en la política, el sistema de autorización binaria permite que se implemente el contenedor. Si no se puede verificar correctamente la firma digital con la clave pública y los datos de la imagen, o si la imagen no cumple otros criterios definidos en la política, el sistema de Autorización Binaria deniega la implementación del contenedor.

Para obtener más información sobre cómo funciona la autorización binaria, consulta la descripción general de la autorización binaria.

Para habilitar la autorización binaria en un clúster o al crear uno, consulta el artículo Cómo habilitar la autorización binaria.

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 AWS 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 las 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. Utiliza esta opción junto con otras medidas de protección que ofrece GKE en AWS.

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

Siguientes pasos