Descripción general de seguridad

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

GKE en AWS usa claves simétricas del servicio de administración de claves (KMS) de AWS para encriptar lo siguiente:

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

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

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 AWS encripta datos en etcd y volúmenes de almacenamiento en reposo mediante claves administradas en 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 se encriptan en reposo con claves del sistema de administración de claves de AWS (AWS KMS). Cuando creas clústeres y grupos de nodos, puedes proporcionar una clave de KMS administrada por el cliente (CMK) para encriptar los volúmenes de EBS subyacentes. Si no especificas una clave, AWS usa la clave predeterminada administrada por AWS dentro de la región de AWS en la que se ejecuta el clúster.

Además, todos los clústeres de GKE habilitan lo siguiente:Encriptación de Secrets de la capa de 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, debes pasar una clave de AWS KMS al campo --database-encryption-kms-key-arn. Esta clave se usa para la encriptación de sobre de los datos de la aplicación. Debido a que este campo de recursos es inmutable y no se puede modificar una vez que se crea el clúster, te sugerimos que uses un alias de clave KMS. Puedes usar un alias de clave para rotar las claves que se usan en la encriptación en reposo durante todo el ciclo de vida del clúster.

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 AWS KMS para realizar la encriptación.

  4. AWS KMS usa una KEK generada con anterioridad para encriptar la DEK y la muestra al complemento de AWS API 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 Secrets a los que se accedió recientemente sin consultar el KMS de AWS.

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 AWS KMS para su desencriptación con la 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.

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.

Rotación de claves de KMS

AWS KMS admite la rotación automática de claves de KMS. Cuando se habilita, AWS genera de forma automática material nuevo de clave criptográfica para tu clave una vez al año. No debes realizar acciones manuales.

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 AWS implementa tus cargas de trabajo en grupos de nodos de instancias de AWS EC2. 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 de nodos predeterminado de GKE on AWS, Ubuntu, usa políticas de seguridad de AppArmor de Docker 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 personalizada es necesaria, puedes limitar los permisos si instalas el Policy Controller o Gatekeeper en tu clúster y aplicar 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, debes permitir que los controladores que administran el ciclo de vida del clúster eviten las políticas. Esto es necesario para que los controladores puedan realizar cambios en el clúster, como aplicar actualizaciones. Por ejemplo, si implementas la política NoUpdateServiceAccount en GKE en AWS, 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.

Usa la 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 implementen imágenes de contenedor confiables en los clústeres de GKE.

Aquí te mostramos cómo funciona:

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

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

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

  4. Luego, la firma digital se “adjunta” a la imagen. En otras palabras, la firma se almacena en los metadatos de la imagen, por lo general, en el registro de imágenes.

  5. Luego, la clave pública se registra con el sistema de Autorización Binaria para que el sistema pueda usarla para verificar 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 usa 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 mediante 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 que el contenedor se implemente. 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, consulta Descripción general de la autorización binaria.

Para habilitar Autorización Binaria en un clúster existente o cuando creas un clúster, consulta Cómo habilitar la Autorización Binaria.

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 a fin de ejecutar tipos específicos de cargas de trabajo. Por ejemplo, puedes indicarle a GKE en AWS 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 diferentes grupos de nodos.

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

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

¿Qué sigue?