Boletines de seguridad

Es posible que, de vez en cuando, publiquemos boletines de seguridad relacionados con Kubernetes Engine. En esta página se describen todos los boletines de seguridad de Google Kubernetes Engine.

Es habitual que las vulnerabilidades se mantengan en secreto y no puedan divulgarse hasta que las partes afectadas hayan tenido oportunidad de mitigarlas. En estos casos, las notas de la versión de Google Kubernetes Engine (GKE) harán referencia a "actualizaciones de seguridad" hasta que se apruebe la divulgación. Llegado ese momento, las notas se actualizan para hacer referencia a la vulnerabilidad que se ha mitigado con el parche.

Suscríbete a los boletines de seguridad de GKE.

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 saber más, consulta el aviso que ha publicado Kubernetes al respecto. Las vulnerabilidades anteriores han afectado a todas las instancias maestras de GKE y ya hemos actualizado los clústeres a las últimas versiones del parche. No hace falta que hagas nada. ¿Qué debo hacer? No hace falta que hagas 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: Debido a la vulnerabilidad CVE‑2018‑1002105, usuarios con privilegios de un nivel relativamente bajo pueden saltarse la autorización de las API de kubelet. En consecuencia, los usuarios autorizados pueden enviar solicitudes de actualización para escalar y hacer llamadas arbitrarias a la API de kubelet. Esta situación 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

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 saber más, consulta el aviso que ha publicado Kubernetes al respecto. Las vulnerabilidades anteriores han afectado a todas las instancias maestras de GKE y ya hemos actualizado los clústeres a las últimas versiones del parche. No hace falta que hagas nada.

¿Qué debo hacer?

No hace falta que hagas 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:

Debido a la vulnerabilidad CVE‑2018‑1002105, usuarios con privilegios de un nivel relativamente bajo pueden saltarse la autorización de las API de kubelet. En consecuencia, los usuarios autorizados pueden enviar solicitudes de actualización para escalar y hacer llamadas arbitrarias a la API de kubelet. Esta situación 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 ejecutarlo con el registro de nivel de depuración, el complemento CNI de Calico 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:

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 ejecutarlo con el registro de nivel de depuración, el complemento CNI de Calico 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 '&#123&#123(index .secrets 0).name&#125&#125' | 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: CVE‑2018‑3615 (para SGX) CVE‑2018‑3620 (para sistemas operativos y SMT) CVE‑2018‑3646 (para virtualización) 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. El 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	CVE‑2018‑3615 CVE‑2018‑3620 CVE‑2018‑3646

Descripción

Gravedad

Notas

Intel ha divulgado las siguientes CVE:

CVE‑2018‑3615 (para SGX)
CVE‑2018‑3620 (para sistemas operativos y SMT)
CVE‑2018‑3646 (para virtualización)

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.

El 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	CVE‑2018‑5390 CVE‑2018‑5391

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

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 blanca `volumes` en 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	CVE‑2018‑11235

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 blanca volumes en 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

CVE‑2018‑11235

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. Todos los nodos de Kubernetes Engine se ven afectados por estas vulnerabilidades, así que te recomendamos que actualices 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 realicen la actualización manualmente se les actualizarán los nodos a las versiones con parche en las próximas semanas. ¿Qué vulnerabilidades mitiga 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 elevació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	CVE‑2018‑1000199 CVE‑2018‑8897 CVE‑2018‑1087

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. Todos los nodos de Kubernetes Engine se ven afectados por estas vulnerabilidades, así que te recomendamos que actualices 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 realicen la actualización manualmente se les actualizarán los nodos a las versiones con parche en las próximas semanas.

¿Qué vulnerabilidades mitiga 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 elevació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
El proyecto Kubernetes divulgó recientemente nuevas vulnerabilidades de seguridad, las 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 encuentra 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 mitiga 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	CVE‑2017‑1002101 CVE‑2017‑1002102

Descripción

Gravedad

Notas

El proyecto Kubernetes divulgó recientemente nuevas vulnerabilidades de seguridad, las 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 encuentra 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 mitiga 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