Questo documento descrive come rafforzare la sicurezza dei tuoi cluster Google Distributed Cloud.
Protezione dei container mediante SELinux
Puoi proteggere i tuoi container abilitando SELinux, supportato per Red Hat Enterprise Linux (RHEL). Se le macchine host eseguono RHEL e vuoi abilitare SELinux per il cluster, devi abilitare SELinux in tutte le macchine host. Per maggiori dettagli, consulta Proteggere i container con SELinux.
Utilizza seccomp
per limitare i container
La modalità di computing sicuro (seccomp
) è disponibile nella versione 1.11 di
Google Distributed Cloud e successive. L'esecuzione dei 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. In questo modo si riduce la possibilità
di sfruttare le vulnerabilità del kernel.
Il profilo seccomp
predefinito contiene un elenco di chiamate di sistema che un contenitore è autorizzato a effettuare. Tutte le chiamate di sistema non nell'elenco non sono consentite. seccomp
è abilitato per impostazione predefinita nella versione 1.11 di Google Distributed Cloud. 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 a
seccomp
limitazioni.
Come disabilitare seccomp
a livello di cluster o su determinati carichi di lavoro
Puoi disabilitare seccomp
solo durante la creazione o l'upgrade del cluster.
Impossibile 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 caso che alcuni carichi di lavoro debbano eseguire chiamate di sistema
bloccate da seccomp
per impostazione predefinita, non è necessario disabilitare seccomp
sull'intero cluster. Puoi invece scegliere determinati carichi di lavoro da eseguire in
unconfined mode
. L'esecuzione di un carico di lavoro in unconfined mode
libera il carico di lavoro
dalle limitazioni che il profilo seccomp
impone sul 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 contenitori come utente root
Per impostazione predefinita, i processi nei container vengono eseguiti come root
. Ciò rappresenta un potenziale problema di sicurezza, perché se un processo esce dal container, viene eseguito come root
sulla macchina host. Ti consigliamo quindi di eseguire tutti i carichi
di lavoro 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 per quale utente deve essere eseguito il processo all'interno di un container. Il seguente snippet di un Dockerfile
mostra come farlo:
....
#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. L'ID utente (UID) di questo utente è pari a 8877
.
La riga successiva nell'intervallo Dockerfile
esegue il comando USER nonroot
. Questo comando
specifica che da questo punto in poi nell'immagine, i comandi vengono eseguiti come l'utente
nonroot
.
Concedi le autorizzazioni all'UID 8877
in modo che i processi del container 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 come utente root
. Le impostazioni di sicurezza vengono specificate per un pod e vengono applicate a loro volta 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) pari a 8877
. Ricordati di concedere le autorizzazioni necessarie e sufficienti all'UID 8877
in modo che i processi del 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 a root.
I container di sistema in Google Distributed Cloud 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 il valore 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 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 carichi di lavoro dell'utente.
Come disattivare la modalità rootless
A partire dalla release 1.10 di Google Distributed Cloud, i container del piano di controllo Kubernetes e i container di sistema vengono eseguiti come utenti non root per impostazione predefinita.
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 nell'ambiente.
A partire dalla release 1.11 di Google Distributed Cloud, puoi disabilitare la modalità rootless durante l'upgrade del cluster. Se la modalità rootless è disabilitata, i container del piano di controllo Kubernetes e quelli 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, consulta Eseguire l'upgrade dei cluster.
Limitare la possibilità di automodifica dei carichi di lavoro
Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per la modifica automatica. Ad esempio, alcuni carichi di lavoro si adeguano automaticamente verticalmente. Anche se conveniente, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di scalare ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe far cambiare il 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 a modificare se stessi. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, che fornisce 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 ignorarli. Ciò è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicandone gli upgrade. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount
su
Google Distributed Cloud, devi impostare i seguenti parametri in Constraint
:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Disabilita porta di sola lettura kubelet
A partire dalla release 1.15.0, Google Distributed Cloud disabilita per impostazione predefinita la porta 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.
Questa porta è disabilitata per impostazione predefinita solo nei cluster creati con versione 1.15.0 o successive. La porta di sola lettura kubelet 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 successiva.
Questa modifica è stata apportata perché il kubelet divulga informazioni di bassa sensibilità sulla porta 10255
, che non è autenticata. Le informazioni includono quelle complete sulla configurazione per tutti i pod in esecuzione su un nodo, che possono essere preziose per un utente malintenzionato. Espone inoltre metriche e informazioni sullo stato, in grado di fornire insight sensibili all'attività.
La disattivazione della porta di sola lettura kubelet è consigliata da CIS Kubernetes Benchmark.
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.
Monitorare 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 comune di numerazione delle vulnerabilità di Google Cloud e sono collegati dalla pagina principale dei bollettini Google Cloud e dalle note di rilascio di Google Distributed Cloud.
Quando è necessario un intervento da parte del cliente per affrontare queste vulnerabilità elevato e critico, Google contatta i clienti via email. Inoltre, Google potrebbe anche contattare i clienti con contratti di assistenza tramite i canali di assistenza.
Per ulteriori informazioni su come Google gestisce le vulnerabilità e le patch di sicurezza per GKE e GKE Enterprise, consulta Applicazione di 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 di sicurezza Kubernetes che risolvono le vulnerabilità di sicurezza che possono interessare i tuoi cluster.
È tua responsabilità mantenere aggiornati i cluster GKE on Bare Metal. Per ogni release, consulta le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei cluster, pianifica l'aggiornamento a nuove versioni delle patch ogni mese e alle versioni secondarie ogni quattro mesi.
Uno dei molti 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 relativo file kubeconfig viene rinnovato automaticamente. 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.
Utilizza Controlli di servizio VPC con Cloud Interconnect o Cloud VPN
Cloud Interconnect fornisce connessioni a bassa latenza e alta disponibilità che ti consentono di trasferire i dati in modo affidabile tra le tue macchine bare metal on-premise e le reti Virtual Private Cloud (VPC) di Google Cloud. Per saperne di più su Cloud Interconnect, consulta Panoramica del provisioning di Dedicated Interconnect.
Cloud VPN connette in sicurezza la rete peer alla rete Virtual Private Cloud (VPC) tramite una connessione IPsec VPN. Per scoprire di più su Cloud VPN, consulta Panoramica di Cloud VPN.
I Controlli di servizio VPC funzionano con Cloud Interconnect o Cloud VPN per fornire ulteriore sicurezza ai cluster. I controlli di servizio VPC aiutano a mitigare il rischio di esfiltrazione di dati. Utilizzando 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 e configurazione dei perimetri di servizio.
Per proteggere completamente Google Distributed Cloud, devi utilizzare un 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
) - Connettiti all'API 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
) - 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, usa il flag --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.