Rafforza la sicurezza del tuo cluster

Questo documento descrive come rafforzare la sicurezza del tuo GDCV per i cluster Bare Metal.

Protezione dei container mediante SELinux

Puoi proteggere i tuoi container attivando SELinux, che è supportato da Red Hat Enterprise Linux (RHEL). Se sulle tue macchine host è in esecuzione RHEL e vuoi abilitare SELinux per il tuo cluster, devi abilitare SELinux su tutte le macchine host. Per i dettagli, consulta Proteggere i container con SELinux.

Usa seccomp per limitare i container

La modalità Secure Computing (seccomp) è disponibile nella versione 1.11 di GDCV per Bare Metal e versioni successive. L'esecuzione di container con un profilo seccomp migliora la sicurezza del tuo cluster perché limita le chiamate di sistema che i container sono autorizzati a effettuare al kernel. Questo riduce la possibilità di sfruttare le vulnerabilità del kernel.

Il profilo seccomp predefinito contiene un elenco di chiamate di sistema che un container è autorizzato a effettuare. Non sono consentite chiamate di sistema non presenti nell'elenco. seccomp è abilitato per impostazione predefinita nella versione 1.11 di GDCV per Bare Metal. Ciò significa che tutti i container di sistema e i carichi di lavoro dei clienti vengono eseguiti con il profilo seccomp predefinito del runtime dei container. Anche i container e i carichi di lavoro che non specificano un profilo seccomp nei file di configurazione sono soggetti alle limitazioni seccomp.

Come disabilitare seccomp a livello di cluster o su carichi di lavoro specifici

Puoi disabilitare seccomp solo durante la creazione o l'upgrade del cluster. Non è possibile utilizzare bmctl update per disattivare questa funzionalità. Se vuoi disabilitare seccomp all'interno di un cluster, aggiungi la seguente sezione clusterSecurity al file di configurazione del cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableSeccomp: false
...

Nell'improbabile eventualità che alcuni dei tuoi carichi di lavoro debbano eseguire chiamate di sistema che seccomp blocca per impostazione predefinita, non devi disabilitare seccomp nell'intero cluster. Puoi invece individuare carichi di lavoro specifici da eseguire in unconfined mode. L'esecuzione di un carico di lavoro in unconfined mode libera questo carico di lavoro dalle restrizioni imposte dal profilo seccomp al resto del cluster.

Per eseguire un container in unconfined mode, aggiungi la seguente sezione securityContext al manifest del pod:

apiVersion: v1
kind: Pod
....
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
....

Non eseguire i container come utente root

Per impostazione predefinita, i processi nei container vengono eseguiti come root. Questo rappresenta un potenziale problema di sicurezza, poiché se un processo esce dal container, viene eseguito come root sulla macchina host. Conviene quindi eseguire tutti i carichi di lavoro come utente non root.

Le seguenti sezioni descrivono due modi di eseguire i container come utente non root.

Metodo 1: aggiungi l'istruzione USER in Dockerfile

Questo metodo utilizza un Dockerfile per garantire che i container non vengano eseguiti come utente root. In un Dockerfile, puoi specificare per quale utente eseguire il processo all'interno di un container. Il seguente snippet di Dockerfile mostra come fare:

....

#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot

#Run Container as nonroot
USER nonroot
....

In questo esempio, il comando di Linux useradd -u crea un utente chiamato nonroot all'interno del container. Questo utente ha un ID utente (UID) di 8877.

La riga successiva in Dockerfile esegue il comando USER nonroot. Questo comando specifica che, da questo momento in poi nell'immagine, i comandi vengono eseguiti come utente nonroot.

Concedi le autorizzazioni all'UID 8877 in modo che i processi dei container possano essere eseguiti correttamente per nonroot.

Metodo 2: aggiungi i campi securityContext nel file manifest di Kubernetes

Questo metodo utilizza un file manifest di Kubernetes per garantire che i container non vengano eseguiti come utente root. Le impostazioni di sicurezza vengono specificate per un pod, che a loro volta vengono applicate a tutti i container all'interno del pod.

L'esempio seguente mostra un estratto di un file manifest per un determinato pod:

apiVersion: v1
kind: Pod
metadata:
  name: name-of-pod
spec:
  securityContext:
    runAsUser: 8877
    runAsGroup: 8877
....

Il campo runAsUser specifica che per tutti i container nel pod, tutti i processi vengono eseguiti con l'ID utente 8877. Il campo runAsGroup specifica che questi processi hanno un ID gruppo principale (GID) di 8877. Ricordati di concedere le autorizzazioni necessarie e sufficienti all'UID 8877 in modo che i processi dei container possano essere eseguiti correttamente.

Ciò garantisce che i processi all'interno di un container vengano eseguiti come UID 8877, che ha meno privilegi rispetto al root.

I container di sistema in GKE su Bare Metal aiutano a installare e gestire i cluster. Gli UID e i GID utilizzati da questi container possono essere controllati dal campo startUIDRangeRootlessContainers nella specifica del cluster. startUIDRangeRootlessContainers è un campo facoltativo che, se non specificato, ha un valore di 2000. I valori consentiti per startUIDRangeRootlessContainers sono 1000-57000. Il valore startUIDRangeRootlessContainers può essere modificato solo durante gli upgrade. I container di sistema utilizzano gli UID e i GID compresi nell'intervallo compreso tra startUIDRangeRootlessContainers e startUIDRangeRootlessContainers + 2999.

L'esempio seguente mostra un estratto di un file manifest per una risorsa cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: name-of-cluster
spec:
 clusterSecurity:
    startUIDRangeRootlessContainers: 5000
...

Scegli il valore di startUIDRangeRootlessContainers in modo che gli spazi UID e GID utilizzati dai container di sistema non si sovrappongano a quelli assegnati ai carichi di lavoro degli utenti.

Come disattivare la modalità rootless

A partire dalla release 1.10 di GKE su Bare Metal, i container del piano di controllo e i container di sistema di Kubernetes vengono eseguiti come utenti non root per impostazione predefinita. GKE su Bare Metal assegna a questi utenti UID e GID nell'intervallo 2000-4999. Tuttavia, questa assegnazione può causare problemi se questi UID e GID sono già stati allocati ai processi in esecuzione all'interno del tuo ambiente.

A partire dalla release 1.11 di GKE su Bare Metal, puoi disabilitare la modalità rootless quando esegui l'upgrade del cluster. Se la modalità rootless è disabilitata, i container del piano di controllo Kubernetes e i container di sistema vengono eseguiti come utente root.

Per disattivare la modalità rootless, procedi nel seguente modo:

  1. Aggiungi la seguente sezione clusterSecurity al file di configurazione del cluster:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableRootlessContainers: false
...

  2. Esegui l'upgrade del cluster. Per maggiori dettagli, vedi Eseguire l'upgrade dei cluster.

Limita la capacità dei carichi di lavoro di auto-modificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione alla modifica automatica. Ad esempio, alcuni carichi di lavoro scalano automaticamente verticalmente. Sebbene sia pratico, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore scalabilità nel cluster. Ad esempio, un utente malintenzionato potrebbe gestire automaticamente un carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi più elevati, che esiste nello stesso spazio dei nomi.

Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione per modificare autonomamente. Se è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria Gatekeeper open source, che offre diversi criteri di sicurezza utili.

Quando esegui il deployment dei criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di bypassare i criteri. Questo è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicare upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su GDCV per Bare Metal, devi impostare i seguenti parametri in Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers: []

Disattiva la porta di sola lettura kubelet

A partire dalla release 1.15.0, GKE su Bare Metal disabilita per impostazione predefinita la porta 10255, la porta kubelet di sola lettura. Tutti i carichi di lavoro dei clienti configurati per leggere i dati da questa porta kubelet non sicura 10255 devono eseguire la migrazione in modo da utilizzare la porta kubelet sicura 10250.

Solo i cluster creati con la versione 1.15.0 o successive hanno questa porta disabilitata per impostazione predefinita. La porta kubelet di sola lettura 10255 rimane accessibile per i cluster creati con una versione precedente alla 1.15.0, anche dopo un upgrade del cluster alla versione 1.15.0 o successive.

Questa modifica è stata apportata perché kubelet divulga informazioni a bassa sensibilità sulla porta 10255, che non è autenticata. Le informazioni includono le informazioni complete sulla configurazione per tutti i pod in esecuzione su un nodo, che possono essere utili per un utente malintenzionato. Espone inoltre metriche e informazioni sullo stato, che possono fornire insight sensibili sull'attività.

La disabilitazione della porta di sola lettura kubelet è consigliata dal benchmark CIS per Kubernetes.

Manutenzione

Il monitoraggio dei bollettini sulla sicurezza e l'upgrade dei cluster sono importanti misure di sicurezza da adottare una volta che i cluster sono attivi e in esecuzione.

Monitora i bollettini sulla sicurezza

Il team per la sicurezza di GKE pubblica bollettini sulla sicurezza per le vulnerabilità con gravità alta e critica.

Questi bollettini seguono uno schema di numerazione delle vulnerabilità comune di Google Cloud e sono collegati tramite link dalla pagina principale dei bollettini di Google Cloud e dalle note di rilascio di GKE su Bare Metal.

Utilizza questo feed XML per abbonarti ai bollettini sulla sicurezza per GKE su Bare Metal e prodotti correlati. Sottoscrivi

Quando è necessario un intervento per risolvere queste vulnerabilità critiche, Google contatta i clienti via email. Inoltre, Google potrebbe contattare i clienti con contratti di assistenza anche tramite i canali di assistenza.

Per maggiori informazioni su come Google gestisce le vulnerabilità e le patch di sicurezza per GKE e GKE Enterprise, consulta Applicazione delle patch di sicurezza.

Esegui l'upgrade dei cluster

Kubernetes introduce regolarmente nuove funzionalità e fornisce patch di sicurezza. Le release di GKE su Bare Metal incorporano i miglioramenti di sicurezza di Kubernetes che risolvono le vulnerabilità di sicurezza che potrebbero interessare i cluster.

È tua responsabilità mantenere aggiornati i cluster GKE su Bare Metal. Leggi le note di rilascio per ogni release. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster, pianifica l'aggiornamento ogni mese alle nuove versioni delle patch e alle versioni secondarie ogni quattro mesi.

Uno dei numerosi vantaggi dell'upgrade di un cluster è l'aggiornamento automatico del file kubeconfig del cluster. Il file kubeconfig autentica un utente in un cluster. Il file kubeconfig viene aggiunto alla directory del cluster quando crei un cluster con bmctl. Il nome e il percorso predefiniti sono bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. Quando esegui l'upgrade di un cluster, il relativo file kubeconfig viene rinnovato automaticamente. Altrimenti, il file kubeconfig scade un anno dopo la creazione.

Per informazioni su come eseguire l'upgrade dei cluster, consulta Eseguire l'upgrade dei cluster.

Utilizzare i Controlli di servizio VPC con Cloud Interconnect o Cloud VPN

Cloud Interconnect fornisce connessioni a bassa latenza e ad alta disponibilità che ti consentono di trasferire i dati in modo affidabile tra le tue macchine bare metal on-premise e le reti VPC (Virtual Private Cloud) di Google Cloud. Per saperne di più su Cloud Interconnect, consulta la panoramica del provisioning di Dedicated Interconnect.

Cloud VPN connette in modo sicuro la tua rete peer alla tua rete Virtual Private Cloud (VPC) tramite una connessione IPsec VPN. Per scoprire di più su Cloud VPN, consulta la panoramica su Cloud VPN.

Controlli di servizio VPC funziona con Cloud Interconnect o Cloud VPN per fornire maggiore sicurezza ai tuoi cluster. Controlli di servizio VPC aiuta a ridurre il rischio di esfiltrazione di dati. Utilizzando i Controlli di servizio VPC, puoi aggiungere progetti ai perimetri di servizio che proteggono risorse e servizi da richieste che hanno origine al di fuori del perimetro. Per scoprire di più sui perimetri di servizio, vedi Dettagli e configurazione dei perimetri di servizio.

Per proteggere completamente GKE su Bare Metal, devi utilizzare il VIP con restrizioni e aggiungere le API seguenti al perimetro di servizio:

  • API Artifact Registry (artifactregistry.googleapis.com)
  • API Resource Manager (cloudresourcemanager.googleapis.com)
  • API Compute Engine (compute.googleapis.com)
  • API Connect Gateway (connectgateway.googleapis.com)
  • API Google Container Registry (containerregistry.googleapis.com)
  • API GKE Connect (gkeconnect.googleapis.com)
  • API GKE Hub (gkehub.googleapis.com)
  • API GKE On-Prem (gkeonprem.googleapis.com)
  • API Identity and Access Management (IAM) (iam.googleapis.com)
  • API Cloud Logging (logging.googleapis.com)
  • API Cloud Monitoring (monitoring.googleapis.com)
  • Config Monitoring per API Ops (opsconfigmonitoring.googleapis.com)
  • API Service Control (servicecontrol.googleapis.com)
  • API Cloud Storage (storage.googleapis.com)

Quando utilizzi bmctl per creare o eseguire l'upgrade di un cluster, usa il flag --skip-api-check per ignorare la chiamata all'API Service Usage (serviceusage.googleapis.com). L'API Service Usage non è supportata dai Controlli di servizio VPC.