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 conocidas en Kubernetes, pero este 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 Platform (GCP) administra las cuentas de usuario de Kubernetes y estas pueden ser de uno de los siguientes dos tipos:

  1. Cuenta de Google
  2. Cuenta de servicio de Google Cloud Platform (GCP)

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

A pesar de los nombres similares, las cuentas de servicio de Kubernetes y las de GCP 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. En cambio, las cuentas de servicio de GCP forman parte de un proyecto de GCP y se les pueden otorgar permisos con facilidad dentro de los clústeres y los clústeres de proyecto de Google Cloud Platform, así como a cualquier recurso de GCP que use Cloud Identity & Access Management (Cloud IAM). Esto hace que las cuentas de servicio de GCP sean más potentes que las de Kubernetes. Para cumplir con el principio de seguridad de privilegio mínimo, debes considerar el uso de cuentas de servicio de GCP solo cuando se requieran sus funciones.

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 basado en funciones (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 de las Cuentas de Google y a las cuentas de servicio de GCP y Kubernetes. A fin de simplificar y optimizar la estrategia de autenticación y autorización para Google Kubernetes Engine, debes asegurarte de que el Control de acceso según el atributo esté inhabilitado para que RBAC de Kubernetes y Cloud IAM sean la fuente 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.

Según la configuración 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 permitan 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 autenticación, debes asegurarte de que hayas inhabilitado la autenticación básica con el ajuste de un nombre de usuario y contraseña vacíos para la configuración de MasterAuth. En la misma configuración, puedes inhabilitar el certificado de cliente, lo que garantiza que tengas una clave menos que considerar cuando bloquees el acceso al clúster.

Otra manera de ayudarte a asegurar la instancia principal de Kubernetes 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 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 las cargas de trabajo en las instancias de Compute Engine que se ejecutan en el proyecto de GCP. 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 al nivel del nodo disponibles en GCP.

Container-Optimized OS

Según la configuración 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 características avanzadas para mejorar la seguridad de los clústeres de Google Kubernetes Engine, incluidos los 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 Google Kubernetes Engine te permite habilitar las actualizaciones automáticas.

Asegura 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 según la configuración 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 metadatos sensibles de instancia si inhabilitas las API heredadas y si usas el ocultamiento de metadatos. El ocultamiento de metadatos garantiza que los pods que se ejecutan en el clúster no puedan acceder a datos sensibles mediante el filtro de 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 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:

Cómo filtrar el tráfico del balanceo de cargas

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

Para configurar este filtro, 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 haces la configuración loadBalancerSourceRanges, todas las direcciones pueden acceder al servicio mediante su IP externa.

Para los casos en los que no se requiera acceso al servicio, considera usar un balanceador de cargas interno. Este respeta 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 las tácticas que los administradores y usuarios pueden usar para limitar las capacidades de los contenedores en ejecución a fin de modificar otros contenedores en el clúster, los hosts en los que se ejecutan y los servicios de GCP habilitados en el proyecto.

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 rechaza las siguientes capacidades a los contenedores:

  • Escribir archivos directamente en /proc/
  • Escribir en archivos que no están en el directorio de ID de un proceso (/proc/)
  • Escribir en archivos en /proc/sys que no sean /proc/sys/kernel/shm*
  • Activar sistemas de archivos

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

Cómo proporcionar a los pods acceso a los recursos de GCP

Es posible que los contenedores y pods necesiten acceso a otros recursos en GCP. Una manera de hacer que las aplicaciones obtengan acceso a las credenciales de los recursos de GCP es usar las credenciales de la cuenta de servicio de los clústeres de Kubernetes desde los metadatos. Sin embargo, cualquier pod que se ejecute en el clúster puede acceder a estas credenciales. Debes crear y configurar una cuenta de servicio personalizada para los clústeres que tengan las funciones de IAM mínimas que se deben aplicar a todos los pods que se ejecutan en el clúster.

Otra manera de proporcionar credenciales de aplicación es mediante una clave JSON de cuenta de servicio. 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 a la cuenta de servicio las funciones de Cloud IAM correctas, puedes crear una clave de cuenta de servicio JSON y activarla en el pod mediante un secreto de Kubernetes.

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

Cómo usar la autorización binaria

La Autorización binaria es un servicio en GCP que proporciona seguridad de la cadena de suministro para 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.

Para obtener instrucciones sobre cómo crear un clúster con la autorización binaria habilitada, visita Crear un clúster en la Documentación de 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:

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...