Capacidades de seguridad de Autopilot de GKE

En esta página, se describen las funciones y los parámetros de configuración de seguridad en Autopilot de Google Kubernetes Engine (GKE), que es la forma recomendada para ejecutar GKE.

¿Quién debería usar esta página?

Esta página está dirigida a administradores de seguridad que desean comprender las restricciones de seguridad que Google aplica específicamente a los clústeres de Autopilot y las funciones de seguridad que están disponibles para su uso en Autopilot.

También debes leer la descripción general de la seguridad de GKE, que describe las opciones de endurecimiento, las medidas y las recomendaciones que se aplican a todos los clústeres de GKE, las opciones de configuración de red y las cargas de trabajo.

Medidas de seguridad en Autopilot

Los clústeres de Autopilot habilitan y aplican las prácticas recomendadas y la configuración de seguridad de forma predeterminada, incluidas muchas de las recomendaciones en la descripción general de seguridad y en Endurece la seguridad del clúster.

Si deseas obtener recursos recomendados según tu caso de uso, ve a Recursos de seguridad por caso de uso. En las siguientes secciones, se describen las políticas de seguridad que Autopilot aplica por ti.

Autopilot y los estándares de seguridad de Pods de Kubernetes

El proyecto de Kubernetes tiene un conjunto de lineamientos de seguridad llamados estándares de seguridad de Pods que definen las siguientes políticas:

  • Privada: No hay restricciones de acceso. No se usa en Autopilot.
  • Baseline: Evita las rutas de elevación de privilegios conocidos. Permite que la mayoría de las cargas de trabajo se ejecuten sin cambios significativos.
  • Restringido: El nivel de seguridad más alto. Requiere cambios significativos en la mayoría de las cargas de trabajo.

Autopilot aplica la política de modelo de referencia con algunas modificaciones para la usabilidad. Autopilot también aplica muchas restricciones de la política restringida, pero evita las restricciones que bloquearían la ejecución de la mayoría de tus cargas de trabajo. Autopilot aplica estas restricciones a nivel de clúster mediante un controlador de admisión que Google controla. Si necesitas aplicar restricciones adicionales para cumplir con la política restringida completa, puedes usar el controlador de admisión PodSecurity en espacios de nombres específicos.

En la siguiente tabla, se describe cómo los clústeres de Autopilot implementan las políticas restringidas y de referencia. Para obtener descripciones de cada control de esta tabla, consulta la entrada correspondiente en Estándares de seguridad de Pods.

Cuando evaluamos el cumplimiento, consideramos cómo se aplican las restricciones a tus propias cargas de trabajo. Esto excluye las cargas de trabajo verificadas de Google Cloud Partner y las cargas de trabajo del sistema que requieren privilegios específicos para funcionar.

Control Cumplimiento de políticas de modelo de referencia Cumplimiento de políticas restringidas Información adicional
HostProcess Autopilot bloquea HostProcess.
Espacios de nombres de host Autopilot bloquea los espacios de nombres del host. Algunos contenedores de socios verificados pueden usar espacios de nombres de host.
Contenedores privilegiados Autopilot bloquea los contenedores privilegiados de forma predeterminada. Autopilot permite la creación de contenedores privilegiados de socios verificados para fines como la ejecución de herramientas de seguridad y supervisión.
Funciones de Linux

Las cargas de trabajo de Autopilot solo pueden acceder a las capacidades especificadas en el estándar de seguridad de Pods de referencia de forma predeterminada.

Puedes habilitar manualmente las siguientes funciones:

  • NET_RAW para ping y SYS_PTRACE para la depuración: agrega a SecurityContextContext de Pod
  • NET_ADMIN para mallas de servicios, como Istio: especifica --workload-policies=allow-net-admin en el comando de creación del clúster. Disponible en los clústeres existentes nuevos y actualizados que ejecutan la versión 1.27 y versiones posteriores de GKE.

Autopilot también permite que algunas cargas de trabajo de socios verificadas establezcan funciones descartadas.
Volúmenes de HostPath Cumple de forma parcial Cumple de forma parcial Autopilot permite que los contenedores soliciten acceso de solo lectura a /var/log para la depuración, pero rechaza todos los demás acceso de lectura o escritura.
HostPorts No se permiten configurar puertos de host específicos, lo que mitiga algunos problemas de programación y evita la exposición accidental o deliberada de los servicios de red. Puedes configurar de forma manual la asignación de puertos de host aleatoria desde un rango conocido para admitir aplicaciones de red de conexión directa, como servidores de juegos.
AppArmor El perfil de seguridad predeterminado de Docker de AppArmor se aplica de forma automática a Container-Optimized OS.
SELinux No se aplicó SELinux porque ya se aplicó AppArmor. SELinux tampoco es obligatorio en los estándares de seguridad de Pods.
Tipo de activación /proc GKE no establece la marca de función ProcMountType. Si el securityContext del Pod establece procMount en “Sin enmascarar”, GKE lo anula de forma automática con “Predeterminado”.
perfil de seccomp Autopilot aplica el perfil de seccomp RuntimeDefault a todas las cargas de trabajo. Puedes anular esta configuración de forma manual para cargas de trabajo específicas si configuras el perfil como Unconfined en la especificación del Pod.
sysctls GKE no establece la marca de kubelet --allowed-unsafe-sysctls para que los Pods con sysctls no seguros no puedan programarse. Para obtener protección adicional, a partir del 11 de julio de 2023, los nuevos clústeres de 1.27+ tienen una regla de política para aplicar la configuración de securityContext y rechazar los Pods que usan sysctls no seguras.
Tipos de volúmenes Autopilot solo permite los tipos de volumen en la política restringida con las siguientes adiciones: volúmenes de HostPath con acceso de solo lectura a /var/log para depuración, volúmenes persistentes de gcePersistentDisk para Compute Engine y nfs para volúmenes del sistema de archivos de red.
Elevación de privilegios Esta configuración solo proporciona protección a los contenedores que no se ejecutan como raíz. Las encuestas del sector muestran que el 76% de los contenedores se ejecutan como raíz, por lo que Autopilot permite la ejecución como raíz para habilitar la mayoría de las cargas de trabajo. Actualmente, esta configuración también es útil en el caso de quitar privilegios a cargas de trabajo que no son de raíz, ya que permite el uso de capacidades de sistema de archivos para evitar deficiencias con el manejo de capacidades raíz de Kubernetes.
Ejecutar como no raíz Las encuestas del sector muestran que el 76% de los contenedores se ejecutan como raíz, por lo que Autopilot permite la ejecución como raíz para habilitar la mayoría de las cargas de trabajo.
Ejecutar como usuario no raíz Los contenedores pueden establecer runAsUser en 0. Las encuestas del sector muestran que el 76% de los contenedores se ejecutan como raíz, por lo que Autopilot permite la ejecución como raíz para habilitar la mayoría de las cargas de trabajo.

Opciones de configuración de seguridad integradas

Google aplica muchas configuraciones de seguridad integradas a los clústeres de Autopilot según las prácticas recomendadas de la industria y nuestra experiencia. En la siguiente tabla, se describen algunas de las configuraciones de seguridad que Autopilot aplica para ti:

Configuración Descripción
Opciones del anfitrión
Funciones de Linux

Puedes usar las siguientes capacidades de Linux:


"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

También puedes habilitar manualmente las siguientes funciones:

  • NET_RAW para ping: agrega a SecurityContext de Pod.
  • SYS_PTRACE para la depuración: agrega a SecurityContext de Pod.
  • NET_ADMIN para mallas de servicios, como Istio: usa --workload-policies=allow-net-admin cuando crees un clúster o actualices uno existente. Después de eso, agrega la función a SecurityContext de Pod. Disponible en las versión 1.27 y posterior de GKE.

En las versiones de GKE anteriores a la versión 1.21, no se admite la capacidad "SYS_PTRACE".
Contenedores privilegiados Los contenedores no se pueden ejecutar en el modo privilegiado, a menos que un socio de Google Cloud implemente el contenedor. Los contenedores con privilegios pueden realizar cambios en el nodo subyacente, como cambiar el kubelet. Este acceso podría aumentar el impacto de una vulneración del Pod.
Espacios de nombres administrados por GKE Como medida de seguridad, Autopilot no permite implementar cargas de trabajo en espacios de nombres administrados por GKE, como kube-system.
Aislamiento del contenedor

Autopilot aplica las siguientes restricciones en los contenedores para limitar el impacto de las vulnerabilidades de escape de contenedores.

Funciones de Linux y seguridad del kernel

  • Autopilot aplica el perfil de seccomp RuntimeDefault a todos los Pods del clúster, a menos que los Pods usen GKE Sandbox. GKE Sandbox aplica el aislamiento del host e ignora las reglas seccomp especificadas en el manifiesto del Pod. La zona de pruebas se considera el límite de seguridad para los Pods de GKE Sandbox.
  • Autopilot descarta la capacidad de Linux CAP_NET_RAW para todos los contenedores. Este permiso no se usa con frecuencia y está sujeto a varias vulnerabilidades de escape. El comando ping puede fallar dentro de los contenedores porque se descarta esta función. Puedes volver a habilitar esta función de forma manual si la configuras en tu SecurityContext de Pod.
  • Autopilot descarta la capacidad de Linux CAP_NET_ADMIN para todos los contenedores. Para volver a habilitar esta función, especifica la marca --workload-policies=allow-net-admin en el comando de creación o actualización del clúster. Algunas cargas de trabajo, como Istio, requieren NET_ADMIN.
  • Autopilot habilita la federación de identidades para cargas de trabajo para GKE, que evita que el Pod acceda a metadatos sensibles en el nodo.
  • Autopilot bloquea los objetos Service de Kubernetes que configuran el campo spec.externalIPs para protegerlos contra CVE-2020-8554.

  • Autopilot solo permite los siguientes tipos de volúmenes:

    
"configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk",
  "nfs", "persistentVolumeClaim", "projected", "secret"

    Otros tipos de volúmenes están bloqueados porque requieren privilegios de nodo. Los volúmenes HostPath están bloqueados de forma predeterminada, pero los contenedores pueden solicitar acceso de solo lectura a las rutas de acceso /var/log para la depuración.

Aplicación de la política de seguridad a nivel del Pod Autopilot admite mecanismos de aplicación para las políticas de seguridad a nivel del Pod, como el controlador de admisión PodSecurity, Gatekeeper o Controlador de políticas. Sin embargo, es posible que no necesites usar ninguno de estos si las configuraciones de seguridad integradas que se describen en esta página ya cumplen con tus requisitos.
SSH a nodos

Autopilot bloquea el acceso SSH a los nodos. GKE maneja todos los aspectos operativos de los nodos, incluido el estado del nodo y todos los componentes de Kubernetes que se ejecutan en los nodos.

Aún puedes conectarte de forma remota a los contenedores en ejecución mediante la funcionalidad exec de Kubernetes a fin de ejecutar comandos en los contenedores para la depuración, incluida la conexión a una shell interactiva, por ejemplo, con kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.
Robo de identidad de usuarios La versión 1.22.4-gke.1501 y posteriores de GKE admiten el robo de identidad de usuarios para todos los usuarios y grupos definidos por el usuario. No se puede robar la identidad de los usuarios y grupos del sistema, como el usuario kube-apiserver y el grupo system:masters.
Webhooks de admisión dinámicos de mutación

Autopilot modifica los webhooks de mutación para descartar que se intercepten los recursos en espacios de nombres administrados, como kube-system.

Autopilot también rechaza los webhooks que especifican uno o más de los siguientes recursos y cualquier subrecurso de esos recursos.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

No puedes usar el comodín * para recursos o grupos a fin de omitir esta restricción.
Solicitudes de firma de certificados Puedes crear CertificateSigningRequests en Autopilot para crear certificados firmados por la autoridad certificadora del clúster. Para evitar interferencias con los componentes del sistema, Autopilot rechaza CertificateSigningRequests para identidades privilegiadas conocidas, como grupos del sistema, agentes del sistema o agentes de servicio de IAM administrados por Google.
Funciones de seguridad de GKE Los clústeres de Autopilot habilitan las funciones de seguridad recomendadas de GKE. Para obtener una lista de las funciones de seguridad habilitadas y opcionales, consulta Funciones de seguridad en Autopilot.
Sistema operativo del nodo Los clústeres de Autopilot usan Container-Optimized OS con containerd como el sistema operativo del nodo. Google crea y administra Container-Optimized OS.
Actualizaciones de versiones de GKE Los clústeres de Autopilot se inscriben en un canal de versiones de GKE durante la creación y las actualizaciones automáticas siempre están habilitadas. Con el tiempo, Google actualiza automáticamente el plano de control y los nodos a la última versión calificada en el canal de versiones.

Límites de seguridad en Autopilot

Autopilot proporciona acceso a la API de Kubernetes, pero quita permisos para usar algunas funciones de Kubernetes con muchos privilegios, como los Pods con privilegios. El objetivo es limitar la capacidad de acceder, modificar o controlar directamente la máquina virtual (VM) de los nodos. Autopilot implementa estas restricciones para limitar las cargas de trabajo que tienen acceso de bajo nivel a la VM de nodo, de manera que Google Cloud pueda ofrecer una administración completa de nodos y un ANS a nivel de Pod.

Nuestra intención es impedir el acceso no deseado a la VM del nodo. Aceptamos las presentaciones para ese fin mediante el Programa de recompensas por detección de vulnerabilidades de Google (VRP) y recompensaremos los informes a discreción del panel de recompensas de VRP de Google.

Por su diseño, los usuarios con privilegios, como los administradores de clústeres, tienen el control total de cualquier clúster de GKE. Como práctica recomendada de seguridad, recomendamos que evites otorgar privilegios potentes de GKE o Kubernetes y, en su lugar, uses la delegación de administrador de espacio de nombres siempre que sea posible, como se describe en nuestra guía de multiusuario.

Autopilot aprovisiona VMs de usuario único en tu proyecto para su uso exclusivo. En cada VM individual, las cargas de trabajo de Autopilot pueden ejecutarse juntas y compartir un kernel endurecido de seguridad. Debido a que el kernel compartido representa un único límite de seguridad, recomendamos que, si necesitas un aislamiento eficaz, como cargas de trabajo de alto riesgo o no confiables, las ejecutes en Pods de GKE Sandbox para brindar protección de seguridad de varias capas.

Recursos de seguridad según el caso de uso

En las siguientes secciones, se proporcionan vínculos y recomendaciones para planificar, implementar y administrar la seguridad de los clústeres de Autopilot según tu caso de uso.

Planifica la seguridad del clúster

Caso de uso Recursos
Comprende cómo GKE aborda la seguridad como plataforma
Entiende tu rol en el endurecimiento del entorno Obtén más información sobre el modelo de responsabilidad compartida.
Consulta las recomendaciones de Google sobre las medidas de endurecimiento y la respuesta ante incidentes
Comprende cómo GKE implementa el registro de auditoría

Autentica y autoriza

Después de configurar los clústeres de Autopilot, es posible que debas autenticar a los usuarios y las aplicaciones para que usen recursos, como la API de Kubernetes o las APIs de Google Cloud.

Caso de uso Recursos
Autentica usuarios o aplicaciones en el servidor de la API del clúster
  • Para autenticar usuarios, consulta Autentica usuarios.
  • Para autenticar aplicaciones, consulta Autentica aplicaciones, que proporciona pasos para autenticar desde aplicaciones en el mismo clúster, en otros entornos de Google Cloud o en entornos externos.
Autentica aplicaciones en las APIs y los servicios de Google Cloud Los clústeres de Autopilot te permiten usar la federación de identidades para cargas de trabajo para GKE para autenticar correctamente tus cargas de trabajo en las APIs de Google Cloud a través de la configuración de cuentas de servicio de Kubernetes para que actúen como cuentas de servicio de IAM. Si deseas obtener instrucciones, consulta Configura las aplicaciones para usar la federación de identidades para cargas de trabajo para GKE.
Autoriza acciones a nivel de proyecto Para autorizar acciones en los clústeres a nivel de proyecto, usa IAM. Puedes otorgar o denegar el acceso a recursos específicos de la API de GKE y Kubernetes mediante roles y permisos de IAM. Para obtener instrucciones, consulta Crea políticas de IAM.
Autoriza acciones a nivel del clúster A fin de autorizar acciones en los recursos de la API de Kubernetes en clústeres específicos, usa el mecanismo de control de acceso basado en roles (RBAC) integrado de Kubernetes. Para obtener instrucciones, consulta Autoriza acciones en clústeres mediante RBAC.
Autoriza acciones a nivel de la organización Puedes usar el Servicio de políticas de la organización de Google Cloud para aplicar restricciones en operaciones específicas en los recursos de GKE de tu organización de Google Cloud. Para obtener instrucciones, consulta Restringe acciones en los recursos de GKE mediante políticas de la organización personalizadas.

Endurece clústeres y cargas de trabajo

Si tienes requisitos de aislamiento o endurecimiento especializados que superan las medidas de Autopilot preconfiguradas, considera los siguientes recursos:

Caso de uso Recursos
Restringe el acceso público al extremo del clúster Crea tus clústeres de Autopilot como clústeres privados, que inhabilitan la dirección IP pública del plano de control del clúster. Para obtener instrucciones, consulta Clústeres privados.
Restringe el acceso a clústeres a redes específicas Usa redes autorizadas del plano de control para especificar rangos de direcciones IP que puedan acceder a tu clúster.
Almacena información sensible fuera del clúster Almacenar datos sensibles en un proveedor de almacenamiento encriptado externo con el control de versiones habilitado es un requisito de cumplimiento común y una práctica recomendada. Usa Secret Manager para almacenar tus datos y acceder a ellos desde los clústeres de Autopilot con la federación de identidades para cargas de trabajo para GKE. Si deseas obtener instrucciones, consulta Accede a los objetos Secret almacenados fuera de los clústeres de GKE con la federación de identidades para cargas de trabajo para GKE.
Verifica las imágenes del contenedor antes de la implementación en tu clúster Usa la autorización binaria para verificar la integridad de las imágenes de contenedor a las que se hace referencia en los manifiestos de Pods en el momento de la implementación. Para obtener instrucciones, consulta Verifica imágenes de contenedor en el momento de la implementación con la autorización binaria.

Supervisa tu posición de seguridad

Después de configurar los clústeres y, además, implementar tus cargas de trabajo, debes configurar la supervisión y el registro para tener observabilidad sobre la posición de seguridad del clúster. Te recomendamos que sigas todos los pasos que se indican a continuación:

  • Inscribe tus clústeres en el panel de postura de seguridad de GKE para auditar las cargas de trabajo en busca de problemas, como configuraciones de seguridad problemáticas o vulnerabilidades en tus paquetes de sistema operativo de contenedores, y obtener información de mitigación práctica.
  • Recibe notificaciones sobre boletines de seguridad nuevos y eventos de actualización mediante notificaciones de clúster.
  • Observa tus clústeres mediante el panel de GKE en Cloud Monitoring o la pestaña Observabilidad en GKE.
  • Obtén información sobre cómo ver y administrar los registros de auditoría de GKE en Cloud Logging.

¿Qué sigue?