Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Rafforzare la sicurezza del cluster

Questo documento descrive come rafforzare la sicurezza dei cluster creati con il software Google Distributed Cloud solo per bare metal.

Protezione dei container mediante SELinux

Puoi proteggere i container attivando SELinux, supportato per Red Hat Enterprise Linux (RHEL). Se sulle tue macchine host è in esecuzione RHEL e vuoi attivare SELinux per il tuo cluster, devi attivare SELinux su tutte le tue macchine host. Per maggiori dettagli, consulta Proteggi i container utilizzando SELinux.

Utilizza `seccomp` per limitare i container

La modalità di computing sicuro (seccomp) è disponibile nella versione 1.11 e successive di Google Distributed Cloud. L'esecuzione di container con un profilo seccomp migliora la sicurezza del cluster perché limita le chiamate di sistema che i container possono effettuare al kernel. In questo modo si riduce la probabilità che vengano sfruttate le vulnerabilità del kernel.

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

Come disattivare `seccomp` a livello di cluster o su workload specifici

Puoi disattivare seccomp solo durante la creazione o l'upgrade del cluster. bmctl update non può essere utilizzato per disattivare questa funzionalità. Se vuoi disattivare 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 caso in cui alcuni dei tuoi workload debbano eseguire chiamate di sistema bloccate per impostazione predefinita da seccomp, non è necessario disabilitare seccomp sull'intero cluster. Puoi invece selezionare workload specifici da eseguire in unconfined mode. L'esecuzione di un workload in unconfined mode lo libera dalle limitazioni 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, perché se un processo esce dal container, viene eseguito come root sulla macchina host. È quindi consigliabile eseguire tutti i workload come utente non root.

Le sezioni seguenti descrivono due modi per 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 l'utente con cui deve essere eseguito il processo all'interno di un container. Il seguente snippet di un 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 Linux useradd -u crea un utente denominato nonroot all'interno del container. Questo utente ha un ID utente (UID) pari a 8877.

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

Concedi le autorizzazioni all'UID 8877 in modo che i processi del 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 e, 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 (GID) principale di 8877. Ricordati di concedere le autorizzazioni necessarie e sufficienti all'UID 8877 in modo che i processi del container possano essere eseguiti correttamente.

In questo modo, i processi all'interno di un container vengono eseguiti come UID 8877, che ha meno privilegi di root.

I container di sistema in Google Distributed Cloud solo software 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 pari a 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 nell'intervallo da startUIDRangeRootlessContainers a 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 per startUIDRangeRootlessContainers in modo che gli spazi UID e GID utilizzati dai container di sistema non si sovrappongano a quelli assegnati ai workload degli utenti.

Come disattivare la modalità senza root

A partire dalla versione 1.10 di Google Distributed Cloud, i container del control plane Kubernetes e i container di sistema vengono eseguiti per impostazione predefinita come utenti non root. Google Distributed Cloud 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 nel tuo ambiente.

A partire dalla versione 1.11, puoi disattivare la modalità rootless quando esegui l'upgrade del cluster. Quando la modalità rootless è disabilitata, i container del control plane Kubernetes e i container di sistema vengono eseguiti come utente root.

Per disattivare la modalità rootless, segui questi passaggi:

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

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

Limita la capacità dei workload di modificarsi autonomamente

Alcuni workload Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per l'automodifica. Ad esempio, alcuni workload eseguono la scalabilità automatica verticale in autonomia. Sebbene sia comodo, questo può consentire a un malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore escalation nel cluster. Ad esempio, un aggressore potrebbe fare in modo che un workload sul nodo si modifichi per essere eseguito come un account di servizio con più privilegi che esiste nello stesso spazio dei nomi.

Idealmente, ai workload non dovrebbe essere concessa l'autorizzazione per modificarsi in primo luogo. Quando l'automodifica è necessaria, puoi limitare le autorizzazioni applicando i vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount della libreria Gatekeeper open source, che fornisce diverse policy di sicurezza utili.

Quando esegui il deployment delle policy, di solito è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di bypassare le policy. Questo è necessario per consentire ai controller di apportare modifiche al cluster, ad esempio applicare upgrade del cluster. Ad esempio, se esegui il deployment della policy NoUpdateServiceAccount sui tuoi cluster, devi impostare i seguenti parametri in Constraint:

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

Disabilita la porta di sola lettura di kubelet

A partire dalla versione 1.15.0, Google Distributed Cloud disabilita per impostazione predefinita la porta 10255, ovvero la porta di sola lettura di kubelet. Tutti i workload dei clienti configurati per leggere i dati da questa porta kubelet non sicura 10255 devono eseguire la migrazione per 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 di sola lettura kubelet 10255 rimane accessibile per i cluster creati con una versione precedente alla 1.15.0, anche dopo l'upgrade del cluster alla versione 1.15.0 o successiva.

Questa modifica è stata apportata perché il kubelet divulga informazioni a bassa sensibilità sulla porta 10255, che non è autenticata. Le informazioni includono i dati di configurazione completi di tutti i pod in esecuzione su un nodo, che possono essere utili per un malintenzionato. Inoltre, espone metriche e informazioni sullo stato, che possono fornire insight sensibili per l'attività.

La disattivazione della porta di sola lettura di kubelet è consigliata dal benchmark CIS 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 funzionanti.

Monitora i bollettini sulla sicurezza

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

Questi bollettini seguono uno schema di numerazione delle vulnerabilità Google Cloud comune e sono collegati alla pagina principale dei bollettiniGoogle Cloud e alle note di rilascio.

Utilizza questo feed XML per iscriverti ai bollettini sulla sicurezza per Google Kubernetes Engine (GKE) e i prodotti correlati.

Quando è richiesta l'azione del cliente per risolvere queste vulnerabilità elevate e critiche, Google contatta i clienti via email. Inoltre, Google potrebbe anche contattare i clienti con contratti di assistenza tramite i canali di assistenza.

Per saperne di più su come Google gestisce le vulnerabilità di sicurezza e le patch per GKE, consulta Applicazione delle patch di sicurezza.

Esegui l'upgrade dei cluster

Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce patch di sicurezza. Le release di Google Distributed Cloud incorporano miglioramenti della sicurezza di Kubernetes che risolvono le vulnerabilità di sicurezza che potrebbero interessare i tuoi cluster.

Sei responsabile di mantenere aggiornati i tuoi cluster. Per ogni release, consulta le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster, pianifica l'aggiornamento alle nuove release delle patch ogni mese e alle versioni secondarie ogni quattro mesi.

Uno dei numerosi vantaggi dell'upgrade di un cluster è che aggiorna automaticamente il 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 file kubeconfig del cluster viene rinnovato automaticamente. In caso contrario, il file kubeconfig scade un anno dopo la sua creazione.

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

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

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

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

I Controlli di servizio VPC funzionano con Cloud Interconnect o Cloud VPN per fornire una sicurezza aggiuntiva ai tuoi cluster. I Controlli di servizio VPC contribuiscono a mitigare 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 provenienti dall'esterno del perimetro. Per saperne di più sui perimetri di servizio, consulta Dettagli e configurazione del perimetro di servizio.

Per proteggere completamente i cluster creati con Google Distributed Cloud, devi utilizzare il VIP limitato e aggiungere le seguenti API 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 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)
API Config Monitoring for Ops (opsconfigmonitoring.googleapis.com)
API Service Control (servicecontrol.googleapis.com)
API Cloud Storage (storage.googleapis.com)