Medidas de seguridad de Autopilot de GKE

En esta página se describen las funciones, configuraciones y ajustes de seguridad del modo Autopilot de Google Kubernetes Engine (GKE). Esta información está dirigida a especialistas en seguridad que quieran conocer las restricciones de seguridad que aplica Google en el modo Autopilot y las funciones de seguridad que se pueden usar en Autopilot. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Antes de leer esta página, familiarícese con lo siguiente:

Terminología

En GKE, puedes usar Autopilot creando un clúster de Autopilot o ejecutando una carga de trabajo en un ComputeClass de Autopilot en cualquier clúster estándar. En esta página se describen las medidas de seguridad de Autopilot en ambas situaciones. Para ello, se utiliza la siguiente terminología:

Clúster de Autopilot
Todo el clúster usa el modo Autopilot.
Cargas de trabajo de Autopilot en clústeres estándar
El clúster usa el modo Estándar y ejecutas cargas de trabajo específicas en Autopilot mediante ComputeClasses.

Medidas de seguridad en Autopilot

GKE aplica de forma predeterminada varias prácticas recomendadas y ajustes de seguridad en el modo Autopilot, incluidas muchas de las recomendaciones de la sección de protección de clústeres y de la descripción general de seguridad.

En los clústeres Autopilot, GKE aplica estrictamente todas las medidas de esta página de forma predeterminada. Esta configuración predeterminada hace que los clústeres Autopilot sean la forma recomendada de usar GKE. En el caso de las cargas de trabajo de Autopilot en clústeres estándar, GKE aplica las medidas de seguridad de las siguientes secciones de la mejor forma posible.

Aplicación de los estándares de seguridad de pods de Kubernetes

El proyecto Kubernetes tiene un conjunto de directrices de seguridad llamado estándares de seguridad de pods que definen las siguientes políticas:

  • Privilegiado: sin restricciones de acceso. No se usa en Autopilot.
  • Base: evita las vías de apropiación de privilegios conocidas. 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.

En el modo Autopilot, GKE aplica restricciones de seguridad de pods mediante controladores de admisión de Kubernetes. La política de admisión predeterminada de Autopilot Pod incluye todas las recomendaciones del nivel Baseline de los estándares de seguridad de pods, con algunas modificaciones para mejorar la usabilidad. Además, la política de admisión predeterminada incluye muchas restricciones del nivel Restringido de los estándares de seguridad de pods, pero evita las restricciones que impedirían que se ejecutara la mayoría de tus cargas de trabajo.

Para aplicar restricciones adicionales y cumplir la política restringida completa, puedes usar de forma opcional el controlador de admisión PodSecurity en espacios de nombres específicos.

En la siguiente tabla se describe cómo se comparan los controles de la política de admisión predeterminada de Autopilot con los controles de los niveles Baseline y Restricted de los estándares de seguridad de pods. Para obtener más información sobre cada control de esta tabla, consulta la entrada correspondiente en Estándares de seguridad de pods.

Al evaluar el cumplimiento, hemos tenido en cuenta cómo se aplican las restricciones a tus cargas de trabajo. Esto excluye las cargas de trabajo de partners verificados Google Cloud y las cargas de trabajo del sistema que requieren privilegios específicos para funcionar.

Control Cumplimiento de las políticas básicas Cumplimiento de políticas restringido Información adicional
HostProcess Autopilot bloquea HostProcess.
Espacios de nombres de host Autopilot bloquea los espacios de nombres de host. Algunos contenedores de partners verificados pueden usar espacios de nombres de host.
Contenedores con privilegios Autopilot bloquea los contenedores con privilegios de forma predeterminada. Autopilot permite que los contenedores privilegiados de partners verificados se utilicen para fines como ejecutar herramientas de seguridad y monitorización.
Funciones de Linux

De forma predeterminada, las cargas de trabajo de Autopilot solo pueden acceder a las funciones especificadas en el estándar de seguridad de pods básico.

Puedes habilitar manualmente las siguientes funciones:

  • NET_RAW para hacer pings y SYS_PTRACE para depurar: Añadir a Pod SecurityContext
  • NET_ADMIN para mallas de servicios como Istio: especifica --workload-policies=allow-net-admin en el comando de creación de clústeres.

Autopilot también permite que algunas cargas de trabajo de partners verificados establezcan funciones eliminadas.
Volúmenes HostPath Cumple parcialmente Cumple parcialmente Autopilot permite que los contenedores soliciten acceso de solo lectura a /var/log para depurar, pero deniega cualquier otro acceso de lectura o escritura.
HostPorts No se permite definir puertos de host específicos, lo que mitiga algunos problemas de programación y evita la exposición directa de servicios a la red de forma accidental o deliberada. Puedes configurar manualmente la asignación aleatoria de puertos de host de un intervalo conocido para admitir aplicaciones de redes de conexión directa, como servidores de juegos.
AppArmor El perfil de seguridad predeterminado de Docker de AppArmor se aplica automáticamente a Container-Optimized OS.
SELinux SELinux no se aplica porque AppArmor ya está aplicado. SELinux tampoco es obligatorio en los estándares de seguridad de pods.
/proc tipo de montaje GKE no define el botón de activación de la función ProcMountType. Si el securityContext del pod define procMount como "Unmasked", GKE lo sustituye automáticamente por "Default".
perfil de seccomp Autopilot aplica el perfil RuntimeDefault seccomp a todas las cargas de trabajo. Puedes anular manualmente este ajuste en cargas de trabajo específicas configurando el perfil en Unconfined en la especificación del pod.
sysctls GKE no define la marca --allowed-unsafe-sysctls de kubelet, por lo que los pods con sysctls no seguros no se pueden programar. Para ofrecer una protección adicional, desde el 11 de julio del 2023, los nuevos clústeres 1.27+ también tienen una regla de política para aplicar la configuración de securityContext y rechazar los pods que usen sysctls no seguros.
Tipos de volúmenes Autopilot solo permite los tipos de volúmenes de la política Restringida con las siguientes adiciones: volúmenes HostPath con acceso de solo lectura a /var/log para depuración, gcePersistentDisk para discos persistentes de Compute Engine y nfs para volúmenes del sistema de archivos de red.
Apropiación de privilegios Este ajuste solo protege los contenedores que no se ejecutan como raíz. Las encuestas del sector muestran que el 76% de los contenedores se ejecutan como root, por lo que Autopilot permite que se ejecuten como root para habilitar la mayoría de las cargas de trabajo. Actualmente, este ajuste también es útil para quitar privilegios a las cargas de trabajo y convertirlas en no root. Para ello, permite usar las funciones del sistema de archivos para solucionar las deficiencias de la gestión de la función root de Kubernetes.
Ejecutar como no root Encuestas del sector muestran que el 76% de los contenedores se ejecutan como root, por lo que Autopilot permite que se ejecuten como root para habilitar la mayoría de las cargas de trabajo.
Ejecutar como usuario no root Los contenedores pueden asignar el valor 0 a runAsUser. Las encuestas del sector muestran que el 76% de los contenedores se ejecutan como raíz, por lo que Autopilot permite ejecutar como raíz para habilitar la mayoría de las cargas de trabajo.

Configuraciones de seguridad integradas

Además de los estándares de seguridad de los pods, Google aplica muchos ajustes de seguridad en Autopilot basados en las prácticas recomendadas del sector y en nuestra experiencia. Estas configuraciones de seguridad integradas se aplican estrictamente en los clústeres de Autopilot. En el caso de las cargas de trabajo de Autopilot en clústeres estándar, Google aplica estas configuraciones con algunas excepciones que se describen en la tabla que se muestra a continuación, de la mejor manera posible.

En la siguiente tabla se describen algunas de las configuraciones de seguridad que Autopilot aplica por ti:

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

Puedes usar las siguientes funciones 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 enviar un toque: Añadir a Pod SecurityContext.
  • SYS_PTRACE para depurar: añadir a Pod SecurityContext.
  • NET_ADMIN para mallas de servicio como Istio: usa --workload-policies=allow-net-admin cuando crees un clúster o actualices uno que ya tengas. Después, añade la función al Pod SecurityContext.
Contenedores con privilegios Los contenedores no se pueden ejecutar en modo Privilegiado a menos que los implemente un Google Cloud partner. Los contenedores con privilegios pueden hacer cambios en el nodo subyacente, como cambiar el kubelet. Este acceso podría aumentar el impacto de una vulneración de un pod.
Espacios de nombres gestionados por GKE Como medida de seguridad, Autopilot no permite desplegar cargas de trabajo en espacios de nombres gestionados por GKE, como kube-system.
Aislamiento de contenedores

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

Funciones de Linux y seguridad del kernel

  • Autopilot aplica el RuntimeDefault perfil seccomp 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 de seccomp especificadas en el manifiesto del pod. El sandbox se considera el límite de seguridad de los pods de GKE Sandbox.
  • Autopilot elimina la función CAP_NET_RAW Linux de todos los contenedores. Este permiso no se usa a menudo y ha sido objeto de varias vulnerabilidades de escape. Es posible que el comando ping falle en tus contenedores porque se ha eliminado esta función. Puedes volver a habilitar esta función manualmente configurándola en tu Pod SecurityContext.
  • Autopilot elimina la función CAP_NET_ADMIN Linux de 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. NET_ADMIN es obligatorio para algunas cargas de trabajo, como Istio.
  • Los clústeres de Autopilot habilitan Workload Identity Federation for GKE, lo que impide que los pods accedan a metadatos sensibles del nodo.
  • Autopilot bloquea los servicios de Kubernetes que definen el campo spec.externalIPs para protegerse contra CVE-2020-8554.

  • El piloto automático 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 /var/log para depurar.
Aplicación de políticas de seguridad a nivel de pod Autopilot admite mecanismos de implementación obligatoria de políticas de seguridad a nivel de pod, como el PodSecuritycontrolador de admisión, Gatekeeper o Policy Controller. Sin embargo, puede que no necesites usar ninguna de estas opciones si las configuraciones de seguridad integradas que se describen en esta página ya cumplen tus requisitos.
Conectarse a los nodos mediante SSH

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

Puedes seguir conectándote de forma remota a tus contenedores en ejecución mediante la función exec de Kubernetes para ejecutar comandos en tus contenedores con fines de depuración, como conectarte a una shell interactiva (por ejemplo, con kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh).
Representación de usuarios

Autopilot admite la suplantación de identidad de usuarios para todos los usuarios y grupos definidos por el usuario.

Solo en los clústeres de Autopilot, no se pueden suplantar los usuarios y grupos del sistema (como el usuario kube-apiserver y el grupo system:masters). Como las restricciones de suplantación de identidad de usuario se producen en el plano de control, esta restricción no se aplica en los clústeres estándar, aunque las cargas de trabajo usen una ComputeClass de Autopilot. No recomendamos en absoluto la suplantación de usuarios y grupos del sistema en GKE.
Mutating dynamic admission webhooks

Solo en los clústeres de Autopilot, GKE modifica los webhooks mutadores para excluir los recursos de los espacios de nombres gestionados, como kube-system, de la interceptación. Como el control de acceso se produce en el plano de control del clúster, esta restricción no se aplica en los clústeres estándar, aunque las cargas de trabajo usen una ComputeClass de Autopilot.

Autopilot también rechaza los webhooks que especifican uno o varios de los siguientes recursos, así como 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 carácter comodín * para recursos o grupos para eludir esta restricción.
ValidatingAdmissionPolicies

Solo en los clústeres de Autopilot, GKE modifica los objetos ValidatingAdmissionPolicy para excluir los recursos de los espacios de nombres gestionados, como kube-system, de la intercepción. Como el control de acceso se produce en el plano de control del clúster, esta restricción no se aplica en los clústeres estándar, aunque las cargas de trabajo usen un ComputeClass de Autopilot.

Autopilot también rechaza los objetos ValidatingAdmissionPolicy que especifican uno o varios de los siguientes recursos, así como 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 carácter comodín * para recursos o grupos para eludir esta restricción.
Solicitudes de firma de certificados Puedes crear CertificateSigningRequests en Autopilot para crear certificados firmados por la autoridad de certificación del clúster. Para evitar interferencias con los componentes del sistema, los clústeres de Autopilot rechazan las solicitudes CertificateSigningRequests de identidades privilegiadas conocidas, como grupos del sistema, agentes del sistema o agentes de servicio de IAM gestionados por Google. Esta restricción no se aplica a los clústeres estándar, que te permiten crear CertificateSigningRequests para identidades privilegiadas conocidas.
Funciones de seguridad de GKE Los clústeres de Autopilot habilitan las funciones de seguridad recomendadas de GKE. Para ver una lista de las funciones de seguridad habilitadas y opcionales, consulta el artículo sobre las funciones de seguridad de Autopilot.
Sistema operativo del nodo Autopilot usa Container-Optimized OS con containerd como sistema operativo de los nodos. Google crea y gestiona Container-Optimized OS.
Actualizaciones de versiones de GKE Los clústeres de Autopilot se registran en un canal de lanzamiento de GKE al crearse y las actualizaciones automáticas siempre están habilitadas. Google actualiza automáticamente el plano de control y los nodos a la versión cualificada más reciente del canal de lanzamiento con el tiempo.

Límites de seguridad en Autopilot

Autopilot proporciona acceso a la API de Kubernetes, pero elimina los permisos para usar algunas funciones de Kubernetes con privilegios elevados, como los pods con privilegios. El objetivo es limitar la capacidad de acceder, modificar o controlar directamente la máquina virtual del nodo. Autopilot implementa estas restricciones para limitar el acceso de bajo nivel de las cargas de trabajo a la VM del nodo, de modo queGoogle Cloud pueda ofrecer una gestión completa de los nodos y un ANS a nivel de pod.

Nuestra intención es evitar el acceso no intencionado a la VM del nodo. Aceptamos envíos a tal efecto a través del Programa de Recompensas por Detección de Vulnerabilidades (VRP) de Google y recompensaremos los informes a discreción del panel de recompensas del VRP de Google.

Por diseño, los usuarios con privilegios, como los administradores de clústeres, tienen control total sobre cualquier clúster de GKE. Como práctica recomendada de seguridad, te aconsejamos que evites conceder privilegios potentes de GKE o Kubernetes de forma generalizada y que, en su lugar, utilices la delegación de administrador de espacio de nombres siempre que sea posible, tal como se describe en nuestra guía sobre multitenencia.

Autopilot aprovisiona máquinas virtuales de un solo inquilino en tu proyecto para que las uses exclusivamente. En cada máquina virtual, tus cargas de trabajo de Autopilot pueden ejecutarse juntas y compartir un kernel reforzado con medidas de seguridad. Como el kernel compartido representa un único límite de seguridad, te recomendamos que, si necesitas un aislamiento sólido (por ejemplo, para cargas de trabajo de alto riesgo o que no sean de confianza), ejecutes tus cargas de trabajo en pods de GKE Sandbox para disfrutar de una protección de seguridad multicapa.

Recomendaciones de seguridad basadas en el caso práctico

En las siguientes secciones se proporcionan enlaces y recomendaciones para planificar, implementar y gestionar la seguridad de los clústeres de Autopilot en función de tu caso de uso.

Planificar la seguridad del clúster

Caso práctico Recursos
Descubrir cómo aborda la seguridad GKE como plataforma
Conocer tu papel en la protección de tu entorno Consulta información sobre el modelo de responsabilidad compartida.
Consulta las recomendaciones de Google sobre medidas de protección y respuesta a incidentes
Información sobre cómo implementa GKE el registro de auditoría

Autenticar y autorizar

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

Caso práctico Recursos
Autenticar usuarios o aplicaciones en el servidor de la API del clúster
  • Para autenticar usuarios, consulta el artículo Autenticar usuarios.
  • Para autenticar aplicaciones, consulta Autenticar aplicaciones, donde se indican los pasos para autenticar aplicaciones en el mismo clúster, en otros entornos o en entornos externos. Google Cloud
Autenticar aplicaciones en Google Cloud APIs y servicios Los clústeres Autopilot te permiten usar la federación de Workload Identity para GKE y autenticar de forma segura tus cargas de trabajo en las APIs configurando cuentas de servicio de Kubernetes para que actúen como cuentas de servicio de IAM. Google Cloud Para obtener instrucciones, consulta Configurar aplicaciones para usar Workload Identity Federation for GKE.
Autorizar acciones a nivel de proyecto Para autorizar acciones en todos los clústeres a nivel de proyecto, usa la gestión de identidades y accesos. Puedes conceder o denegar el acceso a recursos específicos de la API de GKE y Kubernetes mediante roles y permisos de gestión de identidades y accesos. Para obtener instrucciones, consulta Crear políticas de gestión de identidades y accesos.
Autorizar acciones a nivel de clúster Para autorizar acciones en recursos de la API de Kubernetes en clústeres específicos, usa el mecanismo de control de acceso basado en roles (RBAC) de Kubernetes. Para obtener instrucciones, consulta el artículo Autorizar acciones en clústeres mediante RBAC.
Autorizar acciones a nivel de organización Puedes usar el Google Cloud servicio de políticas de la organización para aplicar restricciones en operaciones específicas de recursos de GKE en toda tu Google Cloud organización. Para obtener instrucciones, consulta Restringir acciones en recursos de GKE mediante políticas de organización personalizadas.

Refuerza la seguridad de los clústeres y las cargas de trabajo

Si tienes requisitos de aislamiento o protección especializados que van más allá de las medidas preconfiguradas de Autopilot, consulta los siguientes recursos:

Caso práctico Recursos
Restringir el acceso público al endpoint de un clúster Configura el aislamiento de red de tus clústeres de Autopilot e inhabilita el endpoint externo del plano de control del clúster. Para obtener instrucciones, consulta Configurar el acceso al plano de control.
Restringir el acceso al clúster a redes específicas Usa las redes autorizadas del plano de control para especificar los intervalos de direcciones IP que pueden acceder a tu clúster.
Almacenar información sensible fuera del clúster Almacenar datos sensibles en un proveedor de almacenamiento externo cifrado con el control de versiones habilitado es un requisito de cumplimiento habitual y una práctica recomendada. Usa Secret Manager para almacenar tus datos y acceder a ellos desde tus clústeres de Autopilot mediante Workload Identity Federation para GKE. Para obtener instrucciones, consulta Acceder a secretos almacenados fuera de los clústeres de GKE mediante Workload Identity Federation for GKE.
Verificar imágenes de contenedor antes de desplegarlas en tu clúster Usa la autorización binaria para comprobar la integridad de las imágenes de contenedor a las que se hace referencia en los manifiestos de tus pods en el momento del despliegue. Para obtener instrucciones, consulta el artículo Verificar imágenes de contenedor en tiempo de despliegue con autorización binaria.

Monitorizar tu postura de seguridad

Después de configurar los clústeres e implementar las cargas de trabajo, debes configurar la monitorización y el registro para tener visibilidad de la postura de seguridad de los clústeres. Te recomendamos que hagas lo siguiente:

Siguientes pasos