Descripción general de seguridad

Google Kubernetes Engine (GKE) ofrece varias formas de ayudar a proteger tus cargas de trabajo. Proteger las cargas de trabajo en GKE implica muchas capas de la pila, 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.

Es mejor adoptar un enfoque por capas para proteger los clústeres y las cargas de trabajo. Puedes aplicar el principio de privilegio mínimo al nivel de acceso proporcionado a tus usuarios y aplicación. En cada capa puede haber diferentes concesiones que deban realizarse y que permitan el nivel adecuado de flexibilidad y seguridad para que la organización implemente y mantenga sus cargas de trabajo de forma segura. Por ejemplo, algunas configuraciones de seguridad pueden ser demasiado limitantes a fin de que determinados tipos de aplicaciones o casos prácticos funcionen sin una reestructuración significativa.

En este documento, se proporciona una descripción general de cada capa de la infraestructura y se muestra cómo puedes configurar sus características de seguridad para que se ajusten mejor a tus necesidades.

Autenticación y autorización

Kubernetes admite dos tipos de autenticación:

  1. Las cuentas de usuario son cuentas que Kubernetes conoce, pero no administra. Por ejemplo, no puedes crearlas ni borrarlas con kubectl.
  2. Las cuentas de servicio son cuentas que Kubernetes crea y administra, pero solo las pueden usar las entidades creadas en Kubernetes, como los pods.

En un clúster de GKE, Google Cloud administra las cuentas de usuario de Kubernetes, que pueden ser de uno de estos dos tipos:

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

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

A pesar de tener nombres similares, las cuentas de servicio de Kubernetes y las cuentas de servicio de Google Cloud son entidades diferentes. Las cuentas de servicio de Kubernetes forman parte del clúster en el que están definidas y, por lo general, se usan dentro de ese clúster. Por el contrario, las cuentas de servicio de Google Cloud son parte de un proyecto de Google Cloud. Además, se les pueden otorgar permisos dentro de clústeres y de clústeres de proyectos de Google Cloud, así como permisos a cualquier recurso de Google Cloud mediante Cloud Identity and Access Management (Cloud IAM). Esto hace que las cuentas de servicio de Google Cloud sean más potentes que las de Kubernetes. Para seguir el principio de seguridad de menor privilegio, debes considerar usar cuentas de servicio de Google Cloud solo cuando sus funciones sean obligatorias.

Para configurar un acceso más detallado a los recursos de Kubernetes en el nivel del clúster o en los espacios de nombres de Kubernetes, usa el Control de acceso según la función (RBAC). Este te permite crear políticas detalladas que definan a qué operaciones y recursos pueden acceder los usuarios y las cuentas de servicio. Con RBAC, puedes controlar el acceso a las Cuentas de Google, las cuentas de servicio de Google Cloud y las cuentas de servicio de Kubernetes. A fin de simplificar y optimizar aún más tu estrategia de autenticación y autorización para GKE, debes asegurarte de que el Control de acceso basado en atributos heredados esté inhabilitado de modo que Kubernetes RBAC e IAM sean las fuentes de la verdad.

Para obtener más información, sigue estas sugerencias:

Seguridad del plano de control

En GKE, Google administra 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 API, el programador, el administrador del controlador y la base de datos etcd donde se conserva la configuración de Kubernetes.

De forma predeterminada, los componentes del plano de control usan una dirección IP pública. Puedes proteger el servidor de API de Kubernetes si usas redes autorizadas y clústeres privados que te permitan asignar una dirección IP privada al plano de control además de inhabilitar el acceso en la dirección IP pública.

Puedes controlar la autenticación del clúster en Google Kubernetes Engine mediante IAM como proveedor de identidad. Para obtener más información sobre la autenticación, consulta Autentícate en el servidor de la API de Kubernetes.

Otra manera de ayudarte a proteger tu plano de control es garantizar que realizas la rotación de credenciales de forma habitual. Cuando se inicia la rotación de credenciales, se rotan los certificados SSL y la autoridad certificadora del clúster. GKE automatiza este proceso y garantiza que la dirección IP del plano de control rote.

Para obtener más información, sigue estas sugerencias:

Seguridad de nodos

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

Container‑Optimized OS

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

  • Firewall bloqueado
  • Sistema de archivos de solo lectura cuando sea posible
  • Cuentas de usuario restringido y acceso inhabilitado

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

Actualizaciones de nodos

Una práctica recomendada es parchar el SO de forma habitual. Es posible que, de vez en cuando, los problemas de seguridad en el entorno de ejecución del contenedor, Kubernetes, o el sistema operativo del nodo requieran que actualices los nodos con mayor urgencia. Cuando actualizas el nodo, el software del nodo se actualiza a las últimas versiones.

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

Protege los nodos de cargas de trabajo sospechosas

Para los clústeres que ejecutan cargas de trabajo desconocidas o sospechosas, una buena práctica es proteger el sistema operativo en el nodo de la carga de trabajo sospechosa que se ejecuta en un pod.

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

Puedes habilitar GKE Sandbox en tu clúster para aislar las cargas de trabajo sospechas en zonas de pruebas dentro del nodo. GKE Sandbox se compila con gVisor, un proyecto de código abierto.

Asegura los metadatos de instancia

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

Puedes bloquear las rutas de acceso a metadatos de instancia sensibles con la federación de identidades para cargas de trabajo para GKE. La federación de identidades para cargas de trabajo para GKE habilita el servidor de metadatos de GKE en el clúster, que filtra las solicitudes a campos sensibles, como kube-env.

La federación de identidades para cargas de trabajo para GKE siempre está habilitada en los clústeres de Autopilot. En los clústeres de Standard, los Pods tienen acceso a los metadatos de instancia, a menos que habilites de forma manual la federación de identidades para cargas de trabajo para GKE.

Seguridad de redes

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

Cómo limitar la comunicación de pod a pod

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

Los administradores y usuarios del clúster pueden bloquear las conexiones de entrada y salida creadas desde y hacia los pods en un espacio de nombres mediante las políticas de red. Según la configuración predeterminada, cuando no hay políticas de red definidas, todo el tráfico de entrada y salida puede fluir dentro y fuera de todos los pods. Las políticas de red permiten usar etiquetas para definir el tráfico que fluye a través de los pods.

Una vez que se aplica una política de red en un espacio de nombres, se descarta todo el tráfico desde y hacia los pods que no coincidan con las etiquetas configuradas. Como parte de la creación de clústeres o espacios de nombres, puedes aplicar el tráfico rechazado predeterminado a la entrada y salida de cada pod para asegurarte de que las cargas de trabajo nuevas agregadas al clúster autoricen de manera explícita el tráfico que requieran.

Para obtener más información, sigue estas sugerencias:

Filtra el tráfico del balanceo de cargas

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

Para configurar este filtrado, puedes usar la configuración loadBalancerSourceRanges del objeto de servicio. Con este parámetro de configuración, puedes proporcionar una lista de los rangos CIDR para los cuales te gustaría permitir el acceso al servicio. Si no configuras loadBalancerSourceRanges, todas las direcciones pueden acceder al servicio a través de su IP externa.

Para los casos en los que no se requiera acceso al servicio, considera usar un balanceador de cargas interno. El balanceador de cargas interno también respeta la configuración loadBalancerSourceRanges cuando es necesario filtrar el tráfico desde el interior de la VPC.

Para obtener más información, sigue el instructivo del balanceo de cargas interno.

Cómo asegurar 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 los administradores y usuarios pueden implementar para limitar el efecto de un contenedor en ejecución sobre otros contenedores del mismo clúster, los nodos en los que pueden ejecutarse los contenedores y los servicios de Google Cloud habilitados en los proyectos de los usuarios.

Limita los privilegios del proceso de contenedor del Pod

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

GKE también te permite configurar opciones relacionadas con la seguridad mediante el contexto de seguridad en los pods y los contenedores. Estos parámetros de configuración te permiten cambiar la configuración de seguridad de tus procesos, por ejemplo:

  • Usuario y grupo para ejecutar
  • Funciones de Linux disponibles
  • Capacidad de escalar privilegios

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

Los sistemas operativos de los nodos de GKE, Container-Optimized OS y Ubuntu, aplican las políticas de seguridad predeterminadas de AppArmor de Docker a todos los contenedores que se inician con Kubernetes. Puedes ver la plantilla del perfil en GitHub. Entre otros aspectos, el perfil les niega las siguientes capacidades 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*
  • Activar sistemas de archivos

Para obtener más información, siga estas sugerencias:

Cómo proporcionarles a los pods acceso a los recursos de Google Cloud

Es posible que tus contenedores y pods necesiten acceso a otros recursos de Google Cloud. Hay tres maneras de brindar este acceso.

La forma más segura de autorizar a los Pods para acceder a los recursos de Google Cloud es con la federación de identidades para cargas de trabajo para GKE. La federación de identidades para cargas de trabajo para GKE permite que una cuenta de servicio de Kubernetes se ejecute como 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.

La federación de identidades para cargas de trabajo para GKE se puede usar con GKE Sandbox.

Cuenta de servicio de nodo

En los clústeres de Standard, tus Pods también pueden autenticarse en Google Cloud mediante 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 otorgar credenciales para los recursos de Google Cloud a las aplicaciones mediante la clave de cuenta de servicio. Este enfoque se desaconseja debido a la dificultad de administrar las claves de las cuentas de forma segura.

Si eliges este método, usa cuentas de servicio de IAM personalizadas para cada aplicación a fin de que las aplicaciones tengan los permisos mínimos necesarios. Otorga a cada cuenta de servicio los roles mínimos de IAM necesarios para que la aplicación sincronizada funcione correctamente. Conservar las cuentas de servicio específicas de la aplicación facilita la revocación del acceso en el caso de una vulneración sin afectar a otras aplicaciones. Una vez que le hayas asignado los roles de IAM correctos a tu cuenta de servicio, puedes crear una clave de cuenta de servicio JSON y, luego, activarla en el pod mediante un objeto Secret de Kubernetes.

Use la autorización binaria

La autorización binaria es un servicio de Google Cloud que proporciona seguridad para la cadena de suministro de software a las aplicaciones que se ejecutan en la nube. La autorización binaria funciona con imágenes que implementas en GKE desde Artifact Registry o algún otro registro de imágenes de contenedores.

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 hayan completado correctamente antes de implementar una aplicación en tu entorno de producción. A fin de obtener instrucciones para crear un clúster con la autorización binaria habilitada, consulta Crea un clúster en la documentación de la autorización binaria.

Con la validación continua (CV) de autorización binaria, puedes asegurarte de que las imágenes de contenedor asociadas con los Pods se supervisen con regularidad para asegurarte de que cumplan con los procesos internos en evolución.

Registros de auditoría

El registro de auditoría proporciona una forma para que los administradores retengan, consulten, procesen y generen alertas sobre los eventos que ocurren en los entornos GKE. Los administradores pueden usar la información registrada a fin de realizar análisis forenses, crear alertas en tiempo real o catalogar cómo y quién usa una flota de clústeres de GKE.

De forma predeterminada, GKE realiza registros de la actividad del administrador. Como alternativa, puedes registrar eventos de acceso a los datos según los tipos de operaciones que desees inspeccionar.

Para obtener más información, sigue estas sugerencias:

Medidas de seguridad integradas.

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

Medidas de seguridad del clúster de Autopilot

Los clústeres de Autopilot aplican varias configuraciones de seguridad según nuestra experiencia y las prácticas recomendadas de la industria. Para obtener más información, consulta Medidas de seguridad en Autopilot.

Medidas de seguridad de clúster estándar

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 la siguiente configuración de seguridad:

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