Descripción general de seguridad

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

GKE en AWS utiliza claves simétricas del Servicio de administración de claves de AWS (KMS) administradas por el cliente para cifrar:

En 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 una clave se ve comprometida, también puede crear claves diferentes para cada uno de los siguientes elementos:

Para mayor seguridad, puede crear una política de claves de AWS KMS que asigne únicamente el conjunto mínimo de permisos requerido. Para obtener más información, consulte Creación de claves KMS con permisos específicos .

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

Los clústeres de GKE en AWS almacenan datos en volúmenes de AWS Elastic Block Storage (EBS). Estos volúmenes EBS siempre se cifran en reposo con claves del Sistema de administración de claves de AWS (AWS KMS). Al crear clústeres y grupos de nodos, puede proporcionar una clave KMS administrada por el cliente (CMK) para cifrar los volúmenes EBS subyacentes. Si no especifica una clave, AWS utiliza la clave administrada por AWS predeterminada dentro de la región de AWS 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.

Al crear un clúster, debe pasar una clave de AWS KMS al campo --database-encryption-kms-key-arn . Esta clave se utiliza para el cifrado de sobre de los datos de la aplicación. Dado que este campo de recurso es inmutable y no se puede modificar una vez creado el clúster, le recomendamos usar un alias de clave de KMS . Puede usar un alias de clave para rotar las claves utilizadas para el cifrado en reposo a lo largo del ciclo de vida del clúster.

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

  4. AWS KMS utiliza una KEK generada previamente para cifrar la DEK y devuelve la DEK cifrada al complemento AWS KMS 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 AWS KMS.

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

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.

Rotación de claves KMS

AWS KMS admite la rotación automática de claves KMS . Cuando está habilitado, AWS genera automáticamente nuevo material de claves criptográficas para su clave una vez al año. No se requieren acciones manuales.

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 AWS implementa sus cargas de trabajo en grupos de nodos de instancias de AWS EC2. La siguiente sección explica 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:

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

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 nodos de AWS, Ubuntu, utiliza las políticas de seguridad predeterminadas de Docker AppArmor para todos los contenedores. Puede consultar 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 políticas, 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 política NoUpdateServiceAccount en GKE en AWS, 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.

Utilizar autorización binaria

Otra forma de proteger sus cargas de trabajo es habilitar la Autorización Binaria. Esta función de seguridad garantiza que solo se implementen imágenes de contenedor confiables en los clústeres de GKE.

Así es como funciona el proceso:

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

  2. Un certificador (por ejemplo, un desarrollador o un sistema automatizado) utiliza un algoritmo criptográfico para generar un par de claves (claves privadas y públicas).

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

  4. La firma digital se adjunta a la imagen. En otras palabras, se almacena en los metadatos de la imagen, generalmente en el registro de imágenes.

  5. Luego, la clave pública se registra en el sistema de autorización binaria para que el sistema pueda utilizarla para la verificación de la firma.

  6. Cuando se realiza una solicitud para implementar 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 utiliza la clave pública registrada para verificar la firma digital adjunta a la imagen. También verifica si la imagen cumple con 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 con todos los demás criterios definidos en la política, el sistema de Autorización Binaria permite la implementación del contenedor. Si la firma digital no se puede verificar correctamente con la clave pública y los datos de la imagen, o si la imagen no cumple con 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, consulte Descripción general de la autorización binaria .

Para habilitar la autorización binaria en un clúster existente o al crear un clúster, consulte Cómo habilitar la autorización binaria .

Aislar cargas de trabajo en grupos de nodos dedicados

Puedes usar las tolerancias y los controles de Kubernetes para designar grupos de nodos específicos que ejecuten tipos específicos de cargas de trabajo. Por ejemplo, puedes indicar a GKE en AWS 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 la carga de trabajo mediante taints y tolerancias no es una medida de seguridad garantizada. Úselo únicamente junto con las demás medidas de refuerzo que ofrece GKE en AWS.

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

¿Qué sigue?