Endurecer la seguridad del clúster

En este documento, se proporcionan prácticas recomendadas para mejorar la seguridad de tus entornos de Google Kubernetes Engine (GKE). Los especialistas en seguridad que definen, administran y aplican 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 clústeres nuevos de GKE implementan muchas de las prácticas recomendadas de este documento de forma predeterminada. Los clústeres en modo Autopilot tienen una postura de seguridad predeterminada más estricta que los clústeres en modo Standard.

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

  • Security Command Center: Verifica automáticamente si tus clústeres implementan muchas de estas prácticas recomendadas y comprueba si hay otras configuraciones incorrectas comunes.
  • Servicio de políticas de la organización: Aplica prácticas recomendadas específicas en los recursos de GKE de una organización, carpeta o proyecto. En este documento, se incluyen vínculos a secciones específicas de la consola de Google Cloud para que puedas aplicar restricciones administradas a esas recomendaciones.

Google Cloud diseño de entorno

En las siguientes secciones, se describen las medidas de seguridad que debes tener en cuenta cuando planifiques y diseñes tus recursos en Google Cloud. Los arquitectos de Cloud deben usar estas recomendaciones cuando planifiquen y definan la Google Cloud arquitectura.

Prácticas recomendadas

Planifica la estructura de tus Google Cloud recursos

Recomendado: Implementa el plano de bases empresariales, que es una base completa para tu entorno empresarial basada en nuestras prácticas recomendadas.

La arquitectura de tus organizaciones, carpetas y proyectos de Google Cloud afecta tu postura de seguridad. Diseña estos recursos fundamentales de manera que permitan controles de administración y seguridad a gran escala en todos tus servicios.

Planifica entornos multiusuario

Recomendado: Implementa Google Cloud y las prácticas recomendadas de GKE para plataformas empresariales multiusuario.

Muchos clientes de GKE administran equipos distribuidos, con flujos de trabajo y responsabilidades de ingeniería independientes. Estos entornos multiusuario deben tener una infraestructura compartida que todos tus desarrolladores puedan usar, a la vez que se restringe el acceso a los componentes según los roles y las responsabilidades. El plano de la aplicación empresarial se basa en el plano de bases empresariales para ayudarte a implementar plataformas internas para desarrolladores en entornos multiusuario.

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

Usa etiquetas para agrupar Google Cloud recursos

Recomendación: Usa etiquetas para organizar los recursos de GKE y aplicar políticas de forma condicional, además de mejorar la responsabilidad en tus equipos.

Las etiquetas son metadatos que puedes adjuntar a los recursos de tus organizaciones, carpetas y proyectos para identificar las dimensiones comerciales en tuGoogle Cloud jerarquía de recursos. Puedes adjuntar etiquetas a los clústeres y grupos de nodos de GKE y, luego, usar esas etiquetas para aplicar de forma condicional políticas de la organización, políticas de IAM o políticas de firewall.

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

Planifica tus redes de VPC

Recomendado: Implementa Google Cloud y las prácticas recomendadas de GKE para el diseño de redes de VPC.

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

Diseña un plan de respuesta ante incidentes

Recomendación: Crea y mantén un plan de respuesta ante incidentes que cumpla con tus objetivos de seguridad y confiabilidad.

Los incidentes de seguridad pueden ocurrir incluso cuando implementas todos los controles de seguridad posibles. Un plan de respuesta ante incidentes te ayuda a identificar posibles brechas en tus controles de seguridad, responder con rapidez y eficacia a diversos tipos de incidentes y 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 siguientes secciones, se proporcionan recomendaciones de seguridad para tus redes de VPC. Los arquitectos y administradores de redes deben aplicar estas recomendaciones para reducir la superficie de ataque a nivel de la red y limitar el impacto del acceso no deseado a la red.

Prácticas recomendadas

Usa reglas de firewall de privilegio mínimo

Recomendado: Cuando crees reglas de firewall, usa el principio de privilegio mínimo para proporcionar acceso solo para el propósito requerido. Asegúrate de que tus reglas de firewall no entren en conflicto con las reglas de firewall predeterminadas de GKE ni las anulen cuando sea posible.

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

Usa la VPC compartida para el tráfico entre proyectos

Recomendado: Usa la VPC compartida para permitir que los recursos de varios proyectos se comuniquen entre sí a través de direcciones IP internas.

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

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

Usa redes independientes para aislar los entornos

Recomendación: Usa redes de VPC compartida separadas para los entornos de producción, prueba y etapa de pruebas.

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

Configuración de seguridad inmutable

En las siguientes secciones, se proporcionan recomendaciones de seguridad que solo puedes configurar cuando creas clústeres o grupos de nodos. No puedes actualizar clústeres o grupos de nodos existentes para cambiar estos parámetros de configuración. Los administradores de la plataforma deben aplicar estas recomendaciones a los clústeres y grupos de nodos nuevos.

Usa cuentas de servicio de nodo de IAM con privilegios mínimos

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

GKE usa cuentas de servicio de IAM adjuntas a tus nodos para ejecutar tareas del sistema, como el registro y la supervisión. Como mínimo, estas cuentas de servicio de nodo deben tener el rol de cuenta de servicio de nodo predeterminado 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 la cuenta de servicio del nodo.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones en 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 para cargas de trabajo del sistema que realicen tareas como el registro y la supervisión. Para tus propias cargas de trabajo, aprovisiona identidades con la federación de identidades para cargas de trabajo para GKE.

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

Ir a Detalles de la política

Usa una imagen de nodo de Container-Optimized OS

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

Container-Optimized OS se creó, optimizó y reforzó específicamente para ejecutar contenedores. Container-Optimized OS es la única imagen de nodo compatible con el modo de Autopilot y es la imagen de nodo predeterminada para el modo estándar.

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

Configuración de seguridad de nodos

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

Prácticas recomendadas

Usar nodos de GKE protegidos

Recomendación: Habilita los nodos de GKE protegidos, el inicio seguro y la supervisión de integridad en todos los clústeres y grupos de nodos.

Los nodos de GKE protegidos proporcionan verificaciones de identidad y de integridad verificables que mejoran la seguridad de tus nodos. Los nodos de GKE protegidos y las funciones como la supervisión de integridad de nodos y el inicio seguro siempre están habilitados en los clústeres de Autopilot. En los clústeres de Standard, haz lo siguiente:

  • No inhabilite los nodos de GKE protegidos en sus clústeres.
  • Habilita el inicio seguro en todos tus grupos de nodos.
  • No inhabilite la supervisión de integridad en sus grupos de nodos.

Para obtener más información sobre cómo habilitar estas funciones, consulta Usa nodos de GKE protegidos.

Para aplicar esta recomendación en tu organización, usa la restricción de política de la organización administrada constraints/container.managed.enableShieldedNodes. Para revisar esta restricción administrada 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 puerto de solo lectura no seguro de kubelet

Recomendación: Inhabilita el puerto de solo lectura kubelet y cambia las cargas de trabajo que usan el puerto 10255 para usar el puerto más seguro 10250 en su lugar.

El proceso de kubelet que se ejecuta en los nodos entrega una API de solo lectura que usa el puerto no seguro 10255. Kubernetes no realiza ninguna verificación de autenticación ni de autorización en este puerto. El kubelet entrega los mismos extremos en el puerto 10250 autenticado y más seguro.

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

Para aplicar esta recomendación en tu organización, usa la restricción de política de la organización administrada constraints/container.managed.disableInsecureKubeletReadOnlyPort. Para revisar esta restricción administrada 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 proporcionan 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

Restringe el acceso al descubrimiento de API del clúster

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

De forma predeterminada, Kubernetes crea clústeres con un conjunto de permisos de roles de descubrimiento de API predeterminados. Estos roles predeterminados brindan un amplio acceso 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 significativo de seguridad 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 (incluido cualquier usuario con una Cuenta de Google).

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

  • Restringe el acceso al plano de control: Usa solo el extremo basado en DNS para acceder al plano de control. Si usas extremos basados en IP, configura redes autorizadas para restringir el acceso a un conjunto de rangos de direcciones conocidos.
  • Configura nodos privados: Inhabilita las direcciones IP externas de tus nodos para que los clientes fuera de tu red no puedan acceder a ellos.

Para obtener más información, consulta Acerca del aislamiento de red.

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

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

Brinda a los equipos el acceso a Kubernetes de privilegios mínimos a través de la creación de espacios de nombres o clústeres separados para cada equipo y entorno. Para cada espacio de nombres o clúster, asigna centros de costos y etiquetas para la rendición de cuentas y la devolución del cargo.

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

Usa el principio de privilegio mínimo en las políticas de acceso

Recomendación: Otorga a los desarrolladores solo el acceso que necesitan para implementar y administrar aplicaciones en su espacio de nombres, en especial en los entornos de producción. Cuando diseñes tus políticas de control de acceso, asigna las tareas que tus usuarios deben realizar en el clúster y otórgales solo los permisos que les permitan realizar esas tareas.

En GKE, puedes usar IAM y el control de acceso basado en roles (RBAC) de Kubernetes para otorgar permisos sobre los recursos. Estos mecanismos de control de acceso funcionan en conjunto. Para reducir la complejidad de la administración del acceso, haz lo siguiente:

  • Para otorgar acceso a tu proyecto o a los recursos de Google Cloud , usa los roles de IAM.

  • Para otorgar acceso a los recursos de Kubernetes en tu clúster, como los espacios de nombres, usa el RBAC.

Para obtener más información sobre la planificación y el diseño de políticas de IAM y RBAC, consulta los siguientes documentos:

Usa la federación de identidades para cargas de trabajo para GKE para acceder a las APIs de Google Cloud

Recomendado: Para acceder a los recursos de tus cargas de trabajo de GKE, usa la federación de identidades para cargas de trabajo para GKE. Google Cloud

La federación de identidades para cargas de trabajo para GKE es la forma recomendada de autenticarse en las APIs deGoogle Cloud . Puedes otorgar roles de IAM en varios recursos a las entidades principales de tu clúster, como ServiceAccounts o Pods específicos de Kubernetes. La federación de identidades para cargas de trabajo para GKE también protege los metadatos sensibles en tus nodos y proporciona un flujo de trabajo de autenticación más seguro que las alternativas, como los archivos de tokens estáticos.

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, habilita la federación de identidades para cargas de trabajo para GKE en todos los clústeres y grupos de nodos. Además, sigue estas recomendaciones:

  • Si usas bibliotecas cliente de Google Cloud en el código de tu aplicación, no distribuyas credenciales de Google Cloud a tus cargas de trabajo. El código que usa bibliotecas cliente recupera automáticamente las credenciales para la federación de identidades para cargas de trabajo para GKE.
  • Usa un espacio de nombres y una ServiceAccount independientes para cada carga de trabajo que necesite una identidad distinta. Otorga permisos de IAM a cuentas de servicio específicas.

Para obtener más información, consulta Autenticación en las APIs de Google Cloud desde cargas de trabajo de GKE.

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

Ir a Detalles de la política

Usa grupos para administrar el acceso

Recomendación: En tus políticas de acceso, otorga permisos a grupos de usuarios en lugar de a personas.

Cuando administras usuarios en grupos, tu sistema de administración de identidades y los administradores de identidades pueden controlar las identidades de forma centralizada modificando la membresía de los usuarios en varios grupos. Este tipo de administración anula la necesidad de actualizar tus políticas de RBAC o IAM cada vez que un usuario específico necesita permisos actualizados.

Puedes especificar Grupos de Google en tus políticas de IAM o RBAC. Para obtener más información, consulta los siguientes documentos:

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

Ir a Detalles de la política

Restringe el acceso anónimo a los extremos del clúster

Recomendado: Evita las solicitudes anónimas a todos los extremos del clúster, excepto a los extremos de verificación de estado, en todos los clústeres de Autopilot y Standard.

De forma predeterminada, Kubernetes asigna el usuario system:anonymous y el grupo system:unauthenticated a las solicitudes anónimas a los extremos del clúster. Si tus políticas de RBAC otorgan permisos adicionales a este usuario o grupo, es posible que un usuario anónimo pueda comprometer la seguridad de un servicio o del clúster en sí.

En la versión 1.32.2-gke.1234000 y versiones posteriores de GKE, puedes limitar el conjunto de extremos a los que pueden llegar las solicitudes anónimas solo a los extremos de verificación de estado del servidor de la API de Kubernetes /healthz, /livez y /readyz. Se requiere acceso anónimo a estos extremos de verificación de estado para verificar que un clúster funcione correctamente.

Para limitar el acceso anónimo a los extremos del clúster, especifica LIMITED para la marca --anonymous-authentication-config cuando uses gcloud CLI o la API de GKE para crear o actualizar clústeres estándar y de Autopilot. Durante la autenticación, GKE rechaza las solicitudes anónimas a los extremos del clúster que no son los extremos de verificación de estado. Las solicitudes anónimas no llegan a los extremos, incluso si tus políticas de RBAC otorgan acceso a usuarios y grupos anónimos. Las solicitudes rechazadas devuelven un estado HTTP de 401.

Para aplicar esta recomendación en tu organización, carpeta o proyecto con una política de la 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 Restringe acciones en los recursos de GKE con políticas de la organización personalizadas.

No confíes solo en esta capacidad para proteger tu clúster. Implementa medidas de seguridad adicionales, como las siguientes:

Seguridad de red de GKE

En las siguientes secciones, se proporcionan recomendaciones para mejorar la seguridad de red en tus clústeres. Los administradores de redes y los ingenieros de seguridad deben aplicar estas recomendaciones para proteger las cargas de trabajo y la infraestructura del acceso externo o interno no deseado.

Prácticas recomendadas

Restringe el acceso al plano de control

Recomendado: Habilita el extremo basado en DNS para el acceso al plano de control y deshabilita todos los extremos del plano de control basados en IP.

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

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

  • Usa solo el extremo basado en DNS (recomendado): Habilita el extremo basado en DNS para el plano de control y, luego, inhabilita los extremos internos y externos basados en IP. Todo el acceso al plano de control debe usar el extremo basado en DNS. Puedes usar los Controles del servicio de VPC para controlar quién puede acceder al extremo basado en DNS.

    Para aplicar esta recomendación en tu organización, usa la restricción de política de la organización administrada constraints/container.managed.enableControlPlaneDNSOnlyAccess. Para revisar esta restricción administrada 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 extremo basado en IP externa: Quita la dirección IP externa del plano de control. Los clientes que se encuentran fuera de tu red de VPC no pueden usar la dirección IP externa para acceder al plano de control.

    Esta opción funciona bien si usas tecnologías como Cloud Interconnect y Cloud VPN para conectar la red de tu empresa a tu red de VPC.

  • Usa redes autorizadas con el extremo basado en IP externa: Restringe el acceso al extremo basado en IP externa solo a un rango de direcciones IP de origen de confianza.

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

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

  • Los rangos de direcciones IP que especifiques
  • Nodos de GKE en la misma red de VPC que el clúster
  • Direcciones IP reservadas por Google para fines de administración del clúster.

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 en Internet. Para quitar esta dirección IP externa, habilita los nodos privados.

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

Ir a Detalles de la política

Restringe el tráfico de red entre Pods

Recomendación: Controla el tráfico de red de Pod a Pod con NetworkPolicies, una malla de servicios o ambos.

De forma predeterminada, todos los Pods de tu clúster pueden comunicarse entre sí. Restringir el acceso de red entre los servicios hace que sea mucho más difícil para los atacantes moverse lateralmente en tu clúster. Tus servicios también obtienen cierta protección contra incidentes de denegación de servicio accidentales o deliberados. Según tus requisitos, usa 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 proporcionan recomendaciones para encriptar datos y proteger información sensible, como credenciales. Los ingenieros de seguridad y los administradores de la plataforma deben aplicar estas recomendaciones para reducir el riesgo de acceso no intencional a los datos críticos.

Prácticas recomendadas

Encripta los datos en uso de cargas de trabajo

Usa la encriptación de memoria basada en hardware para proteger los datos que usan tus cargas de trabajo con Confidential GKE Nodes. Puedes elegir una tecnología de Confidential Computing según tus requisitos. Para obtener más información, consulta Encripta los datos de cargas de trabajo en uso con Confidential GKE Nodes.

Almacena los Secrets fuera del clúster

Recomendación: Usa un administrador 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 Secrets en 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 persona que pueda crear Pods en un espacio de nombres puede leer los datos de cualquier Secret en ese espacio de nombres.
  • Cualquier persona con acceso de RBAC o IAM para leer todos los objetos de la API de Kubernetes puede leer Secrets.

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

  • Bibliotecas cliente de Secret Manager: Accede a los secretos de forma programática desde el código de tu aplicación con la API de Secret Manager y la federación de identidades para cargas de trabajo de GKE. Para obtener más información, consulta Accede a los objetos Secret almacenados fuera de los clústeres de GKE con bibliotecas cliente.
  • Datos de Secret Manager como volúmenes activados: Proporciona datos sensibles a tus Pods como volúmenes activados con el complemento de Secret Manager para GKE. Este método es útil si no puedes modificar el código de tu aplicación para usar las bibliotecas cliente de Secret Manager. Para obtener más información, consulta Usa el complemento de Secret Manager con Google Kubernetes Engine.

  • Herramientas de administración de secretos de terceros: Las herramientas de terceros, como HashiCorp Vault, proporcionan capacidades de administración de secretos para las 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 administració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 del que ejecuta tus cargas de trabajo.
    • Usar Cloud Storage o Spanner para almacenar los datos de la herramienta
    • Usa un balanceador de cargas de red de transferencia interno para exponer la herramienta de administración de secretos de terceros a los Pods que se ejecutan en tu red de VPC.

  • Usar Secrets de Kubernetes (no recomendado): Si ninguna de las opciones anteriores es adecuada para tu caso de uso, puedes almacenar los datos como Secrets de Kubernetes. Google Cloud Encripta los datos en la capa de almacenamiento de forma predeterminada. Esta encriptación predeterminada 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 objetos Secret en la capa de la aplicación con una clave que administres. Para obtener más información, consulta Encripta Secrets en la capa de la aplicación.

Seguridad de las cargas de trabajo

En las siguientes secciones, se proporcionan recomendaciones para mejorar la seguridad de tu clúster contra problemas de carga 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 contra las cargas de trabajo.

Prácticas recomendadas

Aísla cargas de trabajo con GKE Sandbox

Recomendado: Usa GKE Sandbox para evitar que el código malicioso afecte el kernel del host en los nodos de clústeres.

Puedes ejecutar contenedores en un entorno de zona de pruebas para mitigar la mayoría de los ataques de escape de contenedores, también llamados ataques de elevación de privilegios locales. 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 en 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 confiable.
  • Deseas limitar el impacto si un atacante compromete un contenedor en la carga de trabajo.

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

Restringe la capacidad de las cargas de trabajo de realizar modificaciones automáticas

Recomendación: Usa controladores de admisión para evitar que las cargas de trabajo se modifiquen por sí solas o para evitar la modificación de atributos de carga de trabajo riesgosos, como ServiceAccounts.

Algunas cargas de trabajo de Kubernetes, en especial las del sistema, tienen permiso para realizar modificaciones automáticas. Por ejemplo, algunas cargas de trabajo se escalan automáticamente. Si bien es conveniente, la modificación automática puede permitir que un atacante que ya haya vulnerado un nodo pueda escalar más a fondo en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo en un espacio de nombres se modifique a sí misma para ejecutarse como una cuenta de servicio con más privilegios en el mismo espacio de nombres.

A menos que sea necesario, no les otorgues a los Pods permiso para modificarse a sí mismos. Si algunos Pods deben modificarse por sí mismos, usa el Controlador de políticas 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 cualquier componente de administración de clústeres de tus restricciones, como en el siguiente ejemplo:

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

Aplicación basada en políticas

En las siguientes secciones, se proporcionan recomendaciones para usar políticas y aplicar restricciones de seguridad en varios recursos. Los administradores de identidades y cuentas, y 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

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

Recomendación: Para aplicar prácticas de seguridad en tu organización, carpeta o proyecto, usa el Servicio de políticas de la organización.

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

Para obtener más información sobre cómo habilitar la política de la organización, consulta Crea y administra políticas de la organización.

Aplica 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 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 el control de admisión en clústeres de GKE:

Administración de clústeres

En las siguientes secciones, se proporcionan recomendaciones para administrar tus clústeres con el tiempo, como la actualización, la supervisión y la configuración de registros. Los ingenieros de seguridad, los administradores de plataformas y los SRE deben usar estas recomendaciones para mantener la postura de seguridad de la plataforma de GKE.

Prácticas recomendadas

Actualiza tu infraestructura de GKE con regularidad

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

Kubernetes y GKE lanzan con frecuencia nuevas versiones de parche 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 parches más estables.

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

  • Inscribe tus clústeres en un canal de versiones. Los clústeres de Autopilot siempre se inscriben en un canal de versiones.
  • En el caso de los clústeres que se encuentran en un canal de versiones, 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 versiones.
  • Para los clústeres estándar que no están en un canal de versiones, habilita las actualizaciones automáticas de nodos. La actualización automática de nodos está habilitada de forma predeterminada para los clústeres creados con laGoogle Cloud consola desde junio de 2019 y para los clústeres creados con la API de GKE a partir del 11 de noviembre de 2019.
  • Si usas políticas de mantenimiento, usa un período de mantenimiento para permitir que GKE actualice automáticamente tus nodos al menos una vez al mes.
  • En el caso de los grupos de nodos que no usan actualizaciones automáticas de nodos, actualízalos al menos una vez al mes según tu propio programa.
  • Realiza un seguimiento de los boletines de seguridad de GKE y las notas de la versión de GKE para obtener información sobre los parches de seguridad.

Habilita las notificaciones del boletín de seguridad

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

Cuando hay boletines de seguridad disponibles que son relevantes para el clúster, GKE publica notificaciones sobre esos eventos como mensajes en los temas de Pub/Sub que configuras. Puedes recibir estas notificaciones en una suscripción de Pub/Sub, integrarlas a servicios de terceros y recibir notificaciones en Cloud Logging.

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

Ir a Detalles de la política

Configura la recopilación de registros

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

Los clústeres de GKE envían registros específicos a Google Cloud Observability. De forma opcional, puedes configurar la recopilación de tipos de registros adicionales. Además de los registros del sistema y de la carga 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 realizaron al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles a fin de investigar solicitudes sospechosas a la API, recopilar estadísticas o crear alertas de supervisión para llamadas no deseadas a la API.
  • Registros de auditoría de GKE: Un registro de las actividades administrativas y de acceso para la API de GKE.

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

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

Ir a Detalles de la política

Supervisa tus recursos para detectar problemas de seguridad

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

Parámetros de configuración de seguridad predeterminados

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 la plataforma deben validar que los clústeres existentes usen estos parámetros de configuración.

Prácticas recomendadas

Deja los métodos de autenticación de clientes heredados inhabilitados

Recomendación: Inhabilita los métodos de autenticación del servidor de la API heredada, como los certificados estáticos y las contraseñas.

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

Se inhabilitan los métodos de autenticación heredados, como las contraseñas estáticas, ya que aumentan la superficie de ataque para el compromiso del clúster. En los clústeres de Autopilot, no puedes habilitar ni usar estos métodos de autenticación.

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

  • Usuarios: Usa gcloud CLI 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 para cargas de trabajo para permitir que las aplicaciones enGoogle Cloud o en otros entornos se autentiquen en tu clúster.

Para obtener más información sobre cómo autenticarse y cómo inhabilitar los métodos de autenticación heredados, consulta Autentícate en el servidor de la API de Kubernetes.

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

Ir a Detalles de la política

Deja ABAC inhabilitado

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

El ABAC es un método de autorización heredado 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 restricción de política de la organización administrada constraints/container.managed.disableABAC. Para revisar esta restricción administrada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

Deja 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 ExternalIP y mitiga GCP-2020-015. Este controlador de admisión está habilitado de forma predeterminada en los clústeres que se crearon en la versión 1.21 de GKE y versiones posteriores. Para 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 restricción de política de la organización administrada constraints/container.managed.denyServiceExternalIPs. Para revisar esta restricción administrada en la consola de Google Cloud , ve a la página Detalles de la política.

Ir a Detalles de la política

¿Qué sigue?