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:
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:
En las versiones de GKE anteriores a la versión 1.21, no se admite la capacidad |
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
|
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 |
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 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 |
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 |
|
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?
- Lee la descripción general de la seguridad de GKE.
- Lee la guía de endurecimiento de GKE.
- Suscríbete a los boletines de seguridad y a las notas de la versión.