Archivo de boletines de seguridad

Esta página contiene un archivo histórico de todos los boletines de seguridad anteriores al 2020 de 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 del 2019

Publicación: 14/11/2019
Última actualización: 14/11/2019
Descripción Gravedad Notas

En Kubernetes, se ha descubierto un problema de seguridad en los contenedores adicionales external-provisioner, external-snapshotter y external-resizer de kubernetes-csi que afecta a la mayoría de las versiones de los contenedores adicionales incluidos en los controladores de Container Storage Interface (CSI). Para obtener más información, consulta el aviso que ha publicado Kubernetes al respecto.

¿Qué debo hacer?
Esta vulnerabilidad no afecta a ningún componente de GKE gestionado. Es posible que te afecte si gestionas tus propios controladores de CSI en clústeres alfa de GKE con la versión 1.12 de GKE o una posterior. Si tienes este problema, ponte en contacto con tu proveedor de controladores de CSI para que te indique cómo llevar a cabo la actualización.

¿Qué vulnerabilidades mitiga este parche?
CVE-2019-11255: esta CVE es una vulnerabilidad de los contenedores adicionales kubernetes-csi external-provisioner, external-snapshotter y external-resizer que puede permitir el acceso o la modificación de datos sin autorización. Esto afecta a la mayoría de las versiones de contenedores adicionales incluidos en controladores de CSI.

Medio

CVE-2019-11255

12 de noviembre del 2019

Publicación: 12/11/2019
Última actualización: 12/11/2019
Descripción Gravedad Notas

Intel ha descubierto varias CVE que pueden permitir interacciones entre la ejecución especulativa y el estado de microarquitectura para exponer datos. Para obtener más información, consulta el aviso que ha publicado Intel al respecto.

La infraestructura del host que ejecuta Kubernetes Engine aísla las cargas de trabajo de los clientes. No es necesario que tomes ninguna medida, salvo si ejecutas código no fiable en tus propios clústeres de varios propietarios de GKE y usas nodos N2, M2 o C2. Si usas instancias de GKE en nodos N1, tampoco deberás tomar ninguna medida adicional.

Si utilizas Google Distributed Cloud, la exposición dependerá del hardware. Compara tu infraestructura con la que se detalla en el aviso de Intel.

¿Qué debo hacer?

Esta situación te afectará únicamente si usas grupos de nodos N2, M2 o C2 y estos ejecutan código no fiable dentro de tus propios clústeres de varios propietarios de GKE.

Reinicia los nodos para que se aplique el parche. La forma más sencilla de reiniciar todos los nodos de tu grupo de nodos es usar la operación de actualización. De este modo, se fuerza el reinicio de todos los grupos de nodos afectados.

¿Qué vulnerabilidades trata este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE-2019-11135: esta CVE también se denomina TSX Async Abort (TAA). TAA proporciona otra vía para la filtración externa de datos usando las mismas estructuras de datos de microarquitectura que fueron vulnerables ante el muestreo de datos de microarquitectura (MDS).

CVE-2018-12207: es una vulnerabilidad de denegación de servicio (DoS) que afecta a los hosts de máquinas virtuales y hace que un invitado malicioso provoque un fallo en un host que no está protegido. Esta CVE también se denomina "Machine Check Error on Page Size Change" (Error de comprobación de máquina al cambiar el tamaño de página) y no afecta a GKE.

Medio

CVE-2019-11135
CVE-2018-12207

22 de octubre del 2019

Publicación: 22/10/2019
Última actualización: 22/10/2019
Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad en el lenguaje de programación Go, descrita en la CVE-2019-16276. Puede afectar a las configuraciones de Kubernetes que usan un proxy de autenticación. Para obtener más información, consulta el aviso que ha publicado Kubernetes al respecto.

Kubernetes Engine no permite configurar un proxy de autenticación, por lo que no se ve afectado por esta vulnerabilidad.

Ninguno

CVE-2019-16276

16 de octubre del 2019

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 ya están disponibles en todas las zonas.

Hace poco se ha descubierto una vulnerabilidad en Kubernetes, descrita en la CVE-2019-11253, que permite que cualquier usuario autorizado envíe solicitudes POST para ejecutar un ataque remoto de denegación de servicio en un servidor de API de Kubernetes. El Comité de Seguridad de Producto (PSC) de Kubernetes ha publicado información adicional sobre esta vulnerabilidad.

Los clústeres de GKE que usan redes maestras autorizadas y clústeres privados sin punto de conexión público mitigan esta vulnerabilidad.

¿Qué debo hacer?

Te recomendamos que actualices tu clúster en cuanto haya disponible una versión del parche que contenga la corrección. Está previsto que el parche esté disponible en todas las zonas con el lanzamiento de la versión de GKE programado para la semana del 14 de octubre.

A continuación se indican las versiones de parches que contendrán la mitigación:

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

Este parche mitiga las siguientes vulnerabilidades:

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

Alta

CVE-2019-11253

16 de septiembre del 2019

Publicación: 16/09/2019
Última actualización: 16/10/2019
Descripción Gravedad Notas

Este boletín se ha actualizado desde su publicación original.

Hace poco se han descubierto nuevas vulnerabilidades de denegación de servicio (DoS) con el lenguaje de programación Go: las CVE-2019-9512 y CVE-2019-9514. En GKE, estas vulnerabilidades podrían permitir que un usuario cree solicitudes maliciosas que usen excesivamente la CPU en el servidor de API de Kubernetes, lo que puede reducir la disponibilidad del plano de control del clúster. Para obtener más información, consulta el aviso del lenguaje de programación Go que se ha publicado al respecto.

¿Qué debo hacer?

Te recomendamos que actualices el clúster a la versión más reciente del parche en cuanto esté disponible, ya que contiene la mitigación de esta vulnerabilidad. De acuerdo con el calendario de actualizaciones, está previsto que el parche esté disponible en todas las zonas con la próxima versión de GKE.

A continuación se indican las versiones de parches que contendrán la mitigación:

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

Este parche mitiga las siguientes vulnerabilidades:

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

Alta

CVE-2019-9512
CVE-2019-9514

5 de septiembre del 2019

Publicación: 05/09/2019
Última actualización: 05/09/2019

Se ha actualizado el boletín sobre la corrección de la vulnerabilidad que se publicó el 31 de mayo del 2019.

22 de agosto del 2019

Publicación: 22/08/2019
Última actualización: 22/08/2019

Se ha actualizado el boletín del 5 de agosto del 2019. Ya está disponible la corrección de la vulnerabilidad que se mencionaba en el boletín anterior.

8 de agosto del 2019

Publicación: 08/08/2019
Última actualización: 08/08/2019

Se ha actualizado el boletín del 5 de agosto del 2019. Está previsto que la corrección de la vulnerabilidad incluida en dicho boletín esté disponible en la próxima versión de GKE.

5 de agosto del 2019

Publicación: 05/08/2019
Última actualización: 09/08/2019
Descripción Gravedad Notas

Este boletín se ha actualizado desde su publicación original.

Hace poco se ha descubierto una vulnerabilidad en Kubernetes, la CVE-2019-11247, que permite que las instancias de recursos personalizados con permiso de clúster se utilicen como si fueran objetos espaciados por nombre en todos los espacios de nombres. Esto quiere decir que las cuentas de usuario y de servicio que cuenten únicamente con permisos para controlar el acceso basado en roles a nivel de espacio de nombres pueden interactuar con recursos personalizados que tengan permiso de clúster. Para que el atacante pueda aprovechar esta vulnerabilidad, es necesario que cuente con privilegios para acceder al recurso en cualquier espacio de nombres.

¿Qué debo hacer?

Te recomendamos que actualices tu clúster a la versión más reciente del parche en cuanto esté disponible, ya que contiene la mitigación a esta vulnerabilidad. Está previsto que el parche esté disponible en todas las zonas con la próxima versión de GKE. A continuación se indican las versiones de parches que contendrán la mitigació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 del 2019

Publicación: 03/07/2019
Última actualización: 03/07/2019
Descripción Gravedad Notas

Ya hay disponible una versión con parche de kubectl con gcloud 253.0.0 para tratar la CVE-2019-11246. Consulta el boletín de seguridad del 25 de junio del 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 del 2019

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

Cuando publicamos la última actualización, todavía no estaban disponibles los parches de las versiones 1.11.9 y 1.11.10. Ya hemos lanzado la versión 1.11.10-gke.5 como actualización de ambas versiones 1.11.

En este momento, se han aplicado parches a las instancias maestras de GKE y la infraestructura de Google que ejecuta Kubernetes Engine está protegida frente a esta vulnerabilidad.

En poco tiempo, las instancias maestras 1.11 dejarán de estar disponibles y se han programado actualizaciones automáticas a la versión 1.12 en la semana del 8 de julio del 2019. Puedes elegir cualquiera de las siguientes opciones para obtener nodos con una versión con parche:

  • Actualiza los nodos a la versión 1.11.10-gke.5 a partir del 8 de julio del 2019. Después de esa fecha, se empezarán a eliminar las versiones 1.11 de la lista disponible de objetivos de actualización.
  • Habilita las actualizaciones automáticas en los nodos de la versión 1.11 y permite que puedan actualizarse a la versión 1.12 cuando lo hagan las instancias maestras.
  • Actualiza manualmente las instancias maestras y los nodos a una versión 1.12 corregida.

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

Actualización del 24 de junio del 2019

El 22 de junio del 2019 a las 21:40 (UTC), lanzamos las siguientes versiones con parches de Kubernetes. Las instancias maestras entre las versiones de Kubernetes 1.11.0 y 1.13.6 se actualizarán automáticamente a una versión con parche. Si no estás ejecutando una versión compatible con este parche, actualiza a una versión de instancia maestra compatible (se enumeran más adelante) antes de actualizar tus nodos.

Debido a la gravedad de estas vulnerabilidades, y tengas o no habilitadas las actualizaciones automáticas de nodos, te recomendamos que actualices manualmente tus nodos e instancias maestras a una de estas versiones en cuanto estén disponibles.

Las versiones con parche:

  • 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 del 2019 es el siguiente:

Netflix ha divulgado hace poco tres vulnerabilidades de TCP en los kernels de Linux:

A estas CVE se las conoce conjuntamente como NFLX‑2019‑001.

Es posible que los kernels de Linux sin parches sean vulnerables a un ataque de denegación de servicio activado de forma remota. Los nodos de Google Kubernetes Engine que envían o reciben tráfico de redes no fiables se ven afectados, así que te recomendamos que sigas estos pasos de mitigación para proteger tus cargas de trabajo.

Instancias maestras de Kubernetes

  • Las instancias maestras que utilizan redes autorizadas para limitar el tráfico a la redes fiables no se ven afectadas.

  • En los próximos días, se aplicará automáticamente el parche a las instancias maestras de los clústeres de GKE que gestiona Google. No hace falta que el cliente realice ninguna acción.

Nodos de Kubernetes

Los nodos que limitan el tráfico a las redes fiables no se ven afectados. Se trataría de clústeres con las siguientes características:

  • Nodos con cortafuegos que protegen frente a redes no fiables o que no tienen direcciones IP públicas (clústeres privados).
  • Clústeres sin servicios de tipo LoadBalancer públicos.

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

Hasta entonces, hemos creado un DaemonSet de Kubernetes que modifica la configuración de iptables del host para implementar las mitigaciones.

¿Qué debo hacer?

Ejecuta el siguiente comando para aplicar el DaemonSet de Kubernetes a todos los nodos de tu clúster. De esta forma, se añade una regla iptables a las reglas iptables actuales del nodo para mitigar la vulnerabilidad. Ejecuta el comando una vez por clúster en cada proyecto. Google Cloud 

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

Una vez que haya disponible una versión del nodo con parche y hayas actualizado todos los nodos que puedan haberse visto afectados, usa el siguiente comando para eliminar el DaemonSet. Ejecuta el comando una vez por clúster en cada Google Cloud proyecto. 

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 del 2019

Descripción Gravedad Notas

Actualización del 03/07/2019: este parche está disponible en gcloud 253.0.0 para kubectl 1.12.9, 1.13.6, 1.14.2 y versiones posteriores.

Nota: El parche no está disponible en la versión 1.11.10.

Hace poco se ha descubierto una vulnerabilidad en Kubernetes, la CVE-2019-11246, que permite que un atacante con acceso a una operación kubectl cp y a la ejecución de código dentro de un contenedor modifique archivos en el host. Es posible que esta vulnerabilidad permita que un atacante sustituya o cree un archivo en el sistema de archivos del host. Para obtener más información, consulta el aviso que ha publicado Kubernetes al respecto.

Esta vulnerabilidad afecta a todas las versiones gcloud de Google Kubernetes Engine (GKE), así que te recomendamos actualizar a la versión más reciente del parche de gcloud cuando esté disponible. Próximamente habrá una versión del parche que incluya una mitigación de esta vulnerabilidad.

¿Qué debo hacer?

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

Consulta 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 kubectl cp pueda ejecutar código dentro de un contenedor para modificar archivos en el host. Es posible que esta vulnerabilidad permita que un atacante sustituya o cree un archivo en el sistema de archivos del host.

Alta

CVE-2019-11246

18 de junio del 2019

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad en Docker, la CVE-2018-15664, que permite que un atacante que puede ejecutar código en un contenedor intercepte una operación docker cp iniciada de forma externa. Es posible que esta vulnerabilidad permita que un atacante cambie el lugar en el que se escribe un archivo a una ubicación arbitraria en el sistema de archivos del host.

Esta vulnerabilidad afecta a todos los nodos que ejecutan Docker en Google Kubernetes Engine (GKE), así que te recomendamos actualizar a la versión más reciente del parche cuando esté disponible. Próximamente habrá una versión del parche que incluya una mitigación de esta vulnerabilidad.

Esta vulnerabilidad afecta a todas las instancias maestras que ejecutan Docker en Google Kubernetes Engine (GKE) y que son anteriores a la versión 1.12.7. En GKE, los usuarios no tienen acceso a docker cp en la instancia maestra, por lo que el riesgo de esta vulnerabilidad se ve limitado en las instancias maestras de este entorno.

¿Qué debo hacer?

Solo se ven afectados los nodos que ejecutan Docker y únicamente cuando se emite un comando docker cp (o uno equivalente con una API) que pueda ser interceptado. Se prevé que sea una situación bastante inusual en un entorno de Kubernetes. No se ven afectados los nodos que ejecutan Container-Optimized OS (COS) con containerd.

Para actualizar tus nodos, primero debes actualizar tus instancias maestras a la versión con parche. Cuando el parche esté disponible, podrás iniciar la actualización de la instancia maestra o esperar a que Google lo haga automáticamente. Dicho parche se incluirá en Docker 18.09.7 como parte de un próximo parche de GKE. Este parche solo estará disponible en GKE 1.13 y versiones posteriores.

Actualizaremos automáticamente las instancias maestras del clúster a la versión con parche según la programación habitual. También puedes iniciar la actualización de las instancias maestras por tu cuenta cuando la versión con parche esté disponible.

Actualizaremos este boletín cuando dispongamos de las versiones que contienen un parche. Consulta la disponibilidad de estos parches en las notas de la versión.

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2018-15664 permite que un atacante que pueda ejecutar código en un contenedor intercepte una operación docker cp iniciada de forma externa. Es posible que esta vulnerabilidad permita que un atacante cambie el lugar en el que se ha escrito un archivo a una ubicación arbitraria en el sistema de archivos del host.

Alta

31 de mayo del 2019

Descripción Gravedad Notas

Este boletín se ha actualizado desde su publicación original.

Actualización del 2 de agosto del 2019

Cuando se lanzó el boletín inicial, solo se veían afectadas las versiones de la 1.13.6-gke.0 a la 1.13.6-gke.5. Debido a una regresión, ahora se ven afectadas todas las versiones 1.13.6.x. Si utilizas la versión 1.13.6, actualízala a la 1.13.7 cuanto antes.

El proyecto Kubernetes ha descubierto la CVE-2019-11245 en kubelet v. 1.13.6 y v. 1.14.2, que puede provocar que los contenedores se ejecuten como UID 0 (normalmente se asigna al usuario root), aunque se haya especificado un usuario diferente en la imagen de contenedor. Si tus contenedores se ejecutan como un usuario no raíz y utilizas una versión de nodo entre la 1.13.6-gke.0 y la 1.13.6-gke.6, te recomendamos que establezcas RunAsUser en todos los pods del clúster cuyos contenedores no deberían ejecutarse como UID 0.

Si se especifica un valor de USER que no sea raíz (por ejemplo, si se establece el valor de USER en un Dockerfile), se puede producir un comportamiento inesperado. Cuando un contenedor se ejecuta por primera vez en un nodo, respeta correctamente el UID especificado. No obstante, debido a este defecto, en la segunda ejecución (y en las posteriores) el contenedor se ejecuta como UID 0 independientemente del UID especificado. Se trata normalmente de un privilegio de mayor prioridad no deseado, y puede conllevar un comportamiento inesperado de la aplicación.

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

Ejecuta el siguiente comando para enumerar todos los nodos y su versión de kubelet: 

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

Si el resultado muestra las versiones de kubelet que se indican a continuación, eso significa que tus nodos se ven afectados:

  • v. 1.13.6
  • v. 1.14.2
¿Cómo puedo saber si mi configuración específica se ve afectada?

Si tus contenedores se ejecutan como un usuario no raíz y utilizas una versión de nodo entre la 1.13.6-gke.0 y la 1.13.6-gke.6, tu configuración se verá afectada salvo en los siguientes casos:

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

Establece el contexto de seguridad RunAsUser en todos los pods del clúster que no deban ejecutarse como UID 0. Usa un recurso PodSecurityPolicy para aplicar esta configuración.

Medio CVE-2019-11245

14 de mayo del 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 lanzadas la semana del 28/05/2019, así como en las versiones posteriores.

Intel ha divulgado las siguientes CVE:

A estas CVE se las conoce conjuntamente como muestreo de datos de microarquitectura (MDS). Estas vulnerabilidades podrían permitir que los datos se expusieran por medio de la interacción de la ejecución especulativa y el estado de microarquitectura. Para obtener más información, consulta el aviso que ha publicado Intel al respecto.

La infraestructura del host que ejecuta Kubernetes Engine aísla las cargas de trabajo de los clientes entre sí. No te afectará a menos que ejecutes código no fiable en tus propios clústeres de varios propietarios de GKE.

Para los clientes que ejecuten código no fiable en sus propios servicios de varios propietarios de Kubernetes Engine, se trata de una vulnerabilidad considerablemente grave. Para mitigarla en Kubernetes Engine, inhabilita Hyper-Threading en tus nodos. Estas vulnerabilidades afectan únicamente a los nodos que usan varias CPU en Google Kubernetes Engine (GKE). Ten en cuenta que las máquinas virtuales n1-standard-1 (la predeterminada de GKE), g1-small y f1-micro exponen únicamente 1 vCPU al entorno de invitado, de modo que no es necesario inhabilitar Hyper-Threading.

Se incluirán protecciones adicionales que habiliten la funcionalidad de vaciado en una próxima versión del parche. En las próximas semanas, actualizaremos las instancias maestras y los nodos a las versiones con parche actualizadas automáticamente según la programación habitual. El parche no es suficiente por sí solo para mitigar la exposición a esta vulnerabilidad. Consulta las siguientes acciones recomendadas.

Si utilizas GKE On-Prem, la vulnerabilidad podría afectarte en función del hardware que emplees. Consulta el aviso que ha publicado Intel al respecto.

¿Qué debo hacer?

No te afectará a menos que ejecutes código no fiable en tus propios clústeres de varios propietarios de GKE.

En el caso de los nodos de Kubernetes Engine, crea grupos de nodos con la opción Hyper-Threading inhabilitada y reprograma tus cargas de trabajo en ellos.

Ten en cuenta que las máquinas virtuales n1-standard-1, g1-small y f1-micro exponen 1 vCPU al entorno de invitado, de modo que no es necesario inhabilitar Hyper-Threading.

Advertencia:
  • Inhabilitar Hyper-Threading podría afectar considerablemente al rendimiento de tus clústeres y tu aplicación. Asegúrate de que eso te parece bien antes de aplicar la medida en tus clústeres de producción.
  • Hyper-Threading se puede inhabilitar a nivel de grupo de nodos de GKE desplegando un DaemonSet. No obstante, al desplegar dicho DaemonSet, todos los nodos del grupo de nodos se reiniciarán a la vez. Por tanto, te recomendamos que crees un grupo de nodos en tu clúster, despliegues el DaemonSet para inhabilitar Hyper-Threading en dicho grupo de nodos y, entonces, migres ahí tus cargas de trabajo.

Para crear un grupo de nodos con Hyper-Threading inhabilitado:

  1. Crea un grupo de nodos en tu clúster con la etiqueta de nodo cloud.google.com/gke-smt-disabled=true: 
    gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true
  2. Despliega el DaemonSet en el nuevo grupo de nodos. El DaemonSet se ejecutará solamente en los nodos con la etiqueta cloud.google.com/gke-smt-disabled=true. Inhabilitará Hyper-Threading y, a continuación, 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 de DaemonSet están ejecutándose. 
    kubectl get pods --selector=name=disable-smt -n kube-system

    Deberías obtener una respuesta similar a esta:

    NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m
  4. Comprueba que aparece "SMT has been disabled" (Se ha inhabilitado 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 para que los cambios se apliquen automáticamente a los nodos que crees. Las creaciones de nodos se pueden activar durante la actualización manual o automática de la versión, la reparación automática y el autoescalado.

Para habilitar Hyper-Threading de nuevo, tendrás que volver a crear el grupo de nodos sin desplegar el DaemonSet proporcionado y migrar ahí tus cargas de trabajo.

También te recomendamos que actualices manualmente tus nodos cuando el parche esté disponible. Antes de ello, deberás actualizar tu instancia maestra a la versión más reciente. Las instancias maestras de GKE se actualizarán automáticamente según la programación habitual.

Actualizaremos este boletín con las versiones que contienen un parche en cuanto estén disponibles.

¿Qué vulnerabilidad trata este parche?

Este parche mitiga las siguientes vulnerabilidades:

Las CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 y CVE-2019-11091 son vulnerabilidades que aprovechan la ejecución especulativa. A estas CVE se las conoce conjuntamente como muestreo de datos de microarquitectura. Estas vulnerabilidades podrían permitir que se expongan datos por medio de la interacción de la ejecución especulativa y el estado de microarquitectura. 		Medio

5 de abril del 2019

Descripción Gravedad Notas

Hace poco se han descubierto las vulnerabilidades de seguridad CVE-2019-9900 y CVE-2019-9901 en Envoy.

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

Si has habilitado Istio en Google Kubernetes Engine (GKE), puede que te afecten estas vulnerabilidades. Te recomendamos que actualices cuanto antes los clústeres afectados a la versión más reciente del parche, así como tus contenedores adicionales de Istio (las instrucciones se indican más abajo).

¿Qué debo hacer?

Debido a la gravedad de estas vulnerabilidades, tanto si tienes nodos con la actualización automática habilitada como si no, te recomendamos que sigas los siguientes pasos:

  1. Actualiza manualmente tu clúster en cuanto esté disponible el parche.
  2. Actualiza tus contenedores adicionales tal y como se indica en esta documentación.

Las versiones con parche estarán disponibles en todos los proyectos de GKE antes de las 19:00 (PDT) de hoy.

Este parche estará disponible en las versiones de GKE que se indican más abajo. Los nuevos clústeres usarán la versión con parche de forma predeterminada cuando se anuncie en la página de boletines de seguridad de GKE, lo que está previsto para el 15 de abril del 2019. Si has creado un clúster antes de esa fecha, deberás indicar la versión con parche que debe utilizar. Para los clientes de GKE que tienen las actualizaciones automáticas de los nodos habilitadas y no realicen la actualización manualmente, sus nodos se actualizarán automáticamente a las versiones con parche durante la semana siguiente.

Versiones con parche:

  • 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 trata este parche?

Este parche mitiga las siguientes vulnerabilidades:

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

Alta

1 de marzo del 2019

Descripción Gravedad Notas

Actualización del 22/03/2019: este parche está disponible para Kubernetes 1.11.8-gke.4, 1.13.4-gke.1 y versiones posteriores. El parche aún no está disponible en la versión 1.12. Consulta la disponibilidad de estos parches en las notas de la versión.

Hace poco se ha descubierto una nueva vulnerabilidad de denegación de servicio en Kubernetes, la CVE-2019-1002100, que permite que un usuario autorizado para enviar solicitudes de parche cree solicitudes "json-patch" maliciosas que consumen excesivamente la CPU y la memoria en el servidor de API de Kubernetes, lo que puede reducir la disponibilidad del plano de control del clúster. Para obtener más información, consulta el aviso que ha publicado Kubernetes al respecto. Las vulnerabilidades anteriores afectan a todas las instancias maestras de Google Kubernetes Engine (GKE). Próximamente habrá una versión del parche que incluya una mitigación de esta vulnerabilidad. En las próximas semanas, actualizaremos automáticamente las instancias maestras del clúster a la versión con parche según la programación habitual.

¿Qué debo hacer?

No tienes que hacer nada. Las instancias maestras de GKE se actualizarán automáticamente según la programación habitual. Si quieres actualizar tu instancia maestra con antelación, puedes iniciar manualmente una actualización maestra.

Actualizaremos este boletín con las versiones que contengan un parche. Ten en cuenta que el parche solo estará disponible en las versiones 1.11+, pero no en las versiones 1.10.

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2019-1002100 permite que un usuario cree especialmente un parche de tipo "json-patch" que consume excesivamente la CPU en el servidor de API de Kubernetes, lo que puede reducir la disponibilidad del plano de control del clúster.

Medio CVE-2019-1002100

11 de febrero del 2019 (runc)

Descripción Gravedad Notas

La Open Containers Initiative (OCI) ha descubierto hace poco una nueva vulnerabilidad de seguridad en runc, la CVE-2019-5736, que permite usar el escape de contenedores para obtener privilegios de raíz en el nodo del host.

Estas vulnerabilidades afectan a tus nodos de Ubuntu en Google Kubernetes Engine (GKE), así que te recomendamos actualizar cuanto antes a la versión más reciente del parche como se indica a continuación.

¿Qué debo hacer?

Para actualizar tus nodos, primero debes actualizar tu instancia maestra a la versión más reciente. Este parche está disponible para Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 y versiones posteriores. Consulta la disponibilidad de estos parches en las notas de la versión.

Ten en cuenta que solamente se ven afectados los nodos de Ubuntu en GKE. Los nodos que ejecutan COS no se ven afectados.

Ten en cuenta que en la nueva versión de runc ha aumentado el uso de memoria, por lo que es posible que debas actualizar la memoria asignada a los contenedores si has establecido los límites de memoria en un nivel bajo (menos de 16 MB).

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La CVE-2019-5736 describe una vulnerabilidad en runc que permite que un contenedor malicioso (con una interacción mínima del usuario en forma de un ejecutable) sobrescriba el binario runc del host y, de este modo, pueda ejecutar código a nivel raíz en el nodo del host. No se ven afectados los contenedores que se ejecutan como raíz. Se considera una vulnerabilidad de alta gravedad.

 Alta CVE-2019-5736

11 de febrero del 2019 (Go)

Descripción Gravedad Notas

Actualización del 25/02/2019: el parche no está disponible en 1.11.7-gke.4 como se había anunciado anteriormente. Si utilizas la versión 1.11.7, puedes cambiar a la versión inferior 1.11.6, actualizar a la versión 1.12 o esperar hasta que esté disponible el próximo parche de 1.11.7 la semana del 04/03/2019.

Hace poco se ha descubierto una nueva vulnerabilidad de seguridad en el lenguaje de programación Go, la CVE-2019-6486. Se trata de una vulnerabilidad de denegación de servicio (DoS) en las implementaciones de criptografía de curva elíptica de las curvas elípticas P-521 y P-384. En Google Kubernetes Engine (GKE), esta podría permitir que un usuario cree solicitudes maliciosas que consumen excesivamente la CPU en el servidor de API de Kubernetes, lo que puede reducir la disponibilidad del plano de control del clúster. Para saber más, consulta el aviso sobre el lenguaje de programación Go que se ha publicado al respecto.

Las vulnerabilidades anteriores afectan a todas las instancias maestras de Google Kubernetes Engine (GKE). Habrá una nueva versión del parche que incluya una mitigación para esta vulnerabilidad. En las próximas semanas, actualizaremos automáticamente las instancias maestras del clúster a la versión con parche según la programación habitual.

¿Qué debo hacer?

No tienes que hacer nada. Las instancias maestras de GKE se actualizarán automáticamente según la programación habitual. Si quieres actualizar tu instancia maestra con antelación, puedes iniciar manualmente una actualización maestra.

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 versiones posteriores.

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La CVE-2019-6486 es una vulnerabilidad en las implementaciones de criptografía de curva elíptica de las curvas elípticas P-521 y P-384. Permite que un usuario cree entradas que consumen excesivamente la CPU.

Alta CVE-2019-6486

3 de diciembre del 2018

Descripción Gravedad Notas

En los últimos días, Kubernetes encontró una nueva vulnerabilidad en la seguridad, la CVE‑2018‑1002105, por la que usuarios con privilegios de un nivel relativamente bajo pueden saltarse la autorización de las API de kubelet. En consecuencia, pueden ejecutar operaciones arbitrarias para cualquier pod y en cualquier nodo del clúster. Para obtener más información, consulta el aviso que ha publicado Kubernetes al respecto. Las vulnerabilidades anteriores han afectado a todas las instancias maestras en Google Kubernetes Engine (GKE) y ya hemos actualizado los clústeres a la versión más reciente del parche. No tienes que hacer nada.

¿Qué debo hacer?

No tienes que hacer nada. Ya hemos actualizado las instancias maestras de GKE.

El 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 y 1.11.2‑gke.18, así como en las últimas versiones.

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2018-1002105 permite que un usuario con privilegios de un nivel relativamente bajo pueda saltarse la autorización de las API de kubelet. Como consecuencia, puede enviar solicitudes de actualización de mayor prioridad y realizar llamadas arbitrarias a cualquier API de kubelet. Se considera una vulnerabilidad crítica en Kubernetes. Sin embargo, se ha considerado una vulnerabilidad alta porque algunos detalles de la implementación de GKE impidieron escalar sin autenticar.

Alta CVE‑2018‑1002105

13 de noviembre del 2018

Descripción

Actualización del 16/11/2018: Se ha completado la revocación y rotación de todos los tokens que podrían haberse visto afectados. No hace falta que hagas nada más.

Recientemente, Google descubrió un problema en el complemento Container Network Interface (CNI) de Calico que puede incluir información sensible en los registros con algunas configuraciones. El seguimiento de este problema lo está realizando Tigera Technical Advisory TTA‑2018‑001.

  • Al ejecutar el complemento CNI de Calico con el registro de nivel de depuración, este escribe la configuración del cliente de la API de Kubernetes en los registros.
  • El complemento CNI de Calico también escribe el token de la API de Kubernetes en los registros de nivel de información si el campo "k8s_auth_token" se ha establecido en la configuración de red de CNI.
  • Además, al ejecutarse con el registro de nivel de depuración, si se establece de forma explícita el token de la cuenta de servicio, ya sea en el archivo de configuración de Calico leído por Calico o como variables del entorno usadas por Calico, los componentes de Calico (calico/nodo, 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 de clúster y Stackdriver Logging habilitado han registrado tokens de cuenta de servicio de Calico en Stackdriver. Los clústeres que no tienen habilitada la política de red no se han visto afectados.

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

Durante la próxima semana, llevaremos a cabo una revocación progresiva de todos los tokens que puedan estar afectados. Este boletín se actualizará cuando se haya completado la revocación. No hace falta que hagas nada más. (Esta rotación se completó el 16/11/2018).

Si quieres rotar estos tokens de forma inmediata, puedes ejecutar el siguiente comando; el nuevo secreto correspondiente a la cuenta de servicio debería volver a crearse automáticamente 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 al servidor de la API. Para saber si se utilizó un token de Calico fuera del intervalo de IPs esperado de Google Cloud, puedes ejecutar la siguiente consulta de Stackdriver. Solo se mostrarán los registros de llamadas realizadas desde fuera de la red de Google Cloud Platform (GCP) y te recomendamos que la 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 del 2018

Descripción Gravedad Notas

Intel ha divulgado las siguientes CVE:

A estas CVE se las conoce conjuntamente como "L1 Terminal Fault (L1TF)".

Las vulnerabilidades de L1TF llevan a cabo la ejecución especulativa por medio de ataques a la configuración de las estructuras de datos en el procesador. "L1" hace referencia a la caché Level‑1 Data (L1D), un pequeño recurso del núcleo que se utiliza para acelerar el acceso a la memoria.

Consulta esta entrada del blog de Google Cloud para obtener más información sobre estas vulnerabilidades y las medidas de mitigación de Compute Engine.

Impacto en Google Kubernetes Engine

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

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

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

Alta

6 de agosto del 2018 (última actualización: 5 de septiembre del 2018)

Descripción Gravedad Notas

Actualización del 05/09/2018

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

Descripción

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

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

El impacto en Google Kubernetes Engine

Desde el 11/08/2018, todas las instancias maestras de Kubernetes Engine están protegidas contra ambas vulnerabilidades. Además, todos los clústeres de Kubernetes Engine configurados para actualizarse automáticamente están protegidos contra ambas vulnerabilidades. No obstante, estas afectan a los grupos de nodos de Kubernetes Engine que no estén configurados para actualizarse automáticamente y que se hayan actualizado manualmente por última vez antes del 11/08/2018.

Versiones con parche

Debido a la gravedad de esta vulnerabilidad, te recomendamos que actualices manualmente tus nodos en cuanto esté disponible el parche.

Alta

30 de mayo del 2018

Descripción Gravedad Notas

Hace poco se descubrió una vulnerabilidad en Git que podría permitir la elevación de privilegios en Kubernetes si los usuarios sin privilegios obtienen permisos para crear pods con volúmenes gitRepo. La CVE se identifica con la etiqueta CVE‑2018‑11235.

¿Me afecta esta vulnerabilidad?

Esta vulnerabilidad te afecta si todas estas afirmaciones se aplican a tu caso:

  • 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 raíz al 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?

Prohibir el uso del tipo de volumen gitRepo. Para prohibir los volúmenes gitRepo con PodSecurityPolicy, quita gitRepo de la lista de elementos permitidos volumes de tu PodSecurityPolicy.

Es posible tener un comportamiento equivalente al volumen gitRepo si se clona un repositorio de Git en un volumen EmptyDir desde 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 futura versión de Kubernetes Engine. Vuelve a visitar los boletines de seguridad próximamente para obtener más información.

Media

21 de mayo del 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 de 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. Estas vulnerabilidades afectan a todos los nodos de Kubernetes Engine, por lo que te recomendamos actualizar a la versión más reciente del parche como se indica a continuación.

¿Qué debo hacer?

En primer lugar, debes actualizar tu instancia maestra 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, tendrás que especificar la versión con parche que debe usar. A los clientes que tengan habilitadas las actualizaciones de nodo automáticas y no actualicen manualmente se les actualizarán los nodos a las versiones con parche en las próximas semanas.

¿Qué vulnerabilidades trata este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE‑2018‑1000199: Esta vulnerabilidad afecta al kernel de Linux. Permite que un usuario o proceso sin privilegios cause un fallo en el kernel del sistema, lo que provoca un ataque DoS o una apropiación de privilegios. Se considera una vulnerabilidad alta, con una puntuación de 7,8 en el sistema CVSS.

CVE‑2018‑8897: Esta vulnerabilidad afecta al kernel de Linux. Permite que un usuario o proceso sin privilegios cause un fallo en el kernel del sistema, lo que provoca un ataque DoS. Se considera una vulnerabilidad media, con una puntuación de 6,5 en el sistema CVSS.

CVE‑2018‑1087: Esta vulnerabilidad afecta al hipervisor KVM del kernel de Linux. Permite que un proceso sin privilegios cause un fallo en el kernel invitado o que pueda adquirir privilegios. La vulnerabilidad tiene un parche en la infraestructura sobre la que se ejecuta Kubernetes Engine, por lo que este no se ve afectado. Se considera una vulnerabilidad alta, con una puntuación de 8,0 en el sistema CVSS.

Alta

12 de marzo del 2018

Descripción Gravedad Notas

Hace poco se han descubierto las nuevas vulnerabilidades de seguridad en Kubernetes 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, así que te recomendamos actualizar cuanto antes a la versión más reciente del parche como se indica a continuación.

¿Qué debo hacer?

Debido a la gravedad de estas vulnerabilidades, tengas o no habilitadas las actualizaciones automáticas de nodos, te recomendamos que actualices manualmente tus nodos en cuanto esté disponible el parche. De acuerdo con el calendario de actualizaciones, este parche estará disponible para todos los clientes a partir del 16 de marzo, pero es posible que lo tengas antes a tu disposición en función de la zona en la que se encuentre tu clúster.

En primer lugar, debes actualizar tu instancia maestra 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, tendrás que especificar la versión con parche que debe usar.

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

¿Qué vulnerabilidades trata este parche?

Este parche mitiga las siguientes vulnerabilidades:

La vulnerabilidad CVE‑2017‑1002101 permite que los contenedores que usan activaciones de volumen subPath tengan acceso a archivos externos al volumen. Por tanto, si estás bloqueando el acceso de los contenedores a volúmenes hostPath con PodSecurityPolicy, un atacante con la capacidad para actualizar o crear pods puede activar cualquier hostPath con cualquier otro tipo de volumen.

La vulnerabilidad CVE‑2017‑1002102 permite que los contenedores que usan determinados tipos de volúmenes (incluidos los secretos, mapas de configuración, volúmenes proyectados o volúmenes de la API Downward) borren archivos externos al volumen. Por tanto, si se vulnera un contenedor que utiliza uno de estos tipos de volúmenes o si permites que usuarios que no son de confianza creen pods, un atacante podría usar ese contenedor para borrar archivos al azar en el host.

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

Alta

Boletines de seguridad de Google Distributed Cloud

16 de octubre del 2019

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad en Kubernetes, descrita en la CVE-2019-11253, que permite que cualquier usuario autorizado envíe solicitudes POST para ejecutar un ataque remoto de denegación de servicio en un servidor de API de Kubernetes. El Comité de Seguridad de Producto (PSC) de Kubernetes ha publicado información adicional sobre esta vulnerabilidad.

Puedes mitigar esta vulnerabilidad limitando los clientes que tienen acceso de red a tus servidores de la API de Kubernetes.

¿Qué debo hacer?

Te recomendamos que actualices tus clústeres a una versión del parche que contenga la corrección en cuanto esté disponible.

A continuación, se indican las versiones de parches que contendrán la corrección:

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

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

Alta

CVE-2019-11253

23 de agosto del 2019

Descripción Gravedad Notas

Hace poco, descubrimos y mitigamos una vulnerabilidad por la que el proxy RBAC usado para proteger los endpoints de monitorización no autorizaba correctamente a los usuarios. Como resultado, las métricas de determinados componentes están disponibles para usuarios no autorizados 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 tus clústeres a la versión 1.0.2-gke.3 lo antes posible, ya que incluye el parche para esta vulnerabilidad.

Medio

Lanzamientos de Google Distributed Cloud

22 de agosto del 2019

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad en Kubernetes, la CVE-2019-11247, que permite que las instancias de recursos personalizados con permiso de clúster se utilicen como si fueran objetos espaciados por nombre en todos los espacios de nombres. Esto quiere decir que las cuentas de usuario y de servicio que cuenten únicamente con permisos para controlar el acceso basado en roles a nivel de espacio de nombres pueden interactuar con recursos personalizados que tengan permiso de clúster. Para que el atacante pueda aprovechar esta vulnerabilidad, es necesario que cuente con privilegios para acceder al recurso en cualquier espacio de nombres.

¿Qué debo hacer?

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

¿Qué vulnerabilidad trata este parche?

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

Medio

CVE-2019-11247