En esta página se describe la exploración de la estrategia de seguridad de Kubernetes, una función del panel de control de estrategias de seguridad que te ayuda a identificar y abordar de forma proactiva las vulnerabilidades de seguridad de tus clústeres de Google Kubernetes Engine (GKE). En esta página se explica la auditoría de la configuración de las cargas de trabajo y la publicación de boletines de seguridad para encontrar y mitigar los riesgos de seguridad en GKE.
Esta página está dirigida a especialistas en seguridad que monitorizan clústeres para detectar problemas de seguridad. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el Trusted Cloud by S3NS contenido, consulta Roles y tareas habituales de los usuarios de GKE.
Para habilitar y usar el análisis de la postura de seguridad de Kubernetes, consulta Auditar automáticamente las cargas de trabajo para detectar problemas de configuración.
El análisis de la postura de seguridad de Kubernetes ofrece las siguientes funciones:
Precios
Se ofrece sin coste adicional en GKE.
Las entradas añadidas a Cloud Logging están sujetas a los precios de Cloud Logging.
Acerca de la auditoría de configuración de cargas de trabajo
Las cargas de trabajo que implementes en GKE deben tener una configuración reforzada que limite su superficie de ataque. Comprobar manualmente los problemas de configuración de las cargas de trabajo en todos los clústeres puede ser difícil a gran escala. Puedes usar el panel de control de postura de seguridad para auditar automáticamente la configuración de todas tus cargas de trabajo en ejecución en varios clústeres y obtener resultados y recomendaciones útiles para mejorar tu postura de seguridad.
La auditoría de configuración de cargas de trabajo comprueba cada carga de trabajo implementada con un subconjunto de políticas de los estándares de seguridad de pods. La auditoría de la configuración de las cargas de trabajo se realiza en la infraestructura de Google y no utiliza recursos de computación en tus nodos.
Ventajas de la auditoría de la configuración de cargas de trabajo
- Automatiza la detección de problemas de configuración conocidos en todas las cargas de trabajo.
- Recibe recomendaciones útiles para mejorar la postura de seguridad.
- Usa la consola Trusted Cloud para obtener una vista general de los problemas de configuración.
- Usa el registro para obtener un registro de auditoría de los problemas y mejorar los informes y la observabilidad.
Cómo funciona la auditoría de configuración de cargas de trabajo
En cada carga de trabajo desplegada apta, GKE analiza continuamente la especificación de la carga de trabajo y compara los campos y los valores con los controles definidos en la política de seguridad subyacente. Por ejemplo, un pod con spec.containers.securityContext.privileged=true infringe el estándar de seguridad de pods de nivel básico, y un pod con el campo spec.securityContext.runAsNonRoot definido como false infringe el estándar Restringido. Para ver una lista de las políticas de seguridad que comprueba GKE, consulta ¿Qué comprueba la auditoría de configuración de cargas de trabajo?
Después de analizar y detectar problemas, GKE califica la gravedad de los problemas de configuración detectados en función de las medidas de protección de seguridad integradas. GKE asigna una valoración de gravedad que puede indicar la rapidez con la que debes responder a la incidencia. La consolaTrusted Cloud muestra los resultados y las acciones recomendadas que puedes llevar a cabo para solucionar los problemas. GKE también añade entradas a Cloud Logging para la monitorización y la auditoría.
¿Qué comprueba la auditoría de configuración de cargas de trabajo?
| Problema | Campos | Valores permitidos | Gravedad |
|---|---|---|---|
Espacios de nombres de host Los pods que comparten espacios de nombres de host permiten que los procesos de los pods se comuniquen con los procesos del host y recojan información del host, lo que podría provocar que se salga de un contenedor. |
|
|
Alta |
Contenedores privilegiados Los contenedores con privilegios permiten un acceso casi ilimitado al host. Comparten espacios de nombres con el host y no tienen restricciones de grupo de control, seccomp, AppArmor ni de capacidades. |
|
|
Alta |
Acceso al puerto del host Si expones un puerto de host a un contenedor, este podrá interceptar el tráfico de red a un servicio de host que use ese puerto o eludir las reglas de control de acceso a la red, como las reglas de una NetworkPolicy. |
|
|
Alta |
Funciones no predeterminadas Un contenedor tiene asignadas funciones que podrían permitir que se salga del contenedor. |
|
|
Medio |
Montar volúmenes de ruta de host Los |
spec.volumes[*].hostPath |
Indefinido o nulo | Medio |
Máscara El tipo de montaje |
|
|
Medio |
Máscara de sysctls no seguros Se puede configurar un pod para permitir la modificación de parámetros del kernel no seguros mediante el sistema de archivos virtual |
spec.securityContext.sysctls[*].name |
|
Medio |
Ejecutar como usuario no root Puedes permitir explícitamente que un contenedor se ejecute como usuario root si la directiva |
|
true |
Medio |
Apropiación de privilegios Un contenedor se puede configurar explícitamente para permitir la elevación de privilegios en la ejecución. Esto permite que un proceso creado en el contenedor mediante la ejecución de un archivo ejecutable set-user-id, set-group-id o de capacidad de archivo obtenga los privilegios especificados por el archivo ejecutable. La falta de un control de seguridad preventivo aumenta el riesgo de que se eluda el contenedor. |
|
false |
Medio |
Perfil de AppArmor sin restricciones Un contenedor se puede configurar explícitamente para que AppArmor no lo limite. De esta forma, se asegura de que no se aplique ningún perfil de AppArmor al contenedor y, por lo tanto, no se vea limitado por ellos. El control de seguridad preventivo inhabilitado aumenta el riesgo de que se eluda el contenedor. |
metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"] |
false |
Bajo |
Además, GKE comprueba si hay RoleBindings o ClusterRoleBindings de RBAC que hagan referencia a uno de los siguientes usuarios o grupos:
system:anonymoussystem:authenticatedsystem:unauthenticated
Si existen enlaces RBAC que hacen referencia a estos usuarios o grupos, aparecerá un resultado llamado Usuarios anónimos con acceso al clúster de GKE con una gravedad Media en el panel de control de postura de seguridad. Estos usuarios y grupos son anónimos y no se deben usar en RoleBindings ni ClusterRoleBindings. Para obtener más información, consulta el artículo sobre cómo evitar los roles y grupos predeterminados.
Acerca de la publicación de boletines de seguridad
Cuando se descubre una vulnerabilidad en GKE, la corregimos y publicamos un boletín de seguridad sobre ella. Para obtener información sobre la identificación, la aplicación de parches y los plazos, consulta el artículo Aplicación de parches de seguridad de GKE.
El panel de control de la postura de seguridad muestra boletines de seguridad que afectan a tus clústeres, cargas de trabajo y grupos de nodos en modo estándar. Esta función forma parte de la capacidad Postura de seguridad de Kubernetes del panel de control de postura de seguridad y se habilita automáticamente al crear un clúster Autopilot o Estándar. Para habilitar el análisis de la postura de seguridad de Kubernetes, sigue las instrucciones que se indican en Auditar automáticamente las cargas de trabajo para detectar problemas de configuración.
La consola Trusted Cloud muestra detalles como los clústeres afectados, las versiones y las versiones de parche recomendadas para realizar actualizaciones que mitiguen la vulnerabilidad. Solo verás los boletines para los que haya una mitigación disponible en la región o zona de tu clúster. Trusted Cloud
Para ver los boletines de los clústeres que has registrado en el análisis de la postura de seguridad de Kubernetes, ve al panel de control de la postura de seguridad:
Los boletines disponibles que afecten a tu entorno aparecerán en la sección Boletines de seguridad.