Descripción general de seguridad

Google Kubernetes Engine (GKE) proporciona 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

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.

Puedes actualizar manualmente los nodos en el clúster, pero GKE te permite habilitar las actualizaciones automáticas.

Cómo proteger 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

Los nodos de GKE se ejecutan como instancias de Compute Engine y, como tales, tienen acceso a los metadatos de las instancias de forma predeterminada. Los metadatos de las instancias se usan para proporcionar a los nodos credenciales y configuraciones usadas en el arranque y la conexión a los nodos de instancia principal de Kubernetes. Sin embargo, un pod que se ejecuta en un nodo no siempre necesita esta información que contiene datos sensibles, como la clave de la cuenta de servicio del nodo. Puedes bloquear las rutas de acceso a metadatos de instancia sensibles si inhabilitas las API heredadas y si usas el ocultamiento de metadatos. El ocultamiento de metadatos garantiza que los pods que se ejecutan en tu clúster no puedan acceder a datos sensibles mediante el filtrado de las solicitudes a campos como kube-env.

Seguridad de red

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. GKE 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 cambiar esta configuración en el nivel del clúster en lugar de cambiarla en el pod o contenedor, debes implementar una PodSecurityPolicy. Los administradores de clústeres pueden usar PodSecurityPolicies para asegurarse de que todos los pods en un clúster se adhieran a la política de modelo de referencia mínima que definas.

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, sigue 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 simple y segura de autorizar los pods para acceder a los recursos de Google Cloud es con Workload Identity. Workload Identity permite que una cuenta de servicio de Kubernetes se ejecute como cuenta de servicio de Google Cloud. Los pods que se ejecutan como la cuenta de servicio de Kubernetes tienen los permisos de la cuenta de servicio Google Cloud.

Workload Identity se puede usar con GKE Sandbox.

Cuenta de servicio de nodo

Tus pods también pueden autenticarse en Google Cloud con las credenciales de cuenta de servicio de los clústeres de Kubernetes a partir de los metadatos. Sin embargo, cualquier pod que se ejecute en el clúster puede acceder a estas credenciales si Workload Identity no está habilitado. Crea y configura una cuenta de servicio personalizada que tenga las funciones básicas de IAM que requieren todos los pods que se ejecutan en el clúster.

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

Clave JSON de la cuenta de servicio

Una tercera forma de otorgar credenciales para los recursos de Google Cloud a las aplicaciones es usar la clave de la cuenta de servicio de forma manual. Este enfoque se desaconseja debido a la dificultad de administrar las claves de las cuentas de forma segura.

Debes usar cuentas de servicio de Google Cloud específicas de la aplicación a fin de proporcionar credenciales para que las aplicaciones tengan los permisos mínimos necesarios. A cada cuenta de servicio se le asignan las funciones de IAM necesarias para que la aplicación sincronizada funcione correctamente. Conservar la cuenta de servicio específica de la aplicación facilita la revocación de su acceso en el caso de una concesión sin afectar a otras aplicaciones. Una vez que le hayas asignado las funciones de IAM correctas 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 Container Registry o algún otro registro de imágenes de contenedores. Con 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.

Audit Logging

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: