Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Rafforza la sicurezza del cluster

Questo documento descrive come rafforzare la sicurezza del tuo sistema Google Distributed Cloud cluster.

Protezione dei container mediante SELinux

Puoi proteggere i tuoi container attivando SELinux, supportato per Red RHEL (Hat Enterprise Linux). Se le tue macchine host eseguono RHEL e vuoi attivare SELinux per il tuo cluster, devi attivare SELinux in tutte le tue macchine host. Scopri come proteggere i container con SELinux per maggiori dettagli.

Usa `seccomp` per limitare i contenitori

La modalità di computing sicuro (seccomp) è disponibile nella versione 1.11 di Google Distributed Cloud e versioni successive. Esecuzione dei container con un profilo seccomp migliora la sicurezza del tuo cluster perché limita le chiamate di sistema che i container possono essere inviati al kernel. Questo riduce la possibilità le vulnerabilità sfruttate.

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

Come disabilitare `seccomp` a livello di cluster o su determinati carichi di lavoro

Puoi disattivare seccomp solo durante la creazione o l'upgrade del cluster. Non è possibile utilizzare bmctl update per disattivare questa funzionalità. Se vuoi disattivare seccomp all'interno di un cluster, aggiungi la seguente sezione clusterSecurity al 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 bloccate da seccomp per impostazione predefinita, non è necessario disattivare seccomp per l'intero cluster. In alternativa, puoi individuare carichi di lavoro specifici da eseguire in unconfined mode. L'esecuzione di un carico di lavoro in unconfined mode lo libera dalle limitazioni che il profilo seccomp impone al resto dei in un cluster Kubernetes.

Per eseguire un container in unconfined mode, aggiungi quanto segue securityContext al file 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. Ciò rappresenta un potenziale un problema di sicurezza, perché se un processo esce dal container, viene eseguito come root sul computer host. Pertanto, ti consigliamo di eseguire tutti i carichi di lavoro come utente non root.

Le sezioni seguenti descrivono due modi per eseguire i contenitori come utente non root.

Metodo 1: aggiungi l'istruzione `USER` in `Dockerfile`

Questo metodo utilizza un Dockerfile per assicurarsi che i container non vengano eseguiti come utente root. In un Dockerfile, puoi specificare per quale utente viene eseguito il processo all'interno di un contenitore deve essere eseguito. Il seguente snippet di un Dockerfile mostra come eseguire questa operazione:

....

#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 con nome nonroot all'interno del container. Questo utente ha un ID utente (UID) pari a 8877.

La riga successiva in 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 contenitore possano essere eseguiti correttamente per nonroot.

Metodo 2: aggiungere campi securityContext nel file manifest di Kubernetes

Questo metodo utilizza un file manifest di Kubernetes per garantire che i container non vengano eseguiti in qualità di utente root. Le impostazioni di sicurezza sono specificate per un pod e quelle 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, processi vengono eseguiti con l'ID utente 8877. Il campo runAsGroup specifica che queste procedure hanno un ID gruppo principale (GID) pari a 8877. Ricorda di concedere alla classe necessarie e sufficienti per l'UID 8877, in modo che il container processi possono essere eseguiti correttamente.

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

I container di sistema in Google Distributed Cloud aiutano a installare e gestire i cluster. Gli UID e i GID utilizzati da questi contenitori possono essere controllati dal campo startUIDRangeRootlessContainers nella specifica del cluster. startUIDRangeRootlessContainers è un campo facoltativo che, se non specificato, ha un valore 2000. I valori consentiti per startUIDRangeRootlessContainers sono 1000-57000. Il valore startUIDRangeRootlessContainers può essere modificato solo durante gli upgrade. I contenitori 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 un cluster risorsa:

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 contenitori di sistema non si sovrappongano a quelli assegnati ai carichi di lavoro degli utenti.

Come disattivare la modalità senza root

A partire dalla release 1.10 di Google Distributed Cloud, i contenitori del piano di controllo Kubernetes e i contenitori di sistema vengono eseguiti come utenti non root per impostazione predefinita. Google Distributed Cloud assegna a questi utenti UID e GID nell'intervallo2000-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 Google Distributed Cloud, puoi disabilitare il rootless quando esegui l'upgrade del cluster. Quando la modalità senza root è disattivata, i contenitori del piano di controllo e i contenitori di sistema di Kubernetes vengono eseguiti come utente root.

Per disattivare la modalità senza root, segui questi passaggi:

Aggiungi la seguente sezione clusterSecurity alla configurazione del cluster file:

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, consulta Eseguire l'upgrade dei cluster.

Limitare la capacità dei carichi di lavoro di automodificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione si automodifica. Ad esempio, alcuni carichi di lavoro eseguono la scalabilità automatica verticale. Mentre questo può consentire a un utente malintenzionato che ha già compromesso un nodo di e riassegnarle ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe avere sul nodo stesso cambia in modo che venga eseguito come un account di servizio con privilegi nello stesso spazio dei nomi.

Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione per modificarsi. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli di Gatekeeper o Policy Controller, come NoUpdateServiceAccount dalla libreria open source Gatekeeper, che offre diversi criteri.

Quando esegui il deployment dei criteri, di solito è necessario consentire ai controller che gestire il ciclo di vita del cluster per bypassare i criteri. Questa operazione è necessaria per I controller possono apportare modifiche al cluster, ad esempio applicando upgrade. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount Google Distributed Cloud, devi impostare i seguenti parametri in Constraint:

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

Disattiva la porta di sola lettura di Kubelet

A partire dalla release 1.15.0, Google Distributed Cloud disabilita la porta per impostazione predefinita 10255, la porta di sola lettura kubelet. Tutti i carichi di lavoro 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 disattivata per impostazione predefinita. La porta di sola lettura kubelet 10255 rimane accessibile per i cluster creato 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é kubelet lascia trapelare informazioni a bassa sensibilità tramite la porta 10255, che non è autenticata. Le informazioni includono le informazioni di configurazione complete per tutti i pod in esecuzione su un nodo, che possono essere utili per un malintenzionato. Mette inoltre a disposizione metriche e informazioni sullo stato, che possono fornire approfondimenti sensibili per l'attività.

La disattivazione della porta di sola lettura kubelet è consigliata da Kubernetes CIS Benchmark.

Manutenzione

Il monitoraggio dei bollettini sulla sicurezza e l'upgrade dei cluster sono importanti misure di sicurezza da adottare dopo l'avvio dei cluster.

Monitorare i bollettini sulla sicurezza

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

Questi bollettini seguono una numerazione comune di vulnerabilità di Google Cloud e sono collegati dalla pagina principale dei bollettini Google Cloud e Note di rilascio di Google Distributed Cloud.

Utilizza questo feed XML per iscriverti ai bollettini sulla sicurezza per Google Distributed Cloud e i prodotti correlati.

Quando è necessaria un'azione da parte del cliente per risolvere queste vulnerabilità gravi 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à e i patch di sicurezza per GKE e GKE Enterprise, consulta 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 la sicurezza di Kubernetes miglioramenti che risolvono le vulnerabilità di sicurezza che potrebbero interessare i tuoi cluster.

È tua responsabilità mantenere i cluster Google Distributed Cloud al data. Per ogni release, consulta le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster, pianifica di eseguire l'aggiornamento alle nuove release di patch ogni mese e alle versioni minori ogni quattro mesi.

Uno dei molti vantaggi dell'upgrade di un cluster è che esegue aggiorna 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 relativo file kubeconfig viene automaticamente rinnovato. In caso contrario, 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 alta disponibilità che consentono di trasferire i dati in modo affidabile tra le macchine bare metal on-premise Reti Virtual Private Cloud (VPC) di Google Cloud. Per saperne di più su Cloud Interconnect, vedi Provisioning di Dedicated Interconnect Panoramica.

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

I Controlli di servizio VPC funzionano con Cloud Interconnect o Cloud VPN per fornire sicurezza aggiuntiva ai tuoi cluster. I Controlli di servizio VPC contribuiscono a mitigare il rischio di esfiltrazione di dati. Con i Controlli di servizio VPC, puoi aggiungere progetti ai perimetri di servizio che proteggono risorse e servizi dalle richieste che hanno origine al di fuori del perimetro. Per saperne di più sui perimetri di servizio, consulta Dettagli dei perimetri di servizio configurazione.

Per proteggere completamente Google Distributed Cloud, devi utilizzare VIP con restrizioni 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 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.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)

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