En este documento se describe cómo gestiona Google las vulnerabilidades de seguridad y los parches de Google Kubernetes Engine (GKE).
Esta página está dirigida a especialistas en seguridad que ayudan a resolver problemas o vulnerabilidades de seguridad que requieren asistencia estratégica, como incidentes y problemas derivados del equipo de Asistencia. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.
Responsabilidad compartida de las actualizaciones
La aplicación de parches es una responsabilidad compartida entre Google y el cliente. Cada plataforma tiene responsabilidades compartidas diferentes. Consulta los siguientes temas de cada plataforma para obtener más información:
- GKE
- Google Distributed Cloud (local)
- GKE en AWS
- Google Distributed Cloud para bare metal
- GKE en Azure
Cómo descubrimos las vulnerabilidades
Google ha invertido mucho en el diseño y el refuerzo de la seguridad proactiva, pero incluso los sistemas de software mejor diseñados pueden tener vulnerabilidades. Para detectar esas vulnerabilidades y corregirlas antes de que se puedan aprovechar, Google ha hecho inversiones significativas en varios frentes.
A efectos de aplicación de parches, GKE es una capa de sistema operativo con contenedores que se ejecutan en la parte superior. Los sistemas operativos, Container-Optimized OS o Ubuntu, se han reforzado y contienen la cantidad mínima de software necesaria para ejecutar contenedores. Las funciones de GKE se ejecutan como contenedores sobre las imágenes base.
Google identifica y corrige las vulnerabilidades y los parches que faltan de las siguientes formas:
Container-Optimized OS: Google analiza las imágenes para identificar posibles vulnerabilidades y parches que faltan. El equipo de Container-Optimized OS revisa y resuelve los problemas.
Ubuntu: Canonical proporciona a Google compilaciones del SO que tienen aplicados todos los parches de seguridad disponibles.
Google analiza los contenedores con Container Registry Artifact Analysis para detectar vulnerabilidades y parches que faltan en Kubernetes y en los contenedores gestionados por Google. Si hay correcciones disponibles, el escáner iniciará automáticamente el proceso de aplicación de parches y lanzamiento.
Además del análisis automatizado, Google descubre y corrige vulnerabilidades desconocidas para los analizadores de las siguientes formas.
Google realiza sus propias auditorías, pruebas de penetración y detección de vulnerabilidades en todas las plataformas. Para ver una lista de las plataformas, consulta la sección anterior Aplicación de parches a la responsabilidad compartida.
Equipos especializados de Google y proveedores de seguridad externos de confianza llevan a cabo sus propias investigaciones sobre ataques. Google también ha colaborado con la CNCF para proporcionar gran parte de la experiencia en organización y consultoría técnica para la auditoría de seguridad de Kubernetes.
Google colabora activamente con la comunidad de investigación en temas de seguridad a través de varios programas de recompensas por vulnerabilidades. Un programa de recompensas por vulnerabilidades específico Google Cloud ofrece recompensas importantes,como 133.337 USD por la mejor vulnerabilidad en la nube que se encuentre cada año. En el caso de GKE, hay un programa que recompensa a los investigadores de seguridad si consiguen saltarse nuestros controles de seguridad. El programa cubre todas las dependencias de software de GKE.
Google colabora con otros partners del sector y de software libre que comparten vulnerabilidades, investigaciones de seguridad y parches antes de que se publiquen. El objetivo de esta colaboración es parchear grandes partes de la infraestructura de Internet antes de que se anuncie públicamente la vulnerabilidad. En algunos casos, Google contribuye a esta comunidad con las vulnerabilidades que encuentra. Por ejemplo, el proyecto Zero de Google descubrió y publicó las vulnerabilidades Spectre y Meltdown. El equipo de seguridad también encuentra y corrige periódicamente Google Cloud vulnerabilidades en la máquina virtual basada en kernel (KVM).
La colaboración de Google en materia de seguridad se produce en muchos niveles. A veces, se produce formalmente a través de programas en los que las organizaciones se registran para recibir notificaciones previas al lanzamiento sobre vulnerabilidades de software de productos como Kubernetes y Envoy. La colaboración también se produce de forma informal debido a nuestra participación en muchos proyectos de código abierto, como el kernel de Linux, los tiempos de ejecución de contenedores y la tecnología de virtualización, entre otros.
En el caso de Kubernetes, Google es miembro activo y fundador del Comité de Respuesta de Seguridad (SRC) y ha escrito gran parte del Proceso de Lanzamiento de Seguridad. Google es miembro de la lista de distribuidores de Kubernetes, que recibe notificaciones previas de vulnerabilidades, y ha participado en la clasificación, la aplicación de parches, el desarrollo de mitigaciones y la comunicación de casi todas las vulnerabilidades de seguridad graves de Kubernetes. Google también ha descubierto varias vulnerabilidades de Kubernetes por nuestra cuenta.
Aunque se descubren y se solucionan vulnerabilidades menos graves fuera de estos procesos, la mayoría de las vulnerabilidades de seguridad críticas se comunican de forma privada a través de uno de los canales que se han indicado anteriormente. Si nos avisas con antelación, Google tendrá tiempo antes de que la vulnerabilidad se haga pública para investigar cómo afecta a GKE, desarrollar parches o medidas de mitigación y preparar consejos y comunicaciones para los clientes. Cuando es posible, Google parchea todos los clústeres antes de que se publique la vulnerabilidad.
Cómo se clasifican las vulnerabilidades
GKE invierte mucho en la protección de seguridad de toda la pila, incluidas las capas de SO, contenedor, Kubernetes y red, además de definir valores predeterminados adecuados, configuraciones de seguridad reforzada y componentes gestionados. En conjunto, estas medidas ayudan a reducir el impacto y la probabilidad de que se produzcan vulnerabilidades.
El equipo de seguridad de GKE clasifica las vulnerabilidades según el sistema de puntuación de vulnerabilidades de Kubernetes. Las clasificaciones tienen en cuenta muchos factores, como la configuración de GKE y el refuerzo de la seguridad. Debido a estos factores y a las inversiones que realiza GKE en seguridad, las clasificaciones de vulnerabilidades de GKE pueden ser diferentes de las de otras fuentes.
En la siguiente tabla se describen las categorías de gravedad de las vulnerabilidades:
Gravedad | Descripción |
---|---|
Crítica | Una vulnerabilidad que puede explotar fácilmente en todos los clústeres un atacante remoto no autenticado, lo que provoca que el sistema se vea comprometido por completo. |
Alta | Una vulnerabilidad fácilmente explotable en muchos clústeres que provoca la pérdida de confidencialidad, integridad o disponibilidad. |
Medio | Una vulnerabilidad que se puede aprovechar en algunos clústeres en los que la pérdida de confidencialidad, integridad o disponibilidad está limitada por configuraciones comunes, la dificultad de la propia vulnerabilidad, el acceso necesario o la interacción del usuario. |
Bajo | Todas las demás vulnerabilidades. Es poco probable que se produzca una explotación o las consecuencias de la explotación son limitadas. |
Consulta los boletines de seguridad para ver ejemplos de vulnerabilidades, correcciones y mitigaciones, así como sus clasificaciones.
Cómo se parchean las vulnerabilidades en los clústeres de GKE
Para corregir una vulnerabilidad, debes actualizar a una nueva versión de GKE. Las versiones de GKE incluyen componentes con versiones del sistema operativo, componentes de Kubernetes y otros contenedores que forman la plataforma de GKE. Para corregir algunas vulnerabilidades, solo es necesario actualizar el plano de control, lo que Google hace automáticamente en GKE, mientras que para otras es necesario actualizar tanto el plano de control como los nodos.
Para que los clústeres tengan los parches aplicados y estén protegidos frente a vulnerabilidades de cualquier gravedad, te recomendamos que uses la actualización automática de nodos en GKE (activada de forma predeterminada). En los clústeres registrados en canales de lanzamiento, las versiones de parche se promocionan a medida que cumplen los requisitos de cada canal. Si necesitas una versión de parche de GKE antes de que llegue al canal de tu clúster, puedes actualizar manualmente a la versión de parche si la versión de parche tiene la misma versión secundaria que una disponible en el canal de lanzamiento de tu clúster.
En otras plataformas en las que se ejecutan clústeres, Google recomienda actualizar al menos una vez al mes. Para ver una lista de las plataformas, consulta la sección anterior Aplicación de parches a la responsabilidad compartida.
Es posible que algunos escáneres de seguridad o comprobaciones manuales de versiones asuman incorrectamente que a un componente como runc o containerd le falta un parche de seguridad específico de la versión upstream. GKE parchea los componentes con regularidad y solo realiza actualizaciones de la versión del paquete cuando es necesario, lo que significa que los componentes de GKE son funcionalmente similares a sus equivalentes upstream, aunque el número de versión del componente de GKE no coincida con el número de versión upstream. Para obtener información sobre una CVE específica, consulta los boletines de seguridad de GKE.
Plazos de aplicación de parches
El objetivo de Google es mitigar las vulnerabilidades detectadas en un periodo de tiempo adecuado a los riesgos que representan. GKE se incluye en la autorización provisional de funcionamiento de FedRAMP deGoogle Cloud, que requiere que las vulnerabilidades conocidas se corrijan en plazos específicos según su nivel de gravedad, tal como se especifica en el control RA-5(d) de la tabla "Resumen de actividades y entregables de la monitorización continua" de la guía de estrategia de monitorización continua de FedRAMP.
El objetivo de GKE es lanzar versiones de parche para cada vulnerabilidad conocida en el plazo correspondiente. La Google Cloud autorización provisional para operar de FedRAMP no incluye Google Distributed Cloud, GKE en AWS ni GKE en Azure, pero nuestro objetivo es que los plazos de corrección sean los mismos en esos productos. Cuando GKE publique versiones de parche para corregir una vulnerabilidad conocida, actualiza tus clústeres a esas versiones para cumplir los plazos de aplicación de parches de tu organización.
Cómo se comunican las vulnerabilidades y los parches
La mejor fuente de información actualizada sobre vulnerabilidades y parches de seguridad es el feed de boletines de seguridad de los siguientes productos:
- GKE
- Google Distributed Cloud
- GKE en AWS
- GKE en Azure
- Google Distributed Cloud
Estos boletines siguen un Google Cloud esquema de numeración de vulnerabilidades Google Cloud común y se vinculan desde la página principal de boletines y las notas de la versión de GKE. Cada página de boletines de seguridad tiene un feed RSS al que los usuarios pueden suscribirse para recibir actualizaciones.
A veces, las vulnerabilidades se mantienen privadas y no pueden divulgarse durante un tiempo limitado. Los embargos ayudan a evitar la publicación anticipada de vulnerabilidades que podrían provocar intentos de explotación generalizados antes de que se puedan tomar medidas para solucionarlas. En situaciones de embargo, las notas de la versión hacen referencia a "actualizaciones de seguridad" hasta que se levanta el embargo. Una vez que se levanta el embargo, Google actualiza las notas de la versión para incluir las vulnerabilidades específicas.
El equipo de seguridad de GKE publica boletines de seguridad para vulnerabilidades de gravedad alta y crítica. Cuando se requiere la intervención del cliente para solucionar estas vulnerabilidades de gravedad alta y crítica, Google se pone en contacto con él por correo electrónico. Además, Google también puede ponerse en contacto con los clientes que tengan contratos de asistencia a través de los canales de asistencia.