Prepara un clúster de GKE para usuarios de terceros

En este documento, se sugieren controles que puedes usar para configurar y proteger clústeres de Google Kubernetes Engine (GKE) que alojan aplicaciones personalizadas distribuidas por usuarios de terceros. Es parte de una solución de planos que consiste en lo siguiente:

  • Una guía de los controles que implementas (este documento).
  • Un repositorio de GitHub que contenga los siguientes directorios:
    • terraform: Contiene el código de Terraform que usas para crear la infraestructura y los recursos a nivel de proyecto. En este código, también se instalan componentes de Anthos en el clúster.
    • configsync: Contiene la configuración y los recursos a nivel de clúster que se aplican a tu clúster de GKE.
    • tenant-config-pkg: Un paquete kpt que puedes usar como plantilla para configurar usuarios nuevos en el clúster de GKE.

Este documento está dirigido a los equipos que administran clústeres de GKE. Se supone que estás familiarizado con GKE y Kubernetes.

En este documento, se supone que ya configuraste un conjunto básico de controles de seguridad para proteger la infraestructura de nube, como los controles que se describen en la guía de bases de seguridad de Google Cloud. El plano te ayuda a agregar controles adicionales a tus controles de seguridad existentes para proteger tus clústeres de GKE.

Arquitectura

En el siguiente diagrama, se describe la arquitectura que creas con este plano:

Componentes de la infraestructura del plano.

Como se muestra en el diagrama anterior, el plano te ayuda a crear y configurar los siguientes componentes de la infraestructura:

  • Una red de nube privada virtual (VPC) y una subred.
  • Un clúster de GKE privado. Los nodos del clúster están aislados de Internet.
  • Dos grupos de nodos de GKE. Crea un grupo de nodos dedicado para alojar exclusivamente los recursos y las apps de usuarios. Otros recursos de clúster se alojan en el grupo de nodos predeterminado.
  • Reglas de firewall de VPC. Crea reglas de referencia que se apliquen a todos los nodos del clúster. Crea reglas adicionales que se apliquen solo a los nodos del grupo de nodos de usuario. Estas reglas de firewall limitan la salida desde los nodos de usuario.
  • Cloud NAT para permitir la salida desde los nodos del clúster a Internet.
  • Las reglas de Cloud DNS configuradas para habilitar el Acceso privado a Google, de modo que las aplicaciones adentro del clúster puedan acceder a las API de Google sin atravesar Internet.
  • Las cuentas de servicio que usan los nodos y las apps del clúster.

Aplicaciones

En el siguiente diagrama, se muestran los recursos a nivel de clúster que creas y configuras con el plano.

Recursos a nivel de clúster.

Como se muestra en el diagrama anterior, en el plano, se usa lo siguiente para crear y configurar los recursos a nivel de clúster:

  • El Sincronizador de configuración de Anthos Config Management para sincronizar la configuración y las políticas del clúster desde un repositorio de Git.
  • El controlador de políticas de Anthos Config Management para aplicar políticas en los recursos del clúster.
  • Anthos Service Mesh para controlar y proteger el tráfico de red.
  • Un espacio de nombres dedicado para las aplicaciones y los recursos de usuarios.
  • Políticas y controles que se aplican al espacio de nombres del usuario, incluidas las políticas de red y las de malla de servicios.

Comprende los controles de seguridad que necesitas

En esta sección, se analizan los controles que aplicas con el plano para ayudarte a proteger tu clúster de GKE.

Seguridad mejorada de los clústeres de GKE

Crea clústeres de acuerdo con las prácticas recomendadas de seguridad.

El plano te ayuda a crear un clúster de GKE que implementa la siguiente configuración de seguridad:

Para obtener más información sobre la configuración de seguridad de GKE, consulta Endurece la seguridad de tu clúster.

Reglas de firewall de VPC

Restringe el tráfico entre máquinas virtuales

Las reglas de firewall de la nube privada virtual (VPC) determinan qué tráfico se permite o desde las VM de Compute Engine. Las reglas te permiten filtrar el tráfico con el nivel de detalle de la VM, según los atributos de la capa 4.

Debes crear un clúster de GKE con las reglas de firewall de clúster de GKE predeterminadas. Estas reglas de firewall permiten la comunicación entre los nodos del clúster y el plano de control de GKE, y entre los nodos y los Pods en el clúster.

Aplicas reglas de firewall adicionales a los nodos en el grupo de nodos de usuario. Estas reglas de firewall restringen el tráfico de salida de los nodos de usuario. Este enfoque te permite aumentar el aislamiento de los nodos de usuario. De forma predeterminada, se rechaza todo el tráfico de salida de los nodos de usuario. Cualquier salida necesaria debe configurarse de forma explícita. Por ejemplo, puedes usar el plano para crear reglas de firewall que permitan la salida de los nodos de usuario al plano de control de GKE y a las API de Google mediante el Acceso privado a Google. Las reglas de firewall se orientan a los nodos de usuario mediante la cuenta de servicio del grupo de nodos de usuario.

Espacios de nombres

Etiqueta recursos que deben usar las mismas políticas

Los espacios de nombres te permiten proporcionar un permiso para los recursos relacionados dentro de un clúster, por ejemplo, pods, servicios y controladores de replicación. Si usas espacios de nombres, puedes delegar la responsabilidad de administración de los recursos relacionados como una unidad. Por lo tanto, los espacios de nombres son una parte integral de la mayoría de los patrones de seguridad.

Los espacios de nombres son una función importante para el aislamiento del plano de control. Sin embargo, no proporcionan aislamiento de los nodos, del plano de datos ni de la red.

Un enfoque común es crear espacios de nombres para aplicaciones individuales. Por ejemplo, puedes crear el espacio de nombres myapp-frontend para el componente de IU de una aplicación.

El plano te ayuda a crear un espacio de nombres dedicado para alojar las apps de aprendizaje federado. El espacio de nombres y sus recursos se tratan como un usuario dentro de tu clúster. Aplicas políticas y controles al espacio de nombres para limitar el alcance de los recursos en el espacio de nombres.

Políticas de red

Aplica el flujo de tráfico de red dentro de los clústeres

Las políticas de red aplican los flujos de tráfico de red de capa 4 mediante el uso de reglas de firewall a nivel del pod. Las políticas de red tienen permisos en un espacio de nombres.

En el plano, aplicas políticas de red al espacio de nombres del usuario que aloja las apps de terceros. De forma predeterminada, la política de red rechaza todo el tráfico hacia y desde los Pods en el espacio de nombres. Cualquier tráfico necesario debe incluirse de forma explícita en la lista de entidades permitidas. Por ejemplo, las políticas de red en el plano permiten de forma explícita el tráfico a los servicios obligatorios del clúster, como el DNS interno del clúster y el plano de control de Anthos Service Mesh.

Sincronizador de configuración

Aplica parámetros de configuración a tus clústeres de GKE

El Sincronizador de configuración mantiene los clústeres de GKE sincronizados con las configuraciones almacenadas en un repositorio de Git. El repositorio de Git actúa como la única fuente de información para la configuración y las políticas de tu clúster. El Sincronizador de configuración es declarativo. Comprueba el estado del clúster de forma continua y aplica el estado declarado en el archivo de configuración para aplicar políticas, lo que ayuda a evitar el desvío de configuración.

Instalas el Sincronizador de configuración en tu clúster de GKE. Debes configurar el Sincronizador de configuración para sincronizar las políticas y la configuración del clúster desde el repositorio de GitHub asociado con el plano. Los recursos sincronizados incluyen los siguientes:

  • Configuración de Anthos Service Mesh a nivel de clúster
  • Políticas de seguridad a nivel del clúster
  • Configuración y política a nivel del espacio de nombres del usuario, incluidas las políticas de red, las cuentas de servicio, las reglas de RBAC y la configuración de Anthos Service Mesh

Policy Controller

Aplica el cumplimiento con políticas

El controlador de políticas de Anthos es un controlador de admisión dinámico para Kubernetes que aplica políticas basadas en CustomResourceDefinition (basadas en CRD) que ejecuta Open Policy Agent (OPA).

Los controladores de admisión son complementos de Kubernetes que interceptan solicitudes al servidor de la API de Kubernetes antes de que se conserve un objeto, pero después de que se autentica y autoriza la solicitud. Puedes usar controladores de admisión para limitar el uso de un clúster.

Instala el controlador de políticas en tu clúster de GKE. El plano incluye políticas de ejemplo para ayudar a proteger un clúster. Aplicas de forma automática las políticas a tu clúster mediante el Sincronizador de configuración. Debes aplicar las siguientes políticas:

Anthos Service Mesh

Administra comunicaciones seguras entre servicios

Anthos Service Mesh te ayuda a supervisar y administrar una malla de servicios basada en Istio. Una malla de servicios es una capa de infraestructura que ayuda a crear una comunicación administrada, observable y segura entre todos tus servicios.

Anthos Service Mesh ayuda a simplificar la administración de las comunicaciones seguras en los servicios de las siguientes maneras:

  • Te permite administrar la autenticación y la encriptación del tráfico (protocolos compatibles dentro del clúster mediante la comunicación mutua de la capa de transporte (mTLS)). Anthos Service Mesh administra el aprovisionamiento y la rotación de claves y certificados mTLS para cargas de trabajo de Anthos sin interrumpir las comunicaciones. La rotación periódica de las claves mTLS es una práctica recomendada de seguridad que ayuda a reducir la exposición en caso de un ataque.
  • Te permite configurar políticas de seguridad de red según la identidad del servicio en lugar de la dirección IP de un par de la red. Anthos Service Mesh se usa para configurar políticas de control de acceso (firewall) de identidad que te permiten crear políticas de seguridad independientes de la ubicación de red de la carga de trabajo. Este enfoque simplifica el proceso de configuración de las políticas de comunicación de servicio a servicio.
  • Te permite configurar políticas que permiten el acceso desde ciertos clientes.

El plano te guía para instalar Anthos Service Mesh en tu clúster. Debes configurar el espacio de nombres del usuario para la inyección automática del proxy de sidecar. Este enfoque garantiza que las apps en el espacio de nombres del usuario sean parte de la malla. Debes configurar Anthos Service Mesh de forma automática mediante el Sincronizador de configuración. Configura la malla para que realice las siguientes acciones:

  • Aplicar la comunicación mTLS entre los servicios en la malla.
  • Limitar el tráfico saliente de la malla solo a los hosts conocidos.
  • Limitar la comunicación autorizada entre los servicios de la malla. Por ejemplo, las aplicaciones en el espacio de nombres del usuario solo pueden comunicarse con aplicaciones en el mismo espacio de nombres o con un conjunto de hosts externos conocidos.
  • Enrutar todo el tráfico saliente mediante una puerta de enlace de malla en la que puedes aplicar más controles de tráfico

Taints y afinidades de nodos

Controla la programación de cargas de trabajo

Los taints de nodo y la afinidad de nodos son mecanismos de Kubernetes que te permiten influir en la forma en que se programan los pods en los nodos del clúster.

Los nodos con taint repelen Pods. Kubernetes no programará un Pod en un nodo con taint, a menos que el Pod tenga una tolerancia al taint. Puedes usar los taints de nodos para reservar nodos a fin de que los usen solo ciertas cargas de trabajo o usuarios. Los taints y las tolerancias suelen usarse en clústeres de multiusuarios. Consulta la documentación sobre nodos dedicados con taints y tolerancias para obtener más información.

La afinidad de nodos te permite restringir los Pods a nodos con etiquetas específicas. Si un Pod tiene un requisito de afinidad de nodos, Kubernetes no programará el Pod en un nodo, a menos que el nodo tenga una etiqueta que coincida con él. Puedes usar la afinidad de nodos para asegurarte de que los Pods se programen en nodos adecuados.

Puedes usar los taints de nodo y la afinidad de nodo a fin de garantizar que los Pods de carga de trabajo de los usuarios se programen exclusivamente en los nodos reservados para el usuario.

El plano te ayuda a controlar la programación de las aplicaciones de usuario de las siguientes maneras:

  • Crear un grupo de nodos de GKE dedicado al usuario. Cada nodo del grupo tiene un taint relacionado con el nombre del usuario.
  • Aplicar de forma automática la tolerancia adecuada y la afinidad de nodos a cualquier Pod que se oriente al espacio de nombres del usuario. Aplicas la tolerancia y la afinidad mediante mutaciones de PolicyController.

Privilegio mínimo

Limita el acceso a los recursos del clúster y del proyecto

Es una práctica recomendada de seguridad adoptar un principio de privilegio mínimo para tus proyectos y recursos de Google Cloud, como los clústeres de GKE. De esta manera, las aplicaciones que se ejecutan dentro del clúster, y los desarrolladores y operadores que usan el clúster solo tienen el conjunto mínimo de permisos necesarios.

El plano te ayuda a usar las cuentas de servicio con privilegios mínimos de las siguientes maneras:

  • Cada grupo de nodos de GKE recibe su propia cuenta de servicio. Por ejemplo, los nodos del grupo de nodos de usuario usan una cuenta de servicio dedicada a esos nodos. Las cuentas de servicio de nodo se configuran con los permisos mínimos necesarios.
  • El clúster usa Workload Identity para asociar las cuentas de servicio de Kubernetes a las cuentas de servicio de Google. De esta manera, las apps de usuario pueden tener acceso limitado a cualquier API de Google requerida sin descargar y almacenar una clave de cuenta de servicio. Por ejemplo, puedes otorgar a la cuenta de servicio permisos para leer datos de un bucket de Cloud Storage.

El plano te ayuda a restringir el acceso a los recursos del clúster de las siguientes maneras:

  • Debes crear un rol de muestra de RBAC de Kubernetes con permisos limitados para administrar aplicaciones. Puedes otorgar este rol a los usuarios y grupos que operan las aplicaciones en el espacio de nombres del usuario. De esta manera, esos usuarios solo tienen permisos para modificar los recursos de la aplicación en el espacio de nombres del usuario. No tienen permisos para modificar los recursos a nivel de clúster ni la configuración de seguridad sensible, como las políticas de Anthos Service Mesh.

Revisión general

Para implementar la arquitectura que se describe en este documento, haz lo siguiente:

  1. Determina si implementarás el plano en conjunto con el plano de base de seguridad o sin él. Si eliges no implementar el modelo del plano de bases de seguridad, asegúrate de que tu entorno tenga un modelo de referencia de seguridad similar implementado.
  2. Revisa el archivo readme del plano y asegúrate de cumplir con todos los requisitos.
  3. En el entorno de pruebas, implementa una instancia de esta arquitectura. Como parte de tu proceso de prueba, haz lo siguiente:
    1. Implementa un servicio de usuario de ejemplo y verifica la configuración del clúster.
    2. Agrega otro usuario al clúster.
  4. Implementa el plano en tu entorno de producción.
  5. Agrega más usuarios al clúster.

¿Qué sigue?