Archivo de boletines de seguridad

En esta página, se incluye un archivo histórico de todos los boletines de seguridad anteriores a 2020 para los siguientes productos:

Para ver los boletines de seguridad más recientes, consulta la página Boletines de seguridad.

Boletines de seguridad de GKE

14 de noviembre de 2019

Fecha de publicación: 14/11/2019
Última actualización: 14/11/2019
Descripción Gravedad Notas

Kubernetes divulgó un problema de seguridad de los archivos adicionales de kubernetes-csi external-provisioner, external-snapshotter y external-resizer, que afecta a la mayoría de las versiones de los archivos adicionales en paquetes de controladores de Container Storage Interface (CSI). Para obtener más detalles, consulta la divulgación de Kubernetes.

¿Qué debo hacer?
Esta vulnerabilidad no afecta a ningún componente administrado de GKE. Es posible que te veas afectado si administras tus propios controladores de CSI en los clústeres Alfa de GKE que ejecutan la versión de GKE 1.12 o posteriores. Si te ves afectado, consulta con tu proveedor de controladores de CSI para obtener instrucciones de actualización.

¿Qué vulnerabilidades trata este parche?
CVE-2019-11255: Esta CVE es una vulnerabilidad de los archivos adicionales external-provisioner, external-snapshotter y external-resizer de kubernetes-csi, que pueden permitir el acceso a datos de volumen o su mutación no autorizados. Esta afecta a la mayoría de las versiones de los archivos adicionales en paquetes de controladores de CSI.

Medio

CVE-2019-11255

12 de noviembre de 2019

Fecha de publicación: 12/11/2019
Última actualización: 12/11/2019
Descripción Gravedad Notas

Intel divulgó las CVE que podrían permitir las interacciones entre la ejecución especulativa y el estado de microarquitectura para exponer datos. Para obtener más detalles, consulta la divulgación de Intel.

La infraestructura de host que ejecuta Kubernetes Engine aísla las cargas de trabajo del cliente. A menos que ejecutes código no confiable dentro de tus propios clústeres de GKE de instancias múltiples y uses nodos N2, M2 o C2, no será necesario que realices ninguna acción. En el caso de las instancias de GKE en los nodos N1, no se requiere ninguna otra acción.

Si ejecutas Google Distributed Cloud, la exposición depende del hardware. Compara tu infraestructura con la divulgación de Intel.

¿Qué debo hacer?

Solo te verás afectado si usas grupos de nodos con nodos N2, M2 o C2 y estos ejecutan código no confiable dentro de tus propios clústeres de GKE de instancias múltiples.

El parche se aplica mediante el reinicio de los nodos. La manera más sencilla de reiniciar todos los nodos de tu grupo de nodos es usar la operación de actualización para forzar un reinicio en todos los grupos de nodos afectados.

¿Qué vulnerabilidades corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2019-11135: Esta CVE también se conoce como TSX Async Abort (TAA). TAA proporciona otra forma de robo de datos mediante las mismas estructuras de datos de microarquitectura que aprovechó el muestreo de datos de microarquitectura (MDS).

CVE-2018-12207: Se trata de una vulnerabilidad de denegación del servicio (DoS) que afecta a los hosts de máquinas virtuales, ya que permite que un invitado malicioso haga fallar un host sin protección. Esta CVE también se conoce como “Error de verificación de máquina en el cambio de tamaño de página”. No afecta a GKE.

Medio

CVE-2019-11135
CVE-2018-12207

22 de octubre de 2019

Fecha de publicación: 22/10/2019
Última actualización: 22/10/2019
Descripción Gravedad Notas

Hace poco tiempo, se descubrió una vulnerabilidad en el lenguaje de programación Go y se describió en CVE-2019-16276. Esta vulnerabilidad podría afectar a las configuraciones de Kubernetes que usan un proxy de autenticación. Para obtener más detalles, consulta la divulgación de Kubernetes.

Kubernetes Engine no permite la configuración de un proxy de autenticación, por lo que esta vulnerabilidad no lo afecta.

Ninguno

CVE-2019-16276

16 de octubre de 2019

Fecha de publicación: 16/10/2019
Última actualización: 24/10/2019
Descripción Gravedad Notas

Actualización del 24/10/2019: Las versiones con parche ahora están disponibles en todas las zonas.

Hace poco tiempo, se descubrió una vulnerabilidad en Kubernetes, descrita en CVE-2019-11253, que permite que cualquier usuario autorizado haga solicitudes POST para ejecutar un ataque a distancia de denegación del servicio en un servidor de la API de Kubernetes. El Product Security Committee (PSC) de Kubernetes publicó información adicional sobre esta vulnerabilidad, que puedes encontrar aquí.

Los clústeres de GKE que usan redes autorizadas para instancias principales y clústeres privados sin extremo público mitigan esta vulnerabilidad.

¿Qué debo hacer?

Te recomendamos actualizar tu clúster a una versión de parche que contenga la corrección en cuanto esté disponible. Esperamos que esté disponibles en todas las zonas con la actualización de GKE planificada para la semana del 14 de octubre.

Las versiones de parche que contendrán la mitigación son las siguientes:

  • 1.12.10-gke.15
  • 1.13.11-gke.5
  • 1.14.7-gke.10
  • 1.15.4-gke.15
¿Qué vulnerabilidades corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2019-11253 es una vulnerabilidad de denegación del servicio (DoS).

Alta

CVE-2019-11253

16 de septiembre de 2019

Fecha de publicación: 16/09/2019
Última actualización: 16/10/2019
Descripción Gravedad Notas

Este boletín se actualizó desde su publicación original.

Hace poco tiempo, se descubrieron vulnerabilidades de seguridad nuevas en el lenguaje de programación Go: CVE-2019-9512 y CVE-2019-9514, que son vulnerabilidades de denegación del servicio (DoS). En GKE, esta vulnerabilidad podría permitir que un usuario cree solicitudes malintencionadas que consuman cantidades excesivas de CPU en el servidor de la API de Kubernetes, lo que podría reducir la disponibilidad del plano de control de los clústeres. Para obtener más detalles, consulta la divulgación del lenguaje de programación Go.

¿Qué debo hacer?

Te recomendamos actualizar tu clúster a la versión más reciente del parche, que contenga la mitigación para esta vulnerabilidad en cuanto esté disponible. Esperamos que esté disponibles en todas las zonas con la próxima actualización de GKE, según el programa de actualización.

Las versiones de parche que contendrán la mitigación son las siguientes:

  • Actualización del 16 de octubre de 2019: 1.12.10-gke.15
  • 1.13.10-gke.0
  • 1.14.6-gke.1
¿Qué vulnerabilidad corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2019-9512 y CVE-2019-9514 son vulnerabilidades de denegación del servicio (DoS).

Alta

CVE-2019-9512
CVE-2019-9514

5 de septiembre de 2019

Fecha de publicación: 5/09/2019
Última actualización: 5/09/2019

Se actualizó el boletín de la corrección de la vulnerabilidad que se documentó en la edición del 31 de mayo de 2019.

22 de agosto de 2019

Fecha de publicación: 22/08/2019
Última actualización: 22/08/2019

Se actualizó el boletín del 5 de agosto de 2019. La corrección de la vulnerabilidad documentada en el boletín anterior está disponible.

8 de agosto de 2019

Fecha de publicación: 8/08/2019
Última actualización: 8/08/2019

Se actualizó el boletín del 5 de agosto de 2019. Esperamos que la corrección de la vulnerabilidad que se documentó en ese boletín esté disponible en la próxima actualización de GKE.

5 de agosto de 2019

Fecha de publicación: 5/08/2019
Última actualización: 9/08/2019
Descripción Gravedad Notas

Este boletín se actualizó desde su publicación original.

Hace poco tiempo, se descubrió una vulnerabilidad en Kubernetes, CVE-2019-11247, que permite que se actúe sobre instancias de recursos personalizados de alcance de clúster como si fueran objetos con espacio de nombres existentes en todos los espacios de nombres. Esto significa que las cuentas de usuario y de servicio solo deben contar con permisos de RBAC a nivel de espacio de nombres para interactuar con recursos personalizados de alcance de clúster. A fin de aprovechar esta vulnerabilidad, el atacante debe tener privilegios para acceder al recurso en cualquier espacio de nombres.

¿Qué debo hacer?

Te recomendamos que actualices el clúster a la versión más reciente del parche, que contiene la mitigación para esta vulnerabilidad, en cuanto esté disponible. Esperamos que esté disponible en todas las zonas con la próxima actualización de GKE. Las versiones de parche que contendrán la mitigación se mencionan a continuación:

  • 1.11.10-gke.6
  • 1.12.9-gke.13
  • 1.13.7-gke.19
  • 1.14.3-gke.10 (Canal rápido)
¿Qué vulnerabilidad trata este parche?

El parche mitiga la siguiente vulnerabilidad: CVE-2019-11247.

Medio

CVE-2019-11247

3 de julio de 2019

Fecha de publicación: 3/07/2019
Última actualización: 3/07/2019
Descripción Gravedad Notas

Ya está disponible una versión con parche de kubectl para abordar la CVE-2019-11246, con gcloud 253.0.0. Consulta el boletín de seguridad del 25 de junio de 2019 para obtener más información.

Nota: El parche no está disponible en kubectl 1.11.10.

Alta

CVE-2019-11246

3 de julio de 2019

Fecha de publicación: 25/06/2019
Última actualización: 3/07/2019
Descripción Gravedad Notas
Actualización del 3 de julio de 2019

Al momento de nuestra última actualización, los parches de las versiones 1.11.9 y 1.11.10 no estaban disponibles. Ahora lanzamos la versión 1.11.10-gke.5 como una asignación de actualización para ambas versiones 1.11.

Por el momento, las instancias principales de GKE cuentan con el parche, y la infraestructura de Google que ejecuta Kubernetes Engine, además de contar con el parche, está protegida de esta vulnerabilidad.

Las instancias principales de 1.11 pronto quedarán obsoletas y están programadas para actualizarse de forma automática a la versión 1.12 durante la semana del 8 de julio de 2019. Puedes elegir cualquiera de las siguientes acciones sugeridas para actualizar los nodos a una versión con parche:

  • Realiza la actualización de nodos a la versión 1.11.10-gke.5 antes del 8 de julio de 2019. Después de esta fecha, se comenzará a quitar las versiones 1.11 de la lista disponible de asignaciones de actualización.
  • Habilita las actualizaciones automáticas en los nodos 1.11 y permíteles actualizarse cuando las instancias principales se actualicen a la versión 1.12.
  • Actualiza de forma manual las instancias principales y los nodos a una versión 1.12 fija.

El boletín original del 24 de junio de 2019 es el siguiente:

Actualización del 24 de junio de 2019

Desde el 22/06/2019 a las 09:40 p.m. (UTC), están disponibles las versiones de Kubernetes con parche que se indican más abajo. Las instancias principales entre las versiones 1.11.0 y 1.13.6 de Kubernetes se actualizarán de forma automática a una versión con parche. Si no ejecutas una versión compatible con este parche, actualiza a una versión de instancia principal compatible (que se mencionan a continuación) antes de actualizar tus nodos.

Debido a la gravedad de estas vulnerabilidades, ya sea que tengas habilitada o no la actualización automática de nodos, te recomendamos que actualices de forma manual los nodos y las instancias principales a una de estas versiones cuanto antes.

Las versiones con parche son las siguientes:

  • 1.11.8-gke.10
  • 1.12.7-gke.24
  • 1.12.8-gke.10
  • 1.13.6-gke.13

El boletín original del 18 de junio de 2019 es el siguiente:

Hace poco tiempo, Netflix divulgó tres vulnerabilidades de TCP de los kernels de Linux:

Estas CVE se conocen en conjunto como NFLX-2019-001.

Los kernels de Linux sin parche pueden ser vulnerables a un ataque activado a distancia de denegación del servicio. Los nodos de Google Kubernetes Engine que envían o reciben tráfico de red no confiable se ven afectados, por lo que te recomendamos seguir los pasos de mitigación que aparecen a continuación para proteger tus cargas de trabajo.

Instancias principales de Kubernetes

  • Las instancias principales de Kubernetes que usan redes autorizadas para limitar el tráfico a redes confiables no se ven afectadas.

  • Las instancias principales de los clústeres de GKE, que administra Google, obtendrán el parche de manera automática en los próximos días. No se requiere que el cliente realice ninguna acción.

Nodos de Kubernetes

Los nodos que limitan el tráfico a redes confiables no se ven afectados. Esto se refiere a un clúster con lo siguiente:

  • Los nodos con firewall para redes no confiables o sin IP públicas (clústeres privados)
  • Clústeres sin servicios públicos de LoadBalancer

Google prepara una mitigación permanente para estas vulnerabilidades que estará disponible como una versión nueva de nodo. Actualizaremos este boletín y enviaremos un correo electrónico a todos los clientes de GKE cuando la corrección permanente esté disponible.

Mientras esperamos por la corrección permanente, creamos un DaemonSet de Kubernetes que implementa mitigaciones mediante la modificación de la configuración de iptables del host.

¿Qué debo hacer?

Aplica el DaemonSet de Kubernetes a todos los nodos de tu clúster; para ello, ejecuta el comando de más abajo. Esta acción agrega una regla de iptables a las reglas de iptables existentes en el nodo para mitigar la vulnerabilidad. Ejecuta el comando una vez por clúster por proyecto de Google Cloud. 

kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

Una vez que una versión de nodo con parche esté disponible y hayas actualizado todos los nodos potencialmente afectados, podrás quitar el DaemonSet con el comando que se indica a continuación. Ejecútalo una vez por clúster por proyecto de Google Cloud. 

kubectl delete -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml
Alta
Media
Media
 CVE-2019-11477
CVE-2019-11478
CVE-2019-11479

25 de junio de 2019

Descripción Gravedad Notas

Actualización del 03/07/2019: Este parche está disponible en gcloud 253.0.0, para las versiones 1.12.9, 1.13.6, 1.14.2 y más recientes de kubectl.

Nota: El parche no está disponible en 1.11.10.

Hace poco tiempo, se descubrió una vulnerabilidad en Kubernetes, CVE-2019-11246, que permite que un atacante con acceso a una operación de kubectl cp y ejecución de código dentro de un contenedor modifique los archivos en el host. Esta vulnerabilidad podría permitir que los atacantes reemplacen o creen archivos en el sistema de archivos del host. Para obtener más detalles, consulta la divulgación de Kubernetes.

Todas las versiones de gcloud de Google Kubernetes Engine (GKE) se ven afectadas por esta vulnerabilidad, por lo que te recomendamos que actualices a la versión más reciente del parche de gcloud cuando esté disponible. Una próxima versión de parche incluirá una mitigación para esta vulnerabilidad.

¿Qué debo hacer?

Habrá una versión de parche de kubectl disponible en una próxima actualización de gcloud. También puedes actualizar kubectl directamente por tu cuenta.

Haz un seguimiento de la disponibilidad de este parche en las notas de la versión de gcloud.

¿Qué vulnerabilidad trata este parche?

La vulnerabilidad CVE-2019-11246 permite que un atacante con acceso a una operación de kubectl cp y a la ejecución de código dentro de un contenedor modifique los archivos del host. Esta vulnerabilidad podría permitir que los atacantes reemplacen o creen archivos en el sistema de archivos del host.

Alta

CVE-2019-11246

18 de junio de 2019

Descripción Gravedad Notas

Hace poco tiempo, se descubrió una vulnerabilidad en Docker, CVE-2018-15664, que permite que un atacante que puede ejecutar código dentro de un contenedor usurpe una operación de docker cp iniciada de forma externa. Esta vulnerabilidad podría permitir que un atacante cambie la ubicación en la que se escribe un archivo a una ubicación arbitraria en el sistema de archivos del host.

Todos los nodos de Google Kubernetes Engine (GKE) que ejecutan Docker se ven afectados por esta vulnerabilidad, por lo que te recomendamos que actualices a la versión más reciente del parche cuando esté disponible. Una próxima versión del parche incluirá una mitigación para esta vulnerabilidad.

Las instancias principales de Google Kubernetes Engine (GKE) más antiguas que la versión 1.12.7 ejecutan Docker y se ven afectadas por esta vulnerabilidad. En GKE, los usuarios no tienen acceso a docker cp en la instancia principal, por lo que el riesgo de esta vulnerabilidad es limitado en las instancias principales de GKE.

¿Qué debo hacer?

Solo los nodos que ejecutan Docker se ven afectados y solo cuando se emite un comando docker cp (o equivalente de API) que puede usurparse. Se espera que esta situación sea bastante inusual en los entornos de Kubernetes. Los nodos que ejecutan COS con containerd no se ven afectados.

Con el fin de actualizar tus nodos, primero debes actualizar tu instancia principal a la versión con parche. Cuando el parche esté disponible, podrás iniciar una actualización de instancia principal o esperar que Google la actualice de manera automática. El parche estará disponible en Docker 18.09.7, que se incluye en un próximo parche de GKE. Este parche solo estará disponible para la versión 1.13 de GKE y posteriores.

Actualizaremos las instancias principales del clúster a la versión con parche de manera automática, a la frecuencia de actualización habitual. También puedes iniciar una actualización de instancias principales por tu cuenta después de que esté disponible la versión con parche.

Actualizaremos este boletín con las versiones que contienen un parche una vez que estén disponibles. Haz un seguimiento de la disponibilidad de estos parches en las notas de la versión.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2018-15664 permite que un atacante que puede ejecutar código dentro de un contenedor usurpe una operación docker cp iniciada de forma externa. Esta vulnerabilidad podría permitir que un atacante cambie la ubicación en la que se escribe un archivo a una ubicación arbitraria en el sistema de archivos del host.

Alta

31 de mayo de 2019

Descripción Gravedad Notas

Este boletín se actualizó desde su publicación original.

Actualización del 2 de agosto de 2019

Al momento del boletín inicial, solo las versiones de 1.13.6-gke.0 a 1.13.6-gke.5 se vieron afectadas. Debido a una regresión, todas las versiones 1.13.6.x ahora se ven afectadas. Si ejecutas la versión 1.13.6, actualiza a 1.13.7 cuanto antes.

El proyecto de Kubernetes divulgó la vulnerabilidad CVE-2019-11245 en los kubelet v1.13.6 y v1.14.2, que puede hacer que los contenedores se ejecuten como UID 0 (en general, mapea al usuario root), incluso si se especifica un usuario diferente en la imagen del contenedor. Si tus contenedores se ejecutan como un usuario diferente del usuario raíz y ejecutas una versión de nodo de 1.13.6-gke.0 a 1.13.6-gke.6, te recomendamos que configures RunAsUser en todos los pods del clúster cuyos contenedores no deban ejecutarse como UID 0.

Si se especifica un valor de USER distinto del usuario raíz (por ejemplo, mediante la configuración del valor de USER en un Dockerfile), se produce un comportamiento inesperado. Cuando un contenedor se ejecuta por primera vez en un nodo, este respetará el UID especificado de forma correcta. Sin embargo, debido a este defecto, la segunda vez que se ejecuta (y las posteriores), el contenedor se ejecuta como UID 0 sin considerar el UID que se especificó. Por lo general, este es un privilegio elevado no deseado y puede conllevar un comportamiento imprevisto de las aplicaciones.

¿Cómo puedo saber si ejecuto una versión afectada?

Ejecuta el siguiente comando para crear una lista de todos los nodos y sus versiones de kubelet:

kubectl get nodes -o=jsonpath='{range .items[*]}'\
'{.status.nodeInfo.machineID}'\
'{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

Si el resultado menciona las versiones de kubelet incluidas abajo, tus nodos se ven afectados:

  • v1.13.6
  • v1.14.2
¿Cómo puedo saber si mi configuración específica se ve afectada?

Si tus contenedores se ejecutan como un usuario distinto del usuario raíz y ejecutas las versiones de nodo de 1.13.6-gke.0 a 1.13.6-gke.6, te verás afectado, excepto en los siguientes casos:

  • Los pods que especifican un valor que es válido y que no es raíz para el PodSecurityContext de runAsUser no se ven afectados y siguen funcionando según lo previsto.
  • Las PodSecurityPolicies que aplican una configuración de runAsUser tampoco se ven afectadas y siguen funcionando según lo previsto.
  • Los pods que especifican mustRunAsNonRoot:true no se iniciarán como UID 0, pero no podrán iniciarse cuando los afecte este problema.
¿Qué debo hacer?

Configura el contexto de seguridad RunAsUser en todos los pods del clúster que no deberían ejecutarse como UID 0. Puedes aplicar esta configuración con una PodSecurityPolicy.

Medio CVE-2019-11245

14 de mayo de 2019

Descripción Gravedad Notas

Actualización del 11/06/2019: El parche está disponible en las versiones 1.11.10-gke.4, 1.12.8-gke.6 y 1.13.6-gke.5 actualizadas durante la semana del 28/05/2019 y en versiones más recientes.

Intel divulgó las siguientes CVE:

Estas CVE se conocen en conjunto como Muestreo de datos de microarquitectura (MDS). Estas vulnerabilidades pueden hacer que los datos se expongan cuando la ejecución especulativa interactúa con el estado de la microarquitectura. Para obtener más detalles, consulta la divulgación de Intel.

La infraestructura del host que ejecuta Kubernetes Engine aísla las cargas de trabajo del cliente entre sí. A menos que ejecutes código no confiable dentro de tus propios clústeres de GKE de instancias múltiples, no te verás afectado.

En el caso de los clientes que ejecutan código no confiable en sus propios servicios de instancias múltiples dentro de Kubernetes Engine, esta representa una vulnerabilidad muy grave. Para mitigarla en Kubernetes Engine, debes inhabilitar los hipersubprocesos en tus nodos. Solo los nodos de Google Kubernetes Engine (GKE) que usan varias CPU se ven afectados por estas vulnerabilidades. Ten en cuenta que las VM n1-standard-1 (la predeterminada de GKE), g1-small y f1-micro solo exponen 1 CPU virtual al entorno de invitado, de modo que no es necesario inhabilitar los hipersubprocesos.

Se incluirán protecciones adicionales para habilitar la funcionalidad de vaciado en la próxima versión de parche. Actualizaremos las instancias principales y los nodos con la actualización automática a la versión con parche en las próximas semanas, a la frecuencia de actualización habitual. Tener solo el parche no es suficiente para mitigar la exposición a esta vulnerabilidad. Consulta la información que aparece a continuación para conocer las acciones recomendadas.

Si ejecutas GKE On-Prem, es posible que te veas afectado dependiendo del hardware que uses. Consulta la divulgación de Intel.

¿Qué debo hacer?

A menos que ejecutes código no confiable dentro de tus propios clústeres de GKE de instancias múltiples, no te verás afectado.

En el caso de los nodos de Kubernetes Engine, crea grupos de nodos nuevos con los hipersubprocesos inhabilitados y vuelve a programar las cargas de trabajo en los nodos nuevos.

Ten en cuenta que las VM n1-standard-1, g1-small y f1-micro solo exponen 1 CPU virtual al entorno de invitado, de modo que no es necesario inhabilitar los hipersubprocesos.

Advertencia:
  • La inhabilitación de los hipersubprocesos puede tener un impacto grave en el rendimiento de tus clústeres y la aplicación. Asegúrate de que esto es aceptable antes de implementar esta opción en tus clústeres de producción.
  • Los hipersubprocesos se pueden inhabilitar a nivel del grupo de nodos de GKE con la implementación de un DaemonSet. Sin embargo, implementar este DaemonSet hará que todos tus nodos en el grupo de nodos se reinicien al mismo tiempo. Por lo tanto, se recomienda crear un grupo de nodos nuevo en el clúster, implementar el DaemonSet para inhabilitar los hipersubprocesos en ese grupo y, luego, migrar tus cargas de trabajo al grupo de nodos nuevo.

Haz lo siguiente para crear un grupo de nodos nuevo con hipersubprocesos inhabilitados:

  1. Crea un grupo de nodos nuevo en tu clúster con la etiqueta de nodo cloud.google.com/gke-smt-disabled=true, como se indica a continuación: 
    gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true
  2. Implementa el DaemonSet en este grupo de nodos nuevo. El DaemonSet solo se ejecutará en nodos con la etiqueta cloud.google.com/gke-smt-disabled=true. Este inhabilitará los hipersubprocesos y, luego, reiniciará el nodo. 
    kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
  3. Asegúrate de que los pods del DaemonSet estén en estado de ejecución. 
    kubectl get pods --selector=name=disable-smt -n kube-system

    Deberías obtener una respuesta similar a la siguiente:

    NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m
  4. Verifica que aparezca el mensaje “Se inhabilitó SMT” en los registros de los Pods. 
    kubectl logs disable-smt-2xnnc disable-smt -n kube-system

Debes mantener el DaemonSet en ejecución en los grupos de nodos, de manera que se apliquen los cambios automáticamente a los nodos nuevos que se creen en el grupo. La creación de nodos puede activarse mediante la reparación automática, la actualización manual o automática o con el ajuste de escala automático.

Para volver a habilitar los hipersubprocesos, será necesario que vuelvas a crear el grupo de nodos sin implementar el DaemonSet proporcionado y migres tus cargas de trabajo al grupo de nodos nuevo.

También te recomendamos que actualices los nodos de forma manual una vez que el parche esté disponible. Para poder actualizar, primero debes actualizar tu instancia principal a la versión más reciente. Las instancias principales de GKE se actualizarán de forma automática a la frecuencia de actualización habitual.

Actualizaremos este boletín con las versiones que contengan el parche cuando estén disponibles.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: Estas vulnerabilidades aprovechan la ejecución especulativa. Estas CVE se conocen en conjunto como Muestreo de datos de microarquitectura. Estas vulnerabilidades pueden hacer que los datos se expongan cuando la ejecución especulativa interactúa con el estado de la microarquitectura. 		Medio

5 de abril de 2019

Descripción Gravedad Notas

Hace poco tiempo, se descubrieron las vulnerabilidades de seguridad CVE-2019-9900 y CVE-2019-9901 en Envoy.

Istio incorpora Envoy, y estas vulnerabilidades permiten que la política de Istio se omita en algunos casos.

Si habilitaste Istio en Google Kubernetes Engine (GKE), es posible que estas vulnerabilidades te afecten. Recomendamos que actualices los clústeres afectados a la versión de parche más reciente cuanto antes, además de actualizar los archivos adicionales de Istio (las instrucciones se encuentran más abajo).

¿Qué debo hacer?

Debido a la gravedad de estas vulnerabilidades, ya sea que hayas habilitado las actualizaciones automáticas de nodos o no, te recomendamos hacer lo siguiente:

  1. Actualiza de forma manual tu clúster apenas el parche esté disponible.
  2. Sigue las instrucciones de la documentación para actualizar archivos adicionales a fin de realizar este proceso.

Las versiones de parche estarán disponibles para todos los proyectos de GKE antes de las 7:00 p.m. PDT de hoy.

Este parche estará disponible en las versiones de GKE que se mencionan abajo. Los clústeres nuevos usarán la versión de parche de forma predeterminada cuando se anuncie en la página de boletines de seguridad de GKE el 15 de abril de 2019, según se estima. Si creas un clúster nuevo antes de esa fecha, deberás especificar la versión de parche que debe usar. En el caso de los clientes de GKE que habilitaron las actualizaciones automáticas de los nodos y que no realizan actualizaciones manuales, sus nodos se actualizarán de forma automática a versiones de parche durante la siguiente semana.

Versiones con parches:

  • 1.10.12-gke.14
  • 1.11.6-gke.16
  • 1.11.7-gke.18
  • 1.11.8-gke.6
  • 1.12.6-gke.10
  • 1.13.4-gke.10

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2019-9900 y CVE-2019-9901. Puedes obtener más información sobre estas en el blog de Istio.

Alta

1 de marzo de 2019

Descripción Gravedad Notas

Actualización del 22/03/2019: Este parche está disponible en las versiones de Kubernetes 1.11.8-gke.4, 1.13.4-gke.1 y en las más recientes. El parche aún no está disponible en la versión 1.12. Haz un seguimiento de la disponibilidad de estos parches en las notas de la versión.

Hace poco tiempo, se descubrió una vulnerabilidad nueva de denegación del servicio en Kubernetes, CVE-2019-1002100, que permite que los usuarios con autorización para crear solicitudes de parche puedan desarrollar solicitudes “json-patch” malintencionadas que consumen cantidades excesivas de CPU y memoria en el servidor de la API de Kubernetes, lo que podría reducir la disponibilidad del plano de control de los clústeres. Para obtener más detalles, consulta la divulgación de Kubernetes. Esta vulnerabilidad afecta a todas las instancias principales de Google Kubernetes Engine (GKE). Una próxima versión del parche incluirá una mitigación para esta vulnerabilidad. Actualizaremos las instancias principales de los clústeres a la versión que incluye el parche de manera automática durante las próximas semanas según la frecuencia de actualización habitual.

¿Qué debo hacer?

No es necesario que realices ninguna acción. Las instancias principales de GKE se actualizarán de forma automática según la frecuencia de actualización habitual. Si quieres actualizar la instancia principal antes, puedes iniciar de forma manual una actualización de esta instancia.

Actualizaremos este boletín con las versiones que contienen un parche. Ten en cuenta que el parche solo estará disponible en las versiones 1.11 y superiores, no en la versión 1.10.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2019-1002100 permite que un usuario desarrolle, en especial, un parche de tipo “json-patch” que consuma cantidades excesivas de CPU en el servidor de la API de Kubernetes, lo que puede reducir la disponibilidad del plano de control de los clústeres.

 Medio CVE-2019-1002100

11 de febrero de 2019 (runc)

Descripción Gravedad Notas

Open Containers Initiative (OCI) descubrió hace poco tiempo una vulnerabilidad de seguridad nueva (CVE-2019-5736) en runc, que permite obtener privilegios de administrador en el nodo host mediante un escape de contenedor.

Esta vulnerabilidad afecta a los nodos de Google Kubernetes Engine (GKE) que ejecutan Ubuntu, por lo que te recomendamos que actualices a la versión más reciente del parche cuanto antes. Para ello, sigue las instrucciones que se detallan a continuación.

¿Qué debo hacer?

Para actualizar los nodos, primero debes actualizar el nodo principal a la versión más reciente. Este parche está disponible en Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 y actualizaciones más recientes. Puedes hacer un seguimiento de la disponibilidad de estos parches en las notas de la versión.

Ten en cuenta que la vulnerabilidad solo afecta a los nodos de GKE que ejecutan Ubuntu y no a los que ejecutan COS.

Ten en cuenta que la versión nueva de runc consume más memoria, por lo que es posible que debas actualizar la cantidad de memoria asignada a los contenedores si configuraste límites de memoria bajos (menores que 16 MB).

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

CVE-2019-5736 es una vulnerabilidad en runc que permite que un contenedor malintencionado reemplace el objeto binario runc del host con una interacción del usuario mínima mediante un ejecutable para lograr la ejecución de código con permisos de administrador en el nodo host. Los contenedores que se ejecutan sin permisos de administrador no se ven afectados. Esta vulnerabilidad de seguridad tiene una calificación de gravedad alta.

 Alta CVE-2019-5736

11 de febrero de 2019 (Go)

Descripción Gravedad Notas

Actualización del 25/02/2019: El parche no está disponible en la versión 1.11.7-gke.4 como se informó anteriormente. Si ejecutas la versión 1.11.7, puedes cambiar a la versión inferior (1.11.6) y actualizar a 1.12, o esperar hasta que el parche de 1.11.7 esté disponible durante la semana del 4 de marzo de 2019.

Recientemente, se descubrió la vulnerabilidad de seguridad CVE-2019-6486 en el lenguaje de programación Go, que corresponde a una vulnerabilidad de denegación del servicio (DoS) en las implementaciones de criptografía de las curvas elípticas P-521 y P-384. En Google Kubernetes Engine (GKE), esta vulnerabilidad podría permitir que un usuario desarrolle solicitudes malintencionadas que consuman cantidades excesivas de CPU en el servidor de la API de Kubernetes, lo que podría reducir la disponibilidad del plano de control de los clústeres. Para obtener más detalles, consulta la divulgación del lenguaje de programación Go.

Esta vulnerabilidad afecta a todas las instancias principales de Google Kubernetes Engine (GKE). La versión más reciente del parche incluye una mitigación contra esta vulnerabilidad. Actualizaremos las instancias principales de los clústeres a la versión que incluye el parche de manera automática durante las próximas semanas según la frecuencia de actualización habitual.

¿Qué debo hacer?

No es necesario que realices ninguna acción. Las instancias principales de GKE se actualizarán de forma automática según la frecuencia de actualización habitual. Si quieres actualizar la instancia principal antes, puedes iniciar de forma manual una actualización de esta instancia.

Este parche está disponible en GKE 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 y actualizaciones más recientes.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

CVE-2019-6486 es una vulnerabilidad de las implementaciones de criptografía de las curvas elípticas P-521 y P-384 que permite que un usuario desarrolle entradas que consuman cantidades excesivas de CPU.

Alta CVE-2019-6486

3 de diciembre de 2018

Descripción Gravedad Notas

Kubernetes recientemente descubrió una nueva vulnerabilidad en la seguridad CVE-2018-1002105, que autorizaba a un usuario con privilegios relativamente bajos a omitir la autorización de las API de kubelet y lo habilitaba a ejecutar operaciones arbitrarias para cualquier pod de cualquier nodo en el clúster. Para obtener más detalles, consulta la divulgación de Kubernetes. Todas las instancias principales de Google Kubernetes Engine (GKE) se vieron afectadas por estas vulnerabilidades, y ya hemos actualizado los clústeres a las versiones más recientes del parche. No es necesario que realices ninguna acción.

¿Qué debo hacer?

No es necesario que realices ninguna acción. Ya se actualizaron las instancias principales de GKE.

Este parche está disponible en GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5, 1.11.2-gke.18 y las versiones más recientes.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2018-1002105 permite que un usuario con privilegios relativamente bajos omita la autorización de las API de kubelet. Esto le permite al usuario realizar solicitudes de actualización para escalar y realizar llamadas arbitrarias a la API de kubelet. Esto está calificado como una vulnerabilidad crítica en Kubernetes. Debido a ciertos detalles en la implementación de GKE que impidieron la ruta de escalamiento no autenticada, se lo calificó como vulnerabilidad alta.

Alta CVE-2018-1002105

13 de noviembre de 2018

Descripción

Actualización del 16/11/2018: Se completó la revocación y rotación de todos los tokens posiblemente afectados. No es necesario que realices ninguna otra acción.

Recientemente, Google descubrió un problema en el complemento de la Interfaz de la Red del Contenedor (CNI) Calico que puede, en ciertas configuraciones, registrar información sensible. La Asesoría Técnica Tigera está controlando este problema, con el código TTA-2018-001.

  • Cuando se ejecuta con el registro de nivel de depuración, el complemento de la CNI Calico escribe la configuración del cliente de la API de Kubernetes en los registros.
  • La CNI Calico también escribirá el token de la API de Kubernetes en los registros en el nivel de información si el campo “k8s_auth_token” se ha establecido en la configuración de la red CNI.
  • Además, cuando se ejecuta con el registro de nivel de depuración, si el token de la cuenta de servicio se establece de manera explícita, ya sea en el archivo de configuración de Calico que lee Calico o como variables de entorno que usa Calico, los componentes de Calico (calico/node, felix, CNI) escriben esta información en los archivos de registro.

Estos tokens tienen los siguientes permisos:

 
bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]

Los clústeres de Google Kubernetes Engine con una Política de red del clúster y Stackdriver Logging habilitado registraron tokens de cuenta de servicio Calico en Stackdriver. Los clústeres sin la Política de red habilitada no se ven afectados.

Hemos implementado una solución que migra el complemento de la CNI Calico para que solo acceda en el nivel de advertencia y utilice una nueva cuenta de servicio. El código Calico con el parche se implementará en una versión posterior.

Durante la próxima semana, realizaremos una revocación progresiva de todos los tokens potencialmente afectados. Este boletín se actualizará cuando se haya completado la revocación. No se requiere ninguna otra acción de tu parte. (Esta rotación se completó el 16/11/2018).

Si deseas rotar estos tokens de inmediato, puedes ejecutar el siguiente comando; el nuevo secreto correspondiente a la cuenta de servicio debería volver a crearse de forma automática en unos segundos:

 
kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system

Detección

GKE registra todos los accesos en el servidor de la API. Para determinar si se utilizó un token de Calico fuera del rango de IP esperado de Google Cloud, puedes ejecutar la siguiente consulta de Stackdriver. Ten en consideración que esto solo mostrará los registros de llamadas realizadas desde afuera de la red de GCP. Recomendamos que lo personalices según las necesidades de tu entorno específico. 

resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")

14 de agosto de 2018

Descripción Gravedad Notas

Intel ha divulgado las siguientes CVE:

A estas CVE se hace referencia de forma colectiva como "Falla de terminal L1 (L1TF)".

Estas vulnerabilidades L1TF explotan la ejecución especulativa, ya que atacan la configuración de estructuras de datos en el procesador. "L1" hace referencia a la caché de Datos de nivel 1 (L1D), un recurso pequeño del núcleo que se utiliza para acelerar el acceso a la memoria.

Consulta la entrada de blog de Google Cloud para obtener más detalles sobre estas vulnerabilidades y la mitigación de Compute Engine.

El impacto de Google Kubernetes Engine

La infraestructura que ejecuta Kubernetes Engine y aísla los clústeres y nodos del cliente de sí mismos está protegida frente a ataques conocidos.

Los grupos de nodos de Kubernetes Engine que utilizan una imagen de Container-Optimized OS de Google y que tienen la actualización automática habilitada se actualizarán automáticamente a las versiones con parches de nuestra imagen COS ni bien estén disponibles a partir de la semana del 20-08-2018.

Los grupos de nodos de Kubernetes Engine que no tengan la actualización automática habilitada deberán actualizarse de forma manual cuando estén disponibles las versiones con parche de nuestra imagen COS.

 Alta

6 de agosto de 2018; última actualización: 5 de septiembre de 2018

Descripción Gravedad Notas

Actualización del 05-09-2018

CVE-2018-5391 se divulgó recientemente. Al igual que con CVE-2018-5390, se trata de una vulnerabilidad de la red en el kernel que aumenta la efectividad de los ataques de denegación del servicio (DoS) contra sistemas vulnerables. La diferencia principal es que se puede utilizar CVE-2018-5391 en conexiones IP. Actualizamos este boletín para que abarque ambas vulnerabilidades.

Descripción

CVE-2018-5390 ("SegmentSmack") describe una vulnerabilidad de la red en el kernel que aumenta la efectividad de los ataques de denegación del servicio (DoS) contra sistemas vulnerables a través de conexiones de TCP.

CVE-2018-5391 ("FragmentSmack") describe una vulnerabilidad de la red en el kernel que aumenta la efectividad de los ataques de denegación del servicio (DoS) contra sistemas vulnerables a través de conexiones IP.

El impacto de Google Kubernetes Engine

A partir del 11-08-2018, todos los principales de Kubernetes Engine están protegidos contra ambas vulnerabilidades. Además, todos los clústeres de Kubernetes Engine configurados para actualizarse de forma automática también están protegidos contra ambas vulnerabilidades. Los grupos de nodos de Kubernetes Engine que no estén configurados para actualizarse de forma automática, y se actualizaron de forma manual por última vez antes del 11/08/2018, están afectados por ambas vulnerabilidades.

Versiones con parches

Debido a la gravedad de esta vulnerabilidad, te recomendamos actualizar manualmente tus nodos ni bien esté disponible el parche.

Alta

30 de mayo de 2018

Descripción Gravedad Notas

Recientemente, se descubrió una vulnerabilidad en Git que podría permitir la elevación de privilegios en Kubernetes si usuarios sin privilegios tienen permitido crear pods con volúmenes gitRepo. La CVE se identifica con la etiqueta CVE-2018-11235.

¿Me veo afectado?

Esta vulnerabilidad te afecta si todas las siguientes afirmaciones son verdaderas:

  • Los usuarios que no son de confianza pueden crear pods (o activar su creación).
  • Los pods creados por usuarios que no son de confianza tienen restricciones que impiden el acceso a la raíz del host (por ejemplo, mediante PodSecurityPolicy).
  • Los pods creados por usuarios que no son de confianza pueden usar el tipo de volumen gitRepo.

Todos los nodos de Kubernetes Engine son vulnerables.

¿Qué debo hacer?

Prohíbe el uso del tipo de volumen gitRepo. Para prohibir los volúmenes gitRepo con PodSecurityPolicy, omite gitRepo de la lista de anunciantes permitidos volumes en tu PodSecurityPolicy.

Se pueden lograr comportamientos equivalentes del volumen gitRepo si se clona un repositorio de Git en un volumen EmptyDir de un initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

¿Qué parche trata esta vulnerabilidad?

Se incluirá un parche en una próxima versión de Kubernetes Engine. Vuelve a visitar este sitio para obtener más detalles.

Media

21 de mayo de 2018

Descripción Gravedad Notas

Recientemente, se descubrieron diferentes vulnerabilidades en el kernel de Linux que podrían permitir la elevación de privilegios o la denegación del servicio (mediante el fallo del kernel) desde un proceso sin privilegios. Estas CVE se identifican con las etiquetas CVE-2018-1000199, CVE-2018-8897 y CVE-2018-1087. Todos los nodos de Kubernetes Engine se ven afectados por estas vulnerabilidades. Te recomendamos actualizar a la versión más reciente del parche, como se muestra a continuación.

¿Qué debo hacer?

Para poder llevar a cabo la actualización, primero debes actualizar tu instancia principal a la versión más reciente. El parche está disponible en Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1 y Kubernetes Engine 1.10.2-gke.1. Estas versiones incluyen parches para imágenes de Container-Optimized OS y Ubuntu.

Si creas un clúster nuevo antes, debes especificar la versión con parche que debe usarse. A los clientes que tengan las actualizaciones automáticas de nodo habilitadas y no hagan la actualización de forma manual, se les actualizarán los nodos a la versión con parche en las próximas semanas.

¿Qué vulnerabilidades corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2018-1000199: Esta vulnerabilidad afecta el kernel de Linux. Permite que un usuario o proceso sin privilegios genere una falla en el kernel del sistema, lo que lleva a un ataque DoS o elevación de privilegios. Tiene una calificación de vulnerabilidad alta, con un CVSS de 7.8.

CVE-2018-8897: Esta vulnerabilidad afecta el kernel de Linux. Permite que un usuario o proceso sin privilegios genere una falla en el kernel del sistema, lo que lleva a un ataque DoS. Tiene una calificación de vulnerabilidad media, con un CVSS de 6.5.

CVE-2018-1087: Esta vulnerabilidad afecta el hipervisor KVM del kernel de Linux. Permite que un proceso sin privilegios genere una falla en el kernel invitado o que, potencialmente, adquiera privilegios. La vulnerabilidad tiene un parche en la infraestructura sobre la que se ejecuta Kubernetes Engine, por lo que Kubernetes Engine no se ve afectado. Tiene una calificación de vulnerabilidad alta, con un CVSS de 8.0.

Alta

12 de marzo de 2018

Descripción Gravedad Notas

El proyecto Kubernetes divulgó hace poco tiempo vulnerabilidades de seguridad nuevas, CVE-2017-1002101 y CVE-2017-1002102, que permiten que los contenedores accedan a archivos externos. Todos los nodos de Kubernetes Engine se ven afectados por estas vulnerabilidades. Te recomendamos actualizar a la versión más reciente del parche tan pronto como sea posible, como se muestra a continuación.

¿Qué debo hacer?

Debido a la gravedad de estas vulnerabilidades, ya sea que tengas o no las actualizaciones automáticas de nodos habilitadas, recomendamos que actualices manualmente tus nodos ni bien esté disponible el parche. Este parche estará disponible para todos los clientes a partir del 16 de marzo, pero puede que esté disponible para ti antes, según la zona en la que se encuentra tu clúster, en función del programa de actualizaciones.

Para poder llevar a cabo la actualización, primero debes actualizar tu instancia principal a la versión más reciente. Este parche estará disponible en Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 y Kubernetes 1.7.14-gke.1. Los nuevos clústeres usarán la versión con parche de forma predeterminada antes del 30 de marzo; si creas un clúster nuevo antes, debes especificar la versión con parche que debe usarse.

A los clientes de Kubernetes Engine que tengan las actualizaciones automáticas de nodos habilitadas y no hagan la actualización manualmente, se les actualizarán los nodos a la versión con parche antes del 23 de abril. Sin embargo, debido a la gravedad de estas vulnerabilidades, recomendamos que actualices de forma manual tus nodos en cuanto esté disponible el parche.

¿Qué vulnerabilidades corrige este parche?

Este parche mitiga las siguientes dos vulnerabilidades:

La vulnerabilidad CVE-2017-1002101 permite que los contenedores que utilizan activaciones de volumen de subruta tengan acceso a archivos externos al volumen. Eso significa que si estás bloqueando acceso al contenedor a volúmenes de la ruta del host con PodSecurityPolicy, un atacante con la capacidad para actualizar o crear pods puede activar cualquier ruta del host mediante cualquier otro tipo de volumen.

La vulnerabilidad CVE-2017-1002102 permite que los contenedores que utilizan ciertos tipos de volúmenes (incluidos los secretos, mapas de configuración, volúmenes proyectados o volúmenes de la API descendentes) borren archivos externos al volumen. Esto significa que si un contenedor que utiliza uno de estos tipos de volúmenes se ve comprometido, o si permites que usuarios que no son de confianza creen pods, un atacante podría usar ese contenedor para borrar archivos arbitrarios en el host.

Para obtener más información sobre la solución, lee la entrada de blog de Kubernetes.

Alta

Boletines de seguridad de Google Distributed Cloud

16 de octubre de 2019

Descripción Gravedad Notas

Hace poco, se descubrió una vulnerabilidad en Kubernetes, que se describe en CVE-2019-11253, que permite que cualquier usuario autorizado realice solicitudes POST para ejecutar un ataque remoto de denegación del servicio a un servidor de la API de Kubernetes. El comité de seguridad de los productos (PSC) de Kubernetes difundió información adicional sobre esta vulnerabilidad, que puedes encontrar aquí.

Puedes mitigar esta vulnerabilidad si limitas los clientes tienen acceso a la red de los servidores de la API de Kubernetes.

¿Qué debo hacer?

Te recomendamos que actualices el clúster a una versión del parche en la que se incluya la solución en cuanto esté disponible.

Las versiones del parche en las que se incluirá la solución se enumeran a continuación:

  • GKE Enterprise 1.1.1, que ejecuta la versión 1.13.7-gke.30 de Kubernetes
¿Qué vulnerabilidad trata este parche?

Mediante el parche, se mitiga la siguiente vulnerabilidad: CVE-2019-11253.

Alta

CVE-2019-11253

23 de agosto de 2019

Descripción Gravedad Notas

Hace poco, descubrimos y mitigamos una vulnerabilidad en la que el proxy de RBAC que se usa para proteger los extremos de supervisión no autorizaba a los usuarios de forma adecuada. Como resultado, los usuarios no autorizados pueden obtener métricas de ciertos componentes desde la red interna del clúster. Los siguientes componentes se vieron afectados:

  • etcd
  • etcd-events
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • node-exporter
  • kube-state-metrics
  • prometheus
  • alertmanager
¿Qué debo hacer?

Te recomendamos que actualices los clústeres a la versión 1.0.2-gke.3, en la que se incluye el parche para esta vulnerabilidad, lo antes posible.

Medio

Versiones de Google Distributed Cloud

22 de agosto de 2019

Descripción Gravedad Notas

Hace poco tiempo, se descubrió una vulnerabilidad en Kubernetes, CVE-2019-11247, que permite que se actúe sobre instancias de recursos personalizados de alcance de clúster como si fueran objetos con espacios de nombres existentes en todos los espacios de nombres. Esto significa que las cuentas de usuario y de servicio solo deben contar con permisos de RBAC a nivel de espacio de nombres para interactuar con recursos personalizados de alcance de clúster. A fin de aprovechar esta vulnerabilidad, el atacante debe tener privilegios para acceder al recurso en cualquier espacio de nombres.

¿Qué debo hacer?

Te recomendamos que actualices los clústeres a la versión 1.0.2-gke.3, en la que se incluye el parche para esta vulnerabilidad, lo antes posible.

¿Qué vulnerabilidad trata este parche?

El parche mitiga la siguiente vulnerabilidad: CVE-2019-11247.

Medio

CVE-2019-11247