Descripción general de la seguridad de GKE

Google Kubernetes Engine (GKE) ofrece muchas formas de proteger tus cargas de trabajo. La protección de las cargas de trabajo en GKE implica muchas capas de la pila, incluido el contenido de la 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.

Lo más recomendable es adoptar un enfoque por capas para proteger tus clústeres y cargas de trabajo. Puedes aplicar el principio de mínimos accesos al nivel de acceso que proporcionas a tus usuarios y a tu aplicación. En cada capa, tu organización puede tener que hacer diferentes concesiones para permitir el nivel adecuado de flexibilidad y seguridad para desplegar y mantener tus cargas de trabajo de forma segura. Por ejemplo, algunos ajustes de seguridad pueden ser demasiado restrictivos para que determinados tipos de aplicaciones o casos prácticos funcionen sin una refactorización significativa.

En este documento se ofrece una descripción general de cada capa de su infraestructura y se muestra cómo puede configurar sus funciones de seguridad para que se adapten mejor a sus necesidades.

Este documento está dirigido a especialistas en seguridad que definen, gestionan e implementan políticas y procedimientos para proteger los datos de una organización frente a accesos no autorizados. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Autenticación y autorización

Kubernetes admite dos tipos de autenticación:

  1. Las cuentas de usuario son cuentas que Kubernetes conoce, pero que no gestiona. Por ejemplo, no puedes crearlas ni eliminarlas con kubectl.
  2. Las cuentas de servicio son cuentas creadas y gestionadas por Kubernetes, pero solo pueden usarlas entidades creadas por Kubernetes, como los pods.

En un clúster de GKE, Google Cloudgestiona las cuentas de usuario de Kubernetes, que pueden ser de uno de los dos tipos siguientes:

  1. Cuenta de Google
  2. Google Cloud cuenta de servicio

Una vez autenticadas, debes autorizar a estas identidades para crear, leer, actualizar o eliminar recursos de Kubernetes.

A pesar de tener nombres similares, las cuentas de servicio de Kubernetes y las Google Cloud cuentas de servicio son entidades diferentes. Las cuentas de servicio de Kubernetes forman parte del clúster en el que se definen y se suelen usar en ese clúster. Por el contrario, lasGoogle Cloud cuentas de servicio forman parte de un Google Cloud proyecto y se les pueden conceder permisos fácilmente tanto en los clústeres como en los Google Cloud clústeres del proyecto Google Cloud , así como en cualquier Google Cloud recurso que use Gestión de Identidades y Accesos (IAM). Esto hace que las Google Cloud cuentas de servicio sean más potentes que las cuentas de servicio de Kubernetes. Para seguir el principio de seguridad de mínimos privilegios, debes usar las Google Cloud cuentas de servicio solo cuando se requieran sus funciones.

Para configurar un acceso más granular a los recursos de Kubernetes a nivel de clúster o en los espacios de nombres de Kubernetes, se usa el control de acceso basado en roles (RBAC). El control de acceso basado en roles te permite crear políticas detalladas que definen a qué operaciones y recursos pueden acceder los usuarios y las cuentas de servicio. Con RBAC, puedes controlar el acceso de las cuentas de Google, las cuentas de servicio de Google Cloud y las cuentas de servicio de Kubernetes. Para simplificar y optimizar aún más tu estrategia de autenticación y autorización en GKE, debes asegurarte de que el control de acceso basado en atributos antiguo esté inhabilitado para que RBAC de Kubernetes y IAM sean las fuentes de información veraz.

Para obtener más información:

Seguridad del plano de control

En GKE, Google gestiona y mantiene los componentes del plano de control de Kubernetes. Los componentes del plano de control alojan el software que ejecuta el plano de control de Kubernetes, incluido el servidor de la API, el programador, el gestor de controladores y la API etcd. Si el clúster ejecuta instancias de la base de datos etcd en las VMs del plano de control, Google también gestiona y mantiene estas instancias.

Puedes acceder al plano de control mediante un endpoint basado en DNS (opción recomendada), endpoints basados en IP o ambos. Si usas endpoints basados en IP, puedes proteger el servidor de la API de Kubernetes usando redes autorizadas y sin habilitar el endpoint externo del plano de control. Esto te permite asignar una dirección IP interna al plano de control e inhabilitar el acceso a la dirección IP externa. Si usas un endpoint basado en DNS, puedes usar IAM y Controles de Servicio de VPC para proteger el acceso al plano de control con políticas basadas en la identidad y en la red.

Puedes gestionar la autenticación de clústeres en Google Kubernetes Engine usando la gestión de identidades y accesos como proveedor de identidades. Para obtener información sobre la autenticación, consulta Autenticar en el servidor de la API de Kubernetes.

Otra forma de proteger el plano de control es asegurarse de que se realiza la rotación de credenciales de forma periódica. Cuando se inicia la rotación de credenciales, se rotan los certificados SSL y la autoridad de certificación del clúster. GKE automatiza este proceso y también se asegura de que la dirección IP de tu plano de control rote.

Para obtener más información:

Seguridad de los nodos

GKE implementa tus cargas de trabajo en instancias de Compute Engine que se ejecutan en tu Google Cloud proyecto. Estas instancias se adjuntan a tu clúster de GKE como nodos. En las siguientes secciones se explica cómo aprovechar las funciones de seguridad a nivel de nodo que tienes disponibles en Google Cloud.

Container-Optimized OS

De forma predeterminada, los nodos de GKE usan Container-Optimized OS de Google como sistema operativo en el que ejecutar Kubernetes y sus componentes. Container-Optimized OS implementa varias funciones avanzadas para mejorar la seguridad de los clústeres de GKE, entre las que se incluyen las siguientes:

  • Cortafuegos bloqueado
  • Sistema de archivos de solo lectura siempre que sea posible
  • Cuentas de usuario limitadas e inicio de sesión de root inhabilitado

Los nodos de Autopilot de GKE siempre usan Container-Optimized OS como sistema operativo.

Actualizaciones de nodo

Te recomendamos que apliques parches a tu sistema operativo con regularidad. De vez en cuando, es posible que tengas que actualizar tus nodos con más urgencia debido a problemas de seguridad en el entorno de ejecución de contenedores, en Kubernetes o en el sistema operativo del nodo. Cuando actualizas tu nodo, el software del nodo se actualiza a sus versiones más recientes.

Los clústeres de GKE admiten actualizaciones automáticas. En los clústeres Autopilot, las actualizaciones automáticas siempre están habilitadas. También puedes actualizar manualmente los nodos de un clúster estándar.

Proteger los nodos de cargas de trabajo no fiables

En los clústeres que ejecutan cargas de trabajo desconocidas o no fiables, es recomendable proteger el sistema operativo del nodo de la carga de trabajo no fiable que se ejecuta en un pod.

Por ejemplo, los clústeres multiinquilino como los proveedores de software como servicio (SaaS) suelen ejecutar código desconocido enviado por sus usuarios. La investigación de seguridad es otra aplicación en la que las cargas de trabajo pueden necesitar un aislamiento más sólido que el que proporcionan los nodos de forma predeterminada.

Puedes habilitar GKE Sandbox en tu clúster para aislar las cargas de trabajo que no sean de confianza en zonas de pruebas del nodo. GKE Sandbox se ha creado con gVisor, un proyecto de código abierto.

Metadatos de instancias seguros

GKE usa metadatos de instancia de las instancias de Compute Engine subyacentes para proporcionar a los nodos credenciales y configuraciones que se usan para inicializar los nodos y conectarse al plano de control. Estos metadatos contienen información sensible a la que no necesitan acceder los pods del nodo, como la clave de la cuenta de servicio del nodo.

Puede proteger las rutas de metadatos de instancias sensibles mediante Workload Identity Federation for GKE. Workload Identity Federation for GKE habilita el servidor de metadatos de GKE en tu clúster, que filtra las solicitudes a campos sensibles, como kube-env.

Workload Identity Federation para GKE siempre está habilitado en los clústeres de Autopilot. En los clústeres estándar, los pods tienen acceso a los metadatos de las instancias a menos que habilites manualmente Workload Identity Federation for GKE.

Seguridad de la red

La mayoría de las cargas de trabajo que se ejecutan en GKE necesitan comunicarse con otros servicios que pueden ejecutarse dentro o fuera del clúster. Puedes usar varios métodos para controlar el tráfico que puede fluir a través de tus clústeres y sus pods.

Limitar la comunicación entre pods

De forma predeterminada, se puede acceder a todos los pods de un clúster a través de la red mediante su dirección IP de pod. Del mismo modo, de forma predeterminada, el tráfico de salida permite las conexiones salientes a cualquier dirección accesible en la VPC en la que se haya implementado el clúster.

Los administradores y los usuarios de clústeres pueden proteger las conexiones de entrada y salida creadas hacia y desde los pods de un espacio de nombres mediante políticas de red. De forma predeterminada, cuando no hay políticas de red definidas, se permite que todo el tráfico de entrada y salida fluya hacia y desde todos los pods. Las políticas de red te permiten usar etiquetas para definir el tráfico que fluye a través de tus pods.

Una vez que se aplica una política de red en un espacio de nombres, se rechaza todo el tráfico hacia y desde los pods que no coincidan con las etiquetas configuradas. Al crear clústeres o espacios de nombres, puedes aplicar la denegación de tráfico predeterminada tanto a la entrada como a la salida de cada pod para asegurarte de que todas las cargas de trabajo nuevas que se añadan al clúster deban autorizar explícitamente el tráfico que necesiten.

Para obtener más información:

Filtrar el tráfico con balanceo de carga

Para balancear la carga de tus pods de Kubernetes con un balanceador de carga de red, debes crear un servicio de tipo LoadBalancer que coincida con las etiquetas de tus pods. Una vez creado el servicio, tendrás una IP externa que se asigna a los puertos de tus pods de Kubernetes. El filtrado del tráfico autorizado se realiza a nivel de nodo mediante kube-proxy, que filtra en función de la dirección IP.

Para configurar este filtrado, puede usar la configuración loadBalancerSourceRanges del objeto Service. Con este parámetro de configuración, puede proporcionar una lista de intervalos de CIDR a los que quiera permitir el acceso al servicio. Si no configuras loadBalancerSourceRanges, todas las direcciones podrán acceder al servicio a través de su IP externa.

En los casos en los que no se requiera acceso externo al Servicio, considera la posibilidad de usar un balanceador de carga interno. El balanceador de carga interno también respeta el loadBalancerSourceRanges cuando es necesario filtrar el tráfico procedente del interior de la VPC.

Para obtener más información, sigue el tutorial sobre el balanceo de carga interno.

Filtrar el tráfico fuera del clúster

Para controlar el flujo de tráfico de red entre entidades externas y tu clúster, usa Cloud Next Generation Firewall. Puedes usar configuraciones de cortafuegos para, por ejemplo, bloquear el tráfico saliente de tus pods a destinos no aprobados.

Las configuraciones de firewall no son suficientes para controlar de qué registros proceden las imágenes de contenedor de tu clúster. Para limitar las extracciones de imágenes de contenedor a un conjunto de registros aprobados, consulta Bloquear imágenes de contenedor de registros no aprobados.

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 pueden emplear los administradores y los usuarios para limitar el efecto que puede tener un contenedor en ejecución en otros contenedores del mismo clúster, en los nodos en los que se pueden ejecutar contenedores y en los Google Cloudservicios habilitados en los proyectos de los usuarios.

Limitar los privilegios de los procesos de pods en contenedores

Limitar los privilegios de los procesos en contenedores es importante para la seguridad general de tu clúster. Los clústeres Autopilot de GKE siempre restringen privilegios específicos, tal como se describe en Funciones de seguridad de Autopilot.

GKE también te permite definir opciones relacionadas con la seguridad a través del contexto de seguridad en pods y contenedores. Estos ajustes te permiten cambiar la configuración de seguridad de tus procesos, como:

  • Usuario y grupo que se va a ejecutar
  • Funciones de Linux disponibles
  • Posibilidad de elevar privilegios

Para aplicar estas restricciones a nivel de clúster en lugar de a nivel de pod o de contenedor, usa el controlador PodSecurityAdmission. Los administradores de clústeres pueden usar PodSecurityAdmission para asegurarse de que todos los pods de un clúster o espacio de nombres cumplan una política predefinida en los estándares de seguridad de pods. También puedes definir políticas de seguridad para pods personalizadas a nivel de clúster mediante Gatekeeper.

Los sistemas operativos de los nodos de GKE, tanto Container-Optimized OS como Ubuntu, aplican las políticas de seguridad de AppArmor de Docker predeterminadas a todos los contenedores iniciados por Kubernetes. Puedes ver la plantilla del perfil en GitHub. Entre otras cosas, el perfil deniega las siguientes funciones a los contenedores:

  • Escribir archivos directamente en /proc/
  • Escribir en archivos que no estén en un directorio de ID de proceso (/proc/<number>)
  • Escribir en archivos de /proc/sys que no sean /proc/sys/kernel/shm*
  • Montar sistemas de archivos

Para obtener más información:

Dar acceso a los pods a los recursos de Google Cloud

Es posible que tus contenedores y pods necesiten acceder a otros recursos enGoogle Cloud. Hay tres formas de hacerlo.

La forma más segura de autorizar a los pods para que accedan a los recursos de Google Cloud es con Workload Identity Federation para GKE. Workload Identity Federation para GKE permite que una cuenta de servicio de Kubernetes se ejecute como una cuenta de servicio de IAM. Los pods que se ejecutan como la cuenta de servicio de Kubernetes tienen los permisos de la cuenta de servicio de IAM.

Workload Identity Federation para GKE se puede usar con GKE Sandbox.

Cuenta de servicio de nodo

En los clústeres estándar, tus pods también pueden autenticarse enGoogle Cloud con las credenciales de la cuenta de servicio que usa la máquina virtual (VM) de Compute Engine del nodo.

Este enfoque no es compatible con GKE Sandbox porque GKE Sandbox bloquea el acceso al servidor de metadatos de Compute Engine.

Puedes conceder credenciales para Google Cloud recursos a aplicaciones mediante la clave de cuenta de servicio. No recomendamos este enfoque debido a la dificultad de gestionar de forma segura las claves de cuenta.

Si eliges este método, usa cuentas de servicio de gestión de identidades y accesos personalizadas para cada aplicación, de forma que las aplicaciones tengan los permisos mínimos necesarios. Concede a cada cuenta de servicio los roles de gestión de identidades y accesos mínimos necesarios para que la aplicación emparejada funcione correctamente. Si las cuentas de servicio son específicas de la aplicación, será más fácil revocar el acceso en caso de que se vea comprometida sin que esto afecte a otras aplicaciones. Una vez que hayas asignado los roles de gestión de identidades y accesos correctos a tu cuenta de servicio, podrás crear una clave de cuenta de servicio JSON y, a continuación, montar la clave en tu pod mediante un secreto de Kubernetes.

Usar autorización binaria

La autorización binaria es un servicio deGoogle Cloud que proporciona seguridad en la cadena de suministro de software para las aplicaciones que se ejecutan en la nube. La autorización binaria funciona con las imágenes que despliegas en GKE desde Artifact Registry u otro registro de imágenes de contenedor.

Con la aplicación de la autorización binaria, puedes asegurarte de que los procesos internos que protegen la calidad y la integridad de tu software se han completado correctamente antes de que se despliegue una aplicación en tu entorno de producción. Para obtener instrucciones sobre cómo crear un clúster con la autorización binaria habilitada, consulta el artículo Crear un clúster de la documentación sobre la autorización binaria.

Con la validación continua (VC) de la autorización binaria, puedes asegurarte de que las imágenes de contenedor asociadas a los pods se monitoricen periódicamente para que se ajusten a tus procesos internos en constante evolución.

Registros de auditoría

El registro de auditoría permite a los administradores conservar, consultar, procesar y recibir alertas sobre los eventos que se producen en sus entornos de GKE. Los administradores pueden usar la información registrada para hacer análisis forenses, enviar alertas en tiempo real o catalogar cómo se usa una flota de clústeres de GKE y quién la usa.

De forma predeterminada, GKE registra los registros de actividad de administración. También puedes registrar eventos de acceso a datos, en función de los tipos de operaciones que te interese inspeccionar.

Para obtener más información:

Medidas de seguridad integradas

GKE aplica restricciones específicas sobre lo que puedes hacer con los objetos del sistema en tus clústeres. Cuando realizas una operación como crear o parchear una carga de trabajo, un webhook de admisión llamado warden-validating valida tu solicitud con un conjunto de operaciones restringidas y decide si permite la solicitud.

Los errores de admisión provocados por esta política son similares a los siguientes:

GKE Warden rejected the request because it violates one or more constraints.

Medidas de seguridad de los clústeres de Autopilot

Los clústeres de Autopilot aplican varios ajustes de seguridad basados en nuestra experiencia y en las prácticas recomendadas del sector. Para obtener más información, consulta Medidas de seguridad en Autopilot.

Medidas de seguridad estándar de los clústeres

Los clústeres estándar son más permisivos de forma predeterminada que los clústeres de Autopilot. Los clústeres de GKE Standard tienen los siguientes ajustes de seguridad:

  • No puedes actualizar la cuenta de servicio que usan las cargas de trabajo del sistema gestionadas por GKE, como las cargas de trabajo del espacio de nombres kube-system.
  • No puedes vincular el ClusterRole cluster-admin predeterminado a los grupos system:anonymous, system:unauthenticated o system:authenticated.