Descripción general de seguridad

Google Kubernetes Engine proporciona varias formas de ayudar a proteger tus cargas de trabajo. La protección de las cargas de trabajo en Google Kubernetes Engine implica varias capas de la pila, incluidos los contenidos de la imagen del contenedor, el entorno de ejecución del contenedor, la red del clúster y el acceso al servidor de 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 las administra. Por ejemplo, no puedes crearlas o 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 Google Kubernetes Engine, 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 Google Kubernetes Engine, debes asegurarte de que el Control de acceso basado en atributos heredados esté inhabilitado de modo que Kubernetes RBAC y Cloud IAM sean las fuentes de información.

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

Seguridad del plano de control

En Google Kubernetes Engine, Google administra los componentes de instancia principal de Kubernetes y les da mantenimiento. Los componentes de instancia principal 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 de instancia principal usan una dirección IP pública. Puedes proteger el servidor de API de Kubernetes si usas redes autorizadas de instancia principal y clústeres privados, que te permiten asignar una dirección IP privada a la instancia principal 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 si usas Cloud IAM como proveedor de identidad. Sin embargo, la autenticación basada en el nombre de usuario y contraseña heredada está habilitada según la configuración predeterminada en Google Kubernetes Engine. Para mejorar la seguridad de la autenticación, debes asegurarte de haber inhabilitado la autenticación básica mediante el establecimiento de un nombre de usuario y contraseña vacíos en la configuración de MasterAuth. En la misma configuración, puedes inhabilitar el certificado de cliente, lo que garantiza que tendrás una clave menos que considerar cuando bloquees el acceso al clúster.

Otra manera de ayudarte a proteger la instancia principal de Kubernetes es garantizar la rotación de credenciales de forma habitual. Cuando se inicia la rotación de credenciales, se rotan los certificados SSL y la autoridad certificada del clúster. Google Kubernetes Engine automatiza este proceso, que garantiza que la dirección IP de la instancia principal rote.

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

Seguridad de nodos

Google Kubernetes Engine 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 Google Kubernetes Engine 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 Google Kubernetes Engine 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 Google Kubernetes Engine, 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 de forma manual los nodos del clúster, pero Google Kubernetes Engine también 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.

Cómo asegurar los metadatos de instancia

Los nodos de Google Kubernetes Engine se ejecutan como instancias de Compute Engine y tienen acceso a los metadatos de instancia de forma predeterminada. Los metadatos de instancia 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 Google Kubernetes Engine 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, de forma 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 hasta 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 hasta 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:

Cómo filtrar 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 que desees incluir en la lista blanca para acceder 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 estas sugerencias:

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.

Cómo limitar 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. Google Kubernetes Engine 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 Google Kubernetes Engine, 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 proporcionarle 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. Crea y configura una cuenta de servicio personalizada que tenga las funciones básicas de Cloud 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 GCP 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 Cloud 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 Cloud IAM correctas a la cuenta de servicio, puedes crear una clave de cuenta de servicio JSON y activarla en el pod mediante un secreto de Kubernetes.

Cómo usar 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 Cloud. 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 de manera correcta antes de implementar una aplicación en tu entorno de producción.

Con el fin de obtener instrucciones para crear un clúster con la autorización binaria habilitada, visita la página sobre cómo crear un clúster en la documentación de la autorización binaria.

Registro de auditoría

El registro de auditoría proporciona una manera para que los administradores conserven, consulten, procesen y alerten acerca de los eventos que ocurren en los entornos de Google Kubernetes Engine. Los administradores pueden usar la información registrada a fin de realizar análisis forenses, alertas en tiempo real o para catalogar cómo y quién usa una flota de clústeres de Google Kubernetes Engine.

Según la configuración predeterminada, Google Kubernetes Engine realiza los registros de actividad de 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: