Endurecer la seguridad del clúster

En este documento se describen las prácticas recomendadas para mejorar la seguridad de los entornos de Google Kubernetes Engine (GKE). Los especialistas en seguridad que definen, gestionan e implementan políticas y procedimientos pueden usar estas prácticas recomendadas para proteger los datos de su organización.

Ya deberías conocer los siguientes conceptos:

Los nuevos clústeres de GKE implementan de forma predeterminada muchas de las prácticas recomendadas que se describen en este documento. Los clústeres en modo Autopilot tienen una postura de seguridad predeterminada más estricta que los clústeres en modo Estándar.

Para implementar y aplicar las prácticas recomendadas de este documento en toda tu organización, puedes usar los siguientes servicios:

  • Security Command Center: comprueba automáticamente si tus clústeres implementan muchas de estas prácticas recomendadas y si hay otros errores de configuración habituales.
  • Servicio de políticas de organización: aplica prácticas recomendadas específicas a los recursos de GKE en una organización, una carpeta o un proyecto. En algunas secciones de este documento se incluyen enlaces a la consola para que puedas aplicar restricciones gestionadas a esas recomendaciones. Google Cloud

Google Cloud diseño de entornos

En las siguientes secciones se describen las medidas de seguridad que debes tener en cuenta al planificar y diseñar tus recursos en Google Cloud. Los arquitectos de la nube deben seguir estas recomendaciones al planificar y definir la arquitectura. Google Cloud

Prácticas recomendadas

Planifica tu Google Cloud estructura de recursos

Recomendación: implementa el plano de aspectos básicos de las empresas, que es una base completa para tu entorno empresarial basada en nuestras prácticas recomendadas.

La arquitectura de tus Google Cloud organizaciones, carpetas y proyectos afecta a tu postura de seguridad. Diseña estos recursos básicos de forma que se puedan aplicar controles de gobernanza y seguridad a gran escala en todos tus servicios.

Planificar entornos multicliente

Recomendación: implementa Google Cloud y las prácticas recomendadas de GKE para plataformas empresariales multicliente.

Muchos clientes de GKE gestionan equipos distribuidos con flujos de trabajo y responsabilidades de ingeniería independientes. Estos entornos multiempresa deben tener una infraestructura compartida que puedan usar todos tus desarrolladores, pero restringiendo el acceso a los componentes en función de los roles y las responsabilidades. El blueprint de aplicaciones empresariales se basa en el blueprint de aspectos básicos de seguridad para empresas para ayudarte a implementar plataformas de desarrollo internas en entornos multicliente.

Para obtener más información, consulte los documentos siguientes:

Usar etiquetas para agrupar recursos Google Cloud

Recomendación: Usa etiquetas para organizar los recursos de GKE y aplicar políticas condicionales, así como para mejorar la rendición de cuentas de tus equipos.

Las etiquetas son metadatos que puedes asociar a los recursos de tus organizaciones, carpetas y proyectos para identificar dimensiones empresariales en toda tuGoogle Cloud jerarquía de recursos. Puede asociar etiquetas a clústeres y grupos de nodos de GKE y, a continuación, usar esas etiquetas para aplicar de forma condicional políticas de la organización, políticas de gestión de identidades y accesos o políticas de firewall.

Para obtener más información, consulte los documentos siguientes:

Planificar las redes de VPC

Recomendación: implementa Google Cloud y las prácticas recomendadas de GKE para el diseño de redes VPC.

El diseño de tu red VPC y las funciones que utilices influyen en la seguridad de la red. Planifica tus redes en función de tu Google Cloud jerarquía de recursos y tus objetivos de seguridad. Para obtener más información, consulta los siguientes documentos:

Diseñar un plan de respuesta a incidentes

Recomendación: crea y mantén un plan de respuesta ante incidentes que cumpla tus objetivos de seguridad y fiabilidad.

Los incidentes de seguridad pueden ocurrir incluso cuando implementas todos los controles de seguridad posibles. Un plan de respuesta a incidentes te ayuda a identificar posibles carencias en tus controles de seguridad, a responder de forma rápida y eficaz a varios tipos de incidentes y a reducir el tiempo de inactividad durante una interrupción. Para obtener más información, consulta los siguientes documentos:

Google Cloud seguridad de redes

En las secciones siguientes se ofrecen recomendaciones de seguridad para sus redes de VPC. Los arquitectos de redes y los administradores de redes deben aplicar estas recomendaciones para reducir la superficie de ataque a nivel de red y limitar el impacto de los accesos a la red no deseados.

Prácticas recomendadas

Usar reglas de cortafuegos con el principio de privilegio mínimo

Recomendación: cuando crees reglas de cortafuegos, usa el principio de mínimos accesos para proporcionar acceso solo con el fin necesario. Asegúrate de que las reglas de tu cortafuegos no entren en conflicto ni anulen las reglas de cortafuegos predeterminadas de GKE cuando sea posible.

GKE crea reglas de cortafuegos de VPC predeterminadas para habilitar la funcionalidad del sistema y aplicar buenas prácticas de seguridad. Si creas reglas de cortafuegos permisivas con una prioridad más alta que una regla de cortafuegos predeterminada (por ejemplo, una regla de cortafuegos que permita todo el tráfico entrante para depurar), tu clúster corre el riesgo de sufrir accesos no deseados.

Usar VPC compartida para el tráfico entre proyectos

Recomendación: utiliza la VPC compartida para que los recursos de varios proyectos se comuniquen entre sí mediante direcciones IP internas.

Es posible que los recursos de diferentes proyectos de tu organización necesiten comunicarse entre sí. Por ejemplo, los servicios de frontend de un clúster de GKE de un proyecto pueden necesitar comunicarse con instancias de backend de Compute Engine de otro proyecto.

Para obtener más información, consulte los documentos siguientes:

Usar redes independientes para aislar entornos

Recomendación: usa redes de VPC compartidas independientes para los entornos de staging, prueba y producción.

Aísla tus entornos de desarrollo entre sí para reducir el impacto y el riesgo de accesos no autorizados o errores disruptivos. Para obtener más información, consulta Varios proyectos host.

Configuración de seguridad inmutable

En las siguientes secciones se ofrecen recomendaciones de seguridad que solo puede configurar al crear clústeres o grupos de nodos. No puedes actualizar los clústeres ni los grupos de nodos para cambiar estos ajustes. Los administradores de la plataforma deben aplicar estas recomendaciones a los clústeres y grupos de nodos nuevos.

Usar cuentas de servicio de nodo de IAM con el mínimo de privilegios

Recomendación: Usa una cuenta de servicio de IAM personalizada para tus clústeres y grupos de nodos de GKE en lugar de la cuenta de servicio predeterminada de Compute Engine.

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones de tu proyecto u organización, es posible que la cuenta de servicio tenga más permisos de los que necesita GKE, lo que podría exponerte a riesgos de seguridad.

La cuenta de servicio adjunta a tus nodos solo debe usarse en cargas de trabajo del sistema que realicen tareas como el registro y la monitorización. Para tus propias cargas de trabajo, aprovisiona identidades mediante Workload Identity Federation para GKE.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.disallowDefaultComputeServiceAccount restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Usar una imagen de nodo de Container-Optimized OS

Recomendación: A menos que tengas un requisito específico para usar Ubuntu o Windows, utiliza la imagen de nodo de Container-Optimized OS para tus nodos.

Container-Optimized OS se ha creado, optimizado y reforzado específicamente para ejecutar contenedores. Container-Optimized OS es la única imagen de nodo compatible con el modo Autopilot y es la imagen de nodo predeterminada del modo Estándar.

Para obtener más información, consulte los documentos siguientes:

Configuración de seguridad de los nodos

En las siguientes secciones se ofrecen recomendaciones de seguridad para la configuración de nodos de GKE. Los administradores de plataformas y los ingenieros de seguridad deben aplicar estas recomendaciones para mejorar la integridad de los nodos de GKE.

Prácticas recomendadas

Usar nodos de GKE blindados

Recomendación: habilita los nodos de GKE blindados, el arranque seguro y la monitorización de integridad en todos los clústeres y grupos de nodos.

Los nodos de GKE blindados proporcionan comprobaciones de identidad e integridad verificables que mejoran la seguridad de tus nodos. Los nodos de GKE blindados y las funciones como la monitorización de integridad de nodos y el arranque seguro están siempre habilitados en los clústeres Autopilot. En los clústeres estándar, haz lo siguiente:

  • No inhabilite los nodos de GKE blindados en sus clústeres.
  • Habilita el arranque seguro en todos tus grupos de nodos.
  • No inhabilite la monitorización de integridad en sus grupos de nodos.

Para obtener más información sobre cómo habilitar estas funciones, consulta el artículo Usar nodos de GKE blindados.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableShieldedNodes restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Inhabilitar el puerto de solo lectura de kubelet no seguro

Recomendación: inhabilita el puerto de solo lectura kubelet y cambia las cargas de trabajo que usen el puerto 10255 para que usen el puerto más seguro 10250.

El proceso kubelet que se ejecuta en los nodos sirve una API de solo lectura mediante el puerto no seguro 10255. Kubernetes no realiza ninguna comprobación de autenticación o autorización en este puerto. El kubelet sirve los mismos endpoints en el puerto autenticado y más seguro 10250.

Para obtener más información, consulta Inhabilitar el puerto de solo lectura kubelet en clústeres de GKE.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.disableInsecureKubeletReadOnlyPort restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Control de acceso

En las siguientes secciones se ofrecen recomendaciones para restringir el acceso no autorizado a tu clúster. Los ingenieros de seguridad y los administradores de identidades y cuentas deben aplicar estas recomendaciones para reducir la superficie de ataque y limitar el impacto del acceso no autorizado.

Prácticas recomendadas

Restringir el acceso al descubrimiento de la API de clúster

Recomendación: Restringe el acceso a tu plano de control y a tus nodos desde Internet para evitar el acceso no intencionado a los endpoints de descubrimiento de la API de clúster.

De forma predeterminada, Kubernetes crea clústeres con un conjunto permisivo de roles de descubrimiento de API predeterminados. Estos roles predeterminados dan acceso general a la información sobre las APIs de un clúster a varios grupos predeterminados, como system:authenticated. Estos roles predeterminados no representan un nivel de seguridad significativo para los clústeres de GKE. Por ejemplo, el grupo system:authenticated, que puede leer información sobre APIs como CustomResources, se asigna a cualquier usuario autenticado (incluidos los que tengan una cuenta de Google).

Para restringir el acceso a las APIs de descubrimiento de clústeres, haz lo siguiente:

  • Restringe el acceso al plano de control: usa solo el endpoint basado en DNS para acceder al plano de control. Si usas endpoints basados en IP, restringe el acceso a un conjunto de intervalos de direcciones conocidos configurando redes autorizadas.
  • Configurar nodos privados: inhabilita las direcciones IP externas de tus nodos para que los clientes que no estén en tu red no puedan acceder a ellos.

Para obtener más información, consulta Información sobre el aislamiento de redes.

Si no habilitas estas funciones de aislamiento de red, trata toda la información de descubrimiento de APIs (especialmente el esquema de CustomResources, las definiciones de APIService y la información de descubrimiento alojada en servidores de APIs de extensión) como información pública.

Coloca los equipos y los entornos en espacios de nombres o clústeres independientes

Concede a los equipos acceso con privilegios mínimos a Kubernetes creando espacios de nombres o clústeres independientes para cada equipo y entorno. Asigna centros de costes y etiquetas a cada espacio de nombres o clúster para rendir cuentas y repercutir los costes.

Puedes usar los permisos de IAM y RBAC junto con los espacios de nombres para restringir las interacciones de los usuarios con los recursos del clúster en la Google Cloud consola. Para obtener más información, consulta Habilitar el acceso y ver los recursos del clúster por espacio de nombres.

Aplica el principio de mínimos accesos en las políticas de acceso

Recomendación: concede a los desarrolladores solo el acceso que necesiten para desplegar y gestionar aplicaciones en su espacio de nombres, especialmente en entornos de producción. Cuando diseñes tus políticas de control de acceso, define las tareas que deben realizar los usuarios en el clúster y concédeles solo los permisos que les permitan llevarlas a cabo.

En GKE, puedes usar la gestión de identidades y accesos (IAM) y el control de acceso basado en roles (RBAC) de Kubernetes para conceder permisos en los recursos. Estos mecanismos de control de acceso funcionan conjuntamente. Para reducir la complejidad de gestionar el acceso, haz lo siguiente:

Para obtener más información sobre cómo planificar y diseñar políticas de gestión de identidades y accesos y de control de acceso basado en roles, consulta los siguientes documentos:

Usar Workload Identity Federation para GKE para acceder a las APIs Google Cloud

Recomendación: para acceder a los recursos de Google Cloud desde tus cargas de trabajo de GKE, usa Workload Identity Federation para GKE.

Workload Identity Federation for GKE es la forma recomendada de autenticarse en lasGoogle Cloud APIs. Puedes conceder roles de gestión de identidades y accesos en varios recursos a las cuentas principales de tu clúster, como cuentas de servicio o pods de Kubernetes específicos. Workload Identity Federation for GKE también protege los metadatos sensibles de tus nodos y proporciona un flujo de trabajo de autenticación más seguro que otras alternativas, como los archivos de tokens estáticos.

Workload Identity Federation para GKE siempre está habilitado en los clústeres de Autopilot. En los clústeres estándar, habilita Workload Identity Federation for GKE en todos los clústeres y grupos de nodos. Además, sigue estas recomendaciones:

  • Si usas Google Cloud bibliotecas de cliente en el código de tu aplicación, no distribuyas Google Cloud credenciales a tus cargas de trabajo. El código que usa bibliotecas de cliente obtiene automáticamente las credenciales de Workload Identity Federation for GKE.
  • Usa un espacio de nombres y una cuenta de servicio independientes para cada carga de trabajo que necesite una identidad distinta. Concede permisos de gestión de identidades y accesos a cuentas de servicio específicas.

Para obtener más información, consulta el artículo sobre cómo autenticar APIs de Google Cloud cargas de trabajo de GKE.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableWorkloadIdentityFederation restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Usar grupos para gestionar el acceso

Recomendación: en tus políticas de acceso, concede permisos a grupos de usuarios en lugar de a usuarios concretos.

Cuando gestionas usuarios en grupos, tu sistema de gestión de identidades y los administradores de identidades pueden controlar las identidades de forma centralizada modificando la pertenencia de los usuarios a varios grupos. Con este tipo de gestión, no es necesario actualizar las políticas de RBAC o de IAM cada vez que un usuario específico necesite permisos actualizados.

Puedes especificar Grupos de Google en tus políticas de gestión de identidades y accesos o de control de acceso basado en roles. Para obtener más información, consulte los documentos siguientes:

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableGoogleGroupsRBAC restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Restringir el acceso anónimo a los endpoints del clúster

Recomendación: impide las solicitudes anónimas a todos los endpoints de clústeres, excepto a los endpoints de comprobación de estado, en todos los clústeres Autopilot y Estándar.

De forma predeterminada, Kubernetes asigna el usuario system:anonymous y el grupo system:unauthenticated a las solicitudes anónimas a los endpoints del clúster. Si tus políticas de RBAC conceden permisos adicionales a este usuario o grupo, un usuario anónimo podría poner en peligro la seguridad de un servicio o del propio clúster.

En GKE 1.32.2-gke.1234000 y versiones posteriores, puedes limitar el conjunto de endpoints a los que pueden acceder las solicitudes anónimas a los endpoints de comprobación de estado del servidor de la API de Kubernetes /healthz, /livez y /readyz. Es necesario tener acceso anónimo a estos endpoints de comprobación del estado para verificar que un clúster funciona correctamente.

Para limitar el acceso anónimo a los endpoints de clústeres, especifica LIMITED para la marca --anonymous-authentication-config cuando uses la CLI de gcloud o la API de GKE para crear o actualizar clústeres estándar y Autopilot. GKE rechaza las solicitudes anónimas a los endpoints del clúster que no son los endpoints de comprobación de estado durante la autenticación. Las solicitudes anónimas no llegan a los endpoints, aunque tus políticas de control de acceso basado en roles concedan acceso a usuarios y grupos anónimos. Las solicitudes rechazadas devuelven el estado HTTP 401.

Para aplicar esta recomendación en tu organización, carpeta o proyecto mediante una política de organización, crea una restricción personalizada con la condición resource.anonymousAuthenticationConfig.mode. Para obtener más información y ver un ejemplo de restricción, consulta Restringir acciones en recursos de GKE mediante políticas de organización personalizadas.

No confíe únicamente en esta función para proteger su clúster. Implementa medidas de seguridad adicionales, como las siguientes:

Seguridad de la red de GKE

En las siguientes secciones se ofrecen recomendaciones para mejorar la seguridad de la red en los clústeres. Los administradores de redes y los ingenieros de seguridad deben aplicar estas recomendaciones para proteger las cargas de trabajo y la infraestructura frente a accesos externos o internos no deseados.

Prácticas recomendadas

Restringir el acceso al plano de control

Recomendación: habilita el endpoint basado en DNS para acceder al plano de control e inhabilita todos los endpoints del plano de control basados en IP.

De forma predeterminada, las entidades externas, como los clientes de Internet, pueden acceder a tu plano de control. Puedes restringir quién puede acceder a tu plano de control configurando el aislamiento de la red.

Para aislar tu plano de control, haz una de las siguientes acciones:

  • Usar solo el endpoint basado en DNS (opción recomendada): habilita el endpoint basado en DNS para el plano de control e inhabilita los endpoints basados en IP internos y externos. Todo el acceso al plano de control debe usar el endpoint basado en DNS. Puedes usar Controles de Servicio de VPC para controlar quién puede acceder al endpoint basado en DNS.

    Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableControlPlaneDNSOnlyAccess restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

    Ir a Detalles de la política

  • Inhabilita el endpoint basado en IP externa: elimina la dirección IP externa del plano de control. Los clientes que no estén en tu red VPC no podrán usar la dirección IP externa para acceder al plano de control.

    Esta opción es adecuada si usas tecnologías como Cloud Interconnect y Cloud VPN para conectar la red de tu empresa con tu red de VPC.

  • Usar redes autorizadas con el endpoint basado en IP externa: restringe el acceso al endpoint basado en IP externa solo a un intervalo de direcciones IP de origen de confianza.

    Esta opción es adecuada si no tienes una infraestructura de VPN o si tienes usuarios remotos o sucursales que acceden a tus clústeres a través de la red pública de Internet.

En la mayoría de los casos, solo se debe usar el endpoint basado en DNS para acceder al plano de control. Si tienes que habilitar el endpoint basado en IP, usa redes autorizadas para limitar el acceso al plano de control a las siguientes entidades:

  • Los intervalos de direcciones IP que especifiques.
  • Nodos de GKE en la misma red de VPC que el clúster.
  • Direcciones IP reservadas por Google para gestionar clústeres.

Aísla tus nodos de Internet

De forma predeterminada, todos los nodos de GKE tienen una dirección IP externa a la que pueden acceder los clientes de Internet. Para quitar esta dirección IP externa, habilita los nodos privados.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enablePrivateNodes restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Restringir el tráfico de red entre pods

Recomendación: controla el tráfico de red entre pods mediante NetworkPolicies, una malla de servicios o ambas.

De forma predeterminada, todos los pods de tu clúster pueden comunicarse entre sí. Restringir el acceso a la red entre servicios dificulta mucho que los atacantes se muevan lateralmente en tu clúster. Tus servicios también obtienen cierta protección frente a incidentes de denegación de servicio accidentales o deliberados. En función de tus requisitos, utiliza uno de los siguientes métodos o ambos para restringir el tráfico de pod a pod:

Protección de datos sensibles

En las siguientes secciones se ofrecen recomendaciones para cifrar datos y proteger información sensible, como las credenciales. Los ingenieros de seguridad y los administradores de plataformas deben aplicar estas recomendaciones para reducir el riesgo de acceso no intencionado a datos críticos.

Prácticas recomendadas

Cifrar los datos de carga de trabajo en uso

Usa el cifrado de memoria basado en hardware para proteger los datos que usan tus cargas de trabajo mediante nodos confidenciales de GKE. Puedes elegir una tecnología de computación confidencial en función de tus requisitos. Para obtener más información, consulta el artículo Encriptar datos de cargas de trabajo en uso con nodos confidenciales de GKE.

Almacenar secretos fuera del clúster

Recomendación: usa un gestor de secretos externo, como Secret Manager, para almacenar datos sensibles, como claves de API, fuera de tu clúster.

En Kubernetes, puedes almacenar datos sensibles en secretos de tu clúster. Puedes usar secretos para proporcionar datos confidenciales a las aplicaciones sin incluir esos datos en el código de la aplicación. Sin embargo, almacenar estos datos en tu clúster conlleva riesgos como los siguientes:

  • Cualquier usuario que pueda crear pods en un espacio de nombres puede leer los datos de cualquier secreto de ese espacio de nombres.
  • Cualquier persona con acceso RBAC o de gestión de identidades y accesos para leer todos los objetos de la API de Kubernetes puede leer los secretos.

Debido a estos riesgos, crea secretos en tu clúster solo cuando no puedas proporcionar esos datos a tus cargas de trabajo de ninguna otra forma. Te recomendamos los siguientes métodos, por orden de preferencia, para almacenar y acceder a tus datos sensibles:

  • Bibliotecas de cliente de Secret Manager: accede a los secretos de forma programática desde el código de tu aplicación mediante la API Secret Manager con la federación de identidades de carga de trabajo para GKE. Para obtener más información, consulta el artículo Acceder a secretos almacenados fuera de clústeres de GKE mediante bibliotecas de cliente.
  • Datos de Secret Manager como volúmenes montados: proporciona datos sensibles a tus pods como volúmenes montados mediante el complemento Secret Manager para GKE. Este método es útil si no puedes modificar el código de tu aplicación para usar las bibliotecas de cliente de Secret Manager. Para obtener más información, consulta el artículo sobre cómo usar el complemento Secret Manager con Google Kubernetes Engine.

  • Herramientas de gestión de secretos de terceros: herramientas de terceros como HashiCorp Vault proporcionan funciones de gestión de secretos para cargas de trabajo de Kubernetes. Estas herramientas requieren más configuración inicial que Secret Manager, pero son una opción más segura que crear secretos en el clúster. Para configurar una herramienta de terceros para la gestión de secretos, consulta la documentación del proveedor. Además, ten en cuenta las siguientes recomendaciones:

    • Si la herramienta de terceros se ejecuta en un clúster, usa un clúster diferente al que ejecuta tus cargas de trabajo.
    • Usa Cloud Storage o Spanner para almacenar los datos de la herramienta.
    • Usa un balanceador de carga de red de transferencia interno para exponer la herramienta de gestión de secretos de terceros a los pods que se ejecutan en tu red de VPC.

  • Usar secretos de Kubernetes (no recomendado): si ninguna de las opciones anteriores se adapta a tu caso práctico, puedes almacenar los datos como secretos de Kubernetes. Google Cloud Cifra los datos en la capa de almacenamiento de forma predeterminada. Este cifrado predeterminado de la capa de almacenamiento incluye la base de datos que almacena el estado de tu clúster, que se basa en etcd o Spanner. Además, puedes encriptar estos secretos en la capa de aplicación con una clave que gestiones. Para obtener más información, consulta Encriptar secretos en la capa de aplicación.

Seguridad de las cargas de trabajo

En las siguientes secciones se ofrecen recomendaciones para mejorar la seguridad de tu clúster frente a problemas de cargas de trabajo. Los ingenieros de seguridad y los administradores de plataformas deben aplicar estas recomendaciones para mejorar la protección de la infraestructura de GKE frente a las cargas de trabajo.

Prácticas recomendadas

Aislar cargas de trabajo con GKE Sandbox

Recomendación: usa GKE Sandbox para evitar que el código malicioso afecte al kernel del host en los nodos del clúster.

Puedes ejecutar contenedores en un entorno sandbox para mitigar la mayoría de los ataques de escape de contenedores, también llamados ataques de escalada de privilegios local. Como se describe en los boletines de seguridad de GKE, este tipo de ataque permite que un atacante obtenga acceso a la VM host del contenedor. El atacante puede usar este acceso al host para acceder a otros contenedores de la misma VM. GKE Sandbox puede ayudar a limitar el impacto de estos ataques.

Usa GKE Sandbox en situaciones como las siguientes:

  • Tienes cargas de trabajo que ejecutan código no fiable.
  • Quieres limitar el impacto si un atacante vulnera un contenedor de la carga de trabajo.

Para obtener más información, consulta Endurecer el aislamiento de cargas de trabajo con GKE Sandbox.

Restringe la capacidad de las cargas de trabajo para modificarse a sí mismas

Recomendación: usa controladores de admisión para evitar que las cargas de trabajo se modifiquen a sí mismas o para impedir que se modifiquen atributos de cargas de trabajo arriesgados, como las cuentas de servicio.

Algunas cargas de trabajo de Kubernetes, especialmente las del sistema, tienen permiso para modificarse a sí mismas. Por ejemplo, algunas cargas de trabajo se escalan verticalmente de forma automática. Aunque es una opción cómoda, la automodificación puede permitir que un atacante que ya haya vulnerado un nodo avance en el clúster. Por ejemplo, un atacante podría tener una carga de trabajo en un espacio de nombres que se cambie para ejecutarse como una ServiceAccount con más privilegios en el mismo espacio de nombres.

A menos que sea necesario, no concedas a los pods permiso para modificarse a sí mismos. Si algunos pods deben modificarse automáticamente, usa Policy Controller para limitar lo que pueden cambiar las cargas de trabajo. Por ejemplo, puedes usar la plantilla de restricción NoUpdateServiceAccount para evitar que los pods cambien su ServiceAccount. Cuando crees una política, excluye de tus restricciones los componentes de gestión de clústeres, como en el siguiente ejemplo:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Aplicación obligatoria de la política

En las siguientes secciones se ofrecen recomendaciones para usar políticas con el fin de aplicar restricciones de seguridad en varios recursos. Los administradores de identidades y cuentas, así como los ingenieros de seguridad, deben aplicar estas recomendaciones para mantener el cumplimiento de los clústeres y las cargas de trabajo con los requisitos de seguridad de la organización.

Prácticas recomendadas

Implementar políticas en toda la Google Cloud jerarquía de recursos

Recomendación: para aplicar prácticas de seguridad en tu organización, carpeta o proyecto, usa el servicio de política de organización.

Con la política de organización, puedes definir restricciones de forma centralizada y aplicarlas en varios niveles de tu jerarquía de recursos. Varios Google Cloud productos publican restricciones gestionadas que le permiten aplicar recomendaciones de prácticas recomendadas para ese producto. Por ejemplo, GKE publica restricciones gestionadas para muchas de las prácticas recomendadas que se describen en este documento.

Para obtener más información sobre cómo habilitar la política de organización, consulta el artículo Crear y gestionar políticas de organización.

Aplicar políticas durante la admisión de cargas de trabajo

Recomendación: usa un controlador de admisión como Policy Controller o el controlador de admisión PodSecurity para revisar las solicitudes de API entrantes y aplicar políticas a esas solicitudes.

Los controladores de admisión interceptan las solicitudes autenticadas y autorizadas a la API de Kubernetes para realizar tareas de validación o mutación antes de permitir que un recurso persista en la API.

Puedes usar los siguientes métodos para controlar el acceso en los clústeres de GKE:

Gestión de clústeres

En las siguientes secciones se ofrecen recomendaciones para gestionar los clústeres a lo largo del tiempo, como actualizar, monitorizar y configurar registros. Los ingenieros de seguridad, los administradores de plataformas y los ingenieros de fiabilidad de sitios deben usar estas recomendaciones para mantener la postura de seguridad de la plataforma GKE.

Prácticas recomendadas

Actualiza tu infraestructura de GKE periódicamente

Recomendación: mantén actualizada tu versión de GKE para acceder a nuevas funciones de seguridad y aplicar parches de seguridad. Usa canales de lanzamiento, actualizaciones automáticas de parches aceleradas y actualizaciones automáticas de nodos.

Kubernetes y GKE publican con frecuencia nuevas versiones de parches que incluyen mejoras de seguridad y correcciones de vulnerabilidades. En todos los clústeres, GKE actualiza automáticamente el plano de control a versiones secundarias y de parche más estables.

Para asegurarte de que tu clúster de GKE ejecute una versión actualizada, haz lo siguiente:

  • Registra tus clústeres en un canal de lanzamiento. Los clústeres de Autopilot siempre están registrados en un canal de lanzamiento.
  • En los clústeres que estén en un canal de lanzamiento, habilita las actualizaciones automáticas de parches aceleradas para obtener las versiones de parches de seguridad en cuanto estén disponibles en tu canal de lanzamiento.
  • En los clústeres estándar que no estén en un canal de lanzamiento, habilita las actualizaciones automáticas de nodos. La actualización automática de nodos está habilitada de forma predeterminada en los clústeres creados con laGoogle Cloud consola desde junio del 2019 y en los clústeres creados con la API de GKE a partir del 11 de noviembre del 2019.
  • Si usas políticas de mantenimiento, utiliza una ventana de mantenimiento para permitir que GKE actualice automáticamente tus nodos al menos una vez al mes.
  • En los grupos de nodos que no usen la actualización automática de nodos, actualiza los grupos de nodos al menos una vez al mes según tu propia programación.
  • Consulta los boletines de seguridad de GKE y las notas de las versiones de GKE para obtener información sobre los parches de seguridad.

Habilitar las notificaciones de boletines de seguridad

Recomendado: configura las notificaciones de los nuevos boletines de seguridad que afecten a tu clúster.

Cuando hay disponibles boletines de seguridad relevantes para tu clúster, GKE publica notificaciones sobre esos eventos como mensajes en temas de Pub/Sub que configures. Puedes recibirlas en una suscripción de Pub/Sub, integrarte con servicios de terceros y recibir notificaciones en Cloud Logging.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableSecurityBulletinNotifications restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Configurar la recogida de registros

Recomendación: para reducir la sobrecarga operativa y mantener una vista consolidada de los registros, implementa una estrategia de registro coherente en todos los clústeres. No inhabilite la recogida de registros en sus clústeres estándar.

Los clústeres de GKE envían registros específicos a Google Cloud Observability. También puede configurar la recogida de otros tipos de registros. Además de los registros del sistema y de las cargas de trabajo, todos los clústeres de GKE envían los siguientes registros de auditoría a Logging:

  • Registros de auditoría de Kubernetes: un registro cronológico de las llamadas que se han realizado al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles para investigar solicitudes de API sospechosas, recoger estadísticas o crear alertas de monitorización para llamadas a APIs no deseadas.
  • Registros de auditoría de GKE: un registro de las actividades administrativas y de acceso de la API de GKE.

Para obtener más información, consulte los documentos siguientes:

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.enableCloudLogging restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Monitorizar tus recursos para detectar problemas de seguridad

Usa el panel de control de postura de seguridad de GKE y Security Command Center para monitorizar tus clústeres y cargas de trabajo en busca de posibles problemas. Puedes usar estos servicios para comprobar si hay vulnerabilidades, amenazas y boletines de seguridad activos que afecten a tu infraestructura de GKE.

Configuraciones de seguridad predeterminadas

En las siguientes secciones se describen las opciones que se configuran de forma predeterminada en los clústeres nuevos para mitigar problemas de seguridad específicos, como vulnerabilidades o riesgos. Los ingenieros de seguridad y los administradores de plataformas deben validar que los clústeres existentes usen estos ajustes.

Prácticas recomendadas

Dejar inhabilitados los métodos de autenticación de cliente antiguos

Recomendación: inhabilita los métodos de autenticación del servidor de APIs antiguos, como los certificados estáticos y las contraseñas.

Hay varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son tokens de portador de cuenta de servicio, tokens de OAuth y certificados de cliente X.509. La CLI de gcloud usa tokens de OAuth para autenticar a los usuarios de GKE.

Los métodos de autenticación antiguos, como las contraseñas estáticas, están inhabilitados porque aumentan la superficie de ataque de las vulneraciones de clústeres. En los clústeres Autopilot, no puedes habilitar ni usar estos métodos de autenticación.

Utiliza uno de los siguientes métodos para autenticarte en el servidor de la API de Kubernetes:

  • Usuarios: usa la CLI de gcloud para permitir que GKE autentique a los usuarios, genere tokens de acceso de OAuth para el clúster y mantenga los tokens actualizados.
  • Aplicaciones: usa la federación de identidades de cargas de trabajo para que las aplicaciones deGoogle Cloud u otros entornos se autentiquen en tu clúster.

Para obtener más información sobre cómo autenticar y cómo inhabilitar los métodos de autenticación antiguos, consulta el artículo Autenticar en el servidor de la API de Kubernetes.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.disableLegacyClientCertificateIssuance restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Dejar ABAC inhabilitado

Recomendación: usa IAM y RBAC para controlar el acceso en GKE. No habilites el control de acceso basado en atributos (ABAC).

ABAC es un método de autorización antiguo que está inhabilitado de forma predeterminada en todos los clústeres de GKE y no se puede habilitar en los clústeres de Autopilot.

Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.disableABAC restricción de política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Dejar habilitado el controlador de admisión DenyServiceExternalIPs

Recomendación: no inhabilite el controlador de admisión DenyServiceExternalIPs.

Este controlador de admisión impide que los servicios usen ExternalIPs y mitiga GCP-2020-015. Este controlador de admisión está habilitado de forma predeterminada en los clústeres creados en GKE 1.21 y versiones posteriores. En los clústeres que se crearon originalmente en una versión anterior de GKE, habilita el controlador de admisión:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Para aplicar esta recomendación en tu organización, usa la constraints/container.managed.denyServiceExternalIPs restricción de la política de organización gestionada. Para revisar esta restricción gestionada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Siguientes pasos