Bollettini sulla sicurezza

Potremmo pubblicare periodicamente dei bollettini sulla sicurezza relativi a Kubernetes Engine. Di seguito vengono descritti tutti i bollettini di sicurezza per Google Kubernetes Engine.

Le vulnerabilità sono spesso mantenute segrete sotto embargo finché le parti interessate non hanno avuto la possibilità di affrontarle. In questi casi, le Note di rilascio di GKE faranno riferimento agli "aggiornamenti della sicurezza" fino a quando l'embargo non sarà stato revocato. A quel punto le note verranno aggiornate per riflettere la vulnerabilità affrontata dalla patch.

Iscriviti ai bollettini sulla sicurezza di GKE. Iscriviti

3 dicembre 2018

Descrizione Gravità Note

Kubernetes ha recentemente scoperto una nuova vulnerabilità della sicurezza CVE-2018-1002105, che consente a un utente con privilegi relativamente bassi di ignorare l'autorizzazione alle API di kubelet, offrendo la possibilità di eseguire operazioni arbitrarie per qualsiasi pod su qualsiasi nodo nel cluster. Per ulteriori dettagli, consulta Divulgazione di Kubernetes. Tutti i master di Google Kubernetes Engine (GKE) sono stati interessati da queste vulnerabilità e abbiamo già aggiornato i cluster alle versioni patch più recenti. Non è richiesta alcuna azione da parte tua.

Che cosa devo fare?

Non è richiesta alcuna azione da parte tua. I master GKE sono già stati aggiornati.

Questa patch è disponibile in 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 e versioni più recenti.

Quale vulnerabilità viene affrontata da questa patch?

La patch attenua la seguente vulnerabilità:

La vulnerabilità CVE-2018-1002105 consente a un utente con privilegi relativamente bassi di ignorare l'autorizzazione alle API di kubelet. Ciò consente a un utente autorizzato a inoltrare richieste aggiornabili di riassegnare ed eseguire chiamate arbitrarie all'API di kubelet. Questa viene classificata come Vulnerabilità critica in Kubernetes. Dati alcuni dettagli nell'implementazione di GKE che hanno impedito il percorso di escalation non autenticato, questa viene classificata come Alta vulnerabilità.

Alta CVE-2018-1002105

13 novembre 2018

Descrizione

Aggiornamento 16-11-2018: la revoca e la rotazione di tutti i token potenzialmente interessati è completa. Non sono necessarie ulteriori azioni.

Recentemente Google ha rilevato un problema nel plug-in Container Network Interface (CNI) di Calico che può, in alcune configurazioni, registrare informazioni riservate. Questo problema è monitorato dal Tigera Technical Advisory TTA-2018-001.

  • Quando si esegue la registrazione a livello di debug, il plug-in CNI di Calico scriverà la configurazione del client API di Kubernetes nei log.
  • La CNI di Calico scriverà anche il token dell'API di Kubernetes nei log a livello di informazioni se il campo "k8s_auth_token" è impostato sulla configurazione di rete CNI.
  • Inoltre, quando si esegue la registrazione a livello di debug, se il token dell'account di servizio è impostato in modo esplicito, nel file di configurazione Calico letto da Calico o come variabili di ambiente utilizzate da Calico, i componenti Calico (calico/nodo, felix, CNI) scriveranno queste informazioni nei file di log.

Questi token hanno le seguenti autorizzazioni:


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]
      

I cluster di Google Kubernetes Engine con criterio per la rete di cluster e abilitati per Stackdriver Logging, hanno registrato i token dell'account di servizio Calico in Stackdriver. I cluster senza criterio di rete abilitato non sono interessati.

Abbiamo eseguito il deployment di una correzione che esegue la migrazione del plug-in CNI di Calico per accedere solo a livello di avviso e utilizzare un nuovo account di servizio. Il deployment del codice Calico a cui è stata applicata la patch sarà eseguito in una versione successiva.

Nel corso della prossima settimana, effettueremo una revoca progressiva di tutti i token potenzialmente interessati. Questo bollettino verrà aggiornato al termine della revoca. Non sono richieste altre operazioni da parte tua. (Questa rotazione è stata completata in data 16-11-2018)

Se desideri ruotare immediatamente questi token, puoi eseguire il comando riportato di seguito, il nuovo secret per l'account di servizio dovrebbe essere ricreato automaticamente in pochi secondi:


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
      

Rilevamento

GKE registra tutti gli accessi al server API. Per determinare se un token Calico è stato utilizzato al di fuori dell'intervallo IP previsto da Google Cloud, è possibile eseguire la seguente query Stackdriver. Ti preghiamo di notare che questo restituirà solo i record per le chiamate effettuate dalla rete esterna di GCP. Dovresti personalizzarlo secondo le necessità del tuo ambiente specifico.


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 agosto 2018

Descrizione Gravità Note

Intel ha divulgato i seguenti CVE:

Questi CVE vengono denominati collettivamente "L1 Terminal Fault (L1TF)".

Queste vulnerabilità L1TF sfruttano l'esecuzione speculativa attaccando la configurazione delle strutture di dati a livello di processore. "L1" si riferisce alla cache dei dati di livello 1 (L1D), una piccola risorsa on-core utilizzata per accelerare l'accesso alla memoria.

Leggi il post del blog di Google Cloud per ulteriori dettagli su queste vulnerabilità e sulle mitigazioni di Compute Engine.

Impatto di Google Kubernetes Engine

L'infrastruttura che esegue Kubernetes Engine e isola i cluster e i nodi dei clienti l'uno dall'altro è protetta dagli attacchi noti.

I pool di nodi di Kubernetes Engine che utilizzano l'immagine Container-Optimized OS di Google e che hanno l'upgrade automatico attivato verranno automaticamente aggiornati alla versione con patch della nostra immagine COS non appena diventeranno disponibili a partire dalla settimana del 20-08-2018.

I pool di nodi di Kubernetes Engine che non hanno abilitato l'aggiornamento automatico devono essere aggiornati manualmente non appena le versioni con patch della nostra immagine COS diventano disponibili.

Alta

6 agosto 2018; ultimo aggiornamento: 5 settembre 2018

Descrizione Gravità Note

Aggiornamento 05-09-2018

CVE-2018-5391 è stato recentemente divulgato. Come con CVE-2018-5390, si tratta di una vulnerabilità di rete a livello di kernel che aumenta l'efficacia degli attacchi DoS (Denial of Service) contro i sistemi vulnerabili. La principale differenza è che CVE-2018-5391 è sfruttabile su connessioni IP. Abbiamo aggiornato questo bollettino per coprire entrambe le vulnerabilità.

Descrizione

CVE-2018-5390 ("SegmentSmack") descrive una vulnerabilità di rete a livello di kernel che aumenta l'efficacia degli attacchi DoS (Denial of Service) contro i sistemi vulnerabili tramite le connessioni TCP.

CVE-2018-5391 ("FragmentSmack") descrive una vulnerabilità di rete a livello di kernel che aumenta l'efficacia degli attacchi DoS (Denial of Service) contro i sistemi vulnerabili tramite le connessioni IP.

Impatto di Google Kubernetes Engine

A partire dall'11-08-2018, tutti i master di Kubernetes Engine sono protetti da entrambe le vulnerabilità. Inoltre, anche tutti i cluster di Kubernetes Engine che sono configurati per l'aggiornamento automatico sono protetti da entrambe le vulnerabilità. I pool di nodi di Kubernetes Engine che non sono configurati per l'aggiornamento automatico e che sono stati aggiornati manualmente prima dell'11-08-2018 sono interessati da entrambe le vulnerabilità.

Versioni con patch

A causa della gravità di questa vulnerabilità, si consiglia di aggiornare manualmente i nodi non appena la patch diventa disponibile.

Alta

30 maggio 2018

Descrizione Gravità Note

Recentemente è stata scoperta una vulnerabilità in Git che potrebbe consentire l'escalation dei privilegi in Kubernetes se agli utenti non privilegiati è consentito creare pod con volumi gitRepo. Il CVE è identificato con il tag CVE-2018-11235.

Incide su di me?

Questa vulnerabilità influisce su di te se tutte le seguenti condizioni sono vere:

  • Gli utenti non attendibili possono creare pod (o attivare la creazione di pod).
  • I pod creati da utenti non attendibili dispongono di restrizioni che impediscono l'accesso root dell'host (ad esempio tramite PodSecurityPolicy).
  • I pod creati da utenti non attendibili sono autorizzati a utilizzare il tipo di volume gitRepo.

Tutti i nodi di Kubernetes Engine sono vulnerabili.

Che cosa devo fare?

Vieta l'uso del tipo di volume gitRepo. Per vietare i volumi gitRepo con PodSecurityPolicy, ometti gitRepo dalla whitelist volumes in PodSecurityPolicy.

Il comportamento equivalente del volume gitRepo può essere ottenuto clonando un repository git in un volume EmptyDir da 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: {}

Quale patch affronta questa vulnerabilità?

Una patch verrà inclusa in un'imminente release di Kubernetes Engine. Torna a controllare questa pagina per dettagli.

Media

21 maggio 2018

Descrizione Gravità Note

Diverse vulnerabilità sono state recentemente scoperte nel kernel di Linux; questo potrebbe consentire l'escalation dei privilegi o il denial of service (tramite arresto del kernel) da un processo non privilegiato. Questi CVE sono identificati dai tag CVE-2018-1000199, CVE-2018-8897 e CVE-2018-1087. Tutti i nodi di Kubernetes Engine sono interessati da queste vulnerabilità e ti consigliamo di eseguire l'aggiornamento alla versione più recente della patch, come descritto di seguito.

Che cosa devo fare?

Per eseguire l'upgrade, è necessario prima aggiornare il master alla versione più recente. Questa patch è disponibile in Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1 e Kubernetes Engine 1.10.2-gke.1. Queste release includono patch sia per Container-Optimized OS sia per immagini Ubuntu.

Se crei un nuovo cluster prima di allora, devi specificare la versione con patch da utilizzare. I clienti che hanno abilitato gli aggiornamenti automatici dei nodi e che non effettuano l'aggiornamento manuale avranno i loro nodi aggiornati alle versioni con patch nelle prossime settimane.

Quali vulnerabilità vengono affrontate da questa patch?

La patch attenua le seguenti vulnerabilità:

CVE-2018-1000199: questa vulnerabilità interessa il kernel di Linux. Consente a un utente o processo non privilegiato di arrestare il kernel di sistema, causando un attacco DoS o un'escalation dei privilegi. Questa è classificata come Alta vulnerabilità, con un CVSS di 7,8.

CVE-2018-8897: questa vulnerabilità interessa il kernel di Linux. Consente a un utente o processo non privilegiato di arrestare il kernel di sistema, causando un attacco DoS. Questa è classificata come Media vulnerabilità, con un CVSS di 6,5.

CVE-2018-1087: questa vulnerabilità interessa l'hypervisor KVM del kernel Linux. Ciò consente a un processo non privilegiato di arrestare il kernel ospite o potenzialmente di ottenere privilegi. A questa vulnerabilità viene applicata una patch nell'infrastruttura in cui viene eseguito Kubernetes Engine, pertanto Kubernetes Engine non è interessato. Questa è classificata come Alta vulnerabilità, con un CVSS di 8,0.

Alta

12 marzo 2018

Descrizione Gravità Note

Il progetto Kubernetes ha recentemente divulgato nuove vulnerabilità di sicurezza, CVE-2017-1002101 e CVE-2017-1002102, che consentono ai container di accedere ai file all'esterno del container. Tutti i nodi di Kubernetes Engine sono interessati da queste vulnerabilità e ti consigliamo di eseguire l'aggiornamento alla versione più recente della patch il prima possibile, come descritto di seguito.

Che cosa devo fare?

A causa della gravità di queste vulnerabilità, indipendentemente dal fatto che siano abilitati o meno gli aggiornamenti automatici dei nodi, ti consigliamo di aggiornare manualmente i nodi non appena la patch diventa disponibile. La patch sarà disponibile per tutti i clienti entro il 16 marzo, ma potrebbe essere disponibile in anteprima per te in base alla zona in cui si trova il tuo cluster, secondo la programmazione di release.

Per eseguire l'upgrade, è necessario prima aggiornare il master alla versione più recente. Questa patch sarà disponibile in Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 e Kubernetes 1.7.14-gke.1. I nuovi cluster useranno la versione con patch di default entro il 30 marzo; se crei un nuovo cluster prima di allora, devi specificare la versione con patch da utilizzare.

I clienti di Kubernetes Engine che hanno abilitato gli aggiornamenti automatici dei nodi e che non effettuano l'aggiornamento manuale avranno i loro nodi aggiornati alle versioni con patch entro il 23 aprile. Tuttavia, a causa della natura della vulnerabilità, ti consigliamo di aggiornare manualmente i nodi non appena la patch è disponibile.

Quali vulnerabilità vengono affrontate da questa patch?

La patch attenua le due seguenti vulnerabilità:

La vulnerabilità CVE-2017-1002101 consente ai container che utilizzano i montaggi di volume del sottopercorso di accedere ai file al di fuori del volume. Ciò significa che se stai bloccando l'accesso del container ai volumi hostpath con PodSecurityPolicy, un utente malintenzionato con la possibilità di aggiornare o creare pod può montare qualsiasi hostpath utilizzando qualsiasi altro tipo di volume.

La vulnerabilità CVE-2017-1002102 consente ai container che utilizzano determinati tipi di volume, inclusi secret, mappe di configurazione, volumi previsti o volumi API Downward, di eliminare file al di fuori del volume. Ciò significa che se un container che utilizza uno di questi tipi di volume è compromesso, oppure se consenti a utenti non attendibili di creare pod, un utente malintenzionato potrebbe utilizzare quel container per eliminare file arbitrari sull'host.

Per saperne di più sulla correzione, leggi il post del blog Kubernetes.

Alta
Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...

Kubernetes Engine