Questo documento descrive come rafforzare la sicurezza dei tuoi cluster GKE su Bare Metal.
Protezione dei container mediante SELinux
Puoi proteggere i tuoi container attivando SELinux, che è supportato per Red Hat Enterprise Linux (RHEL) e CentOS. Se le tue macchine host eseguono RHEL o CentOS e vuoi abilitare SELinux per il tuo cluster, devi abilitare SELinux in 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 GKE su Bare Metal.
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. 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 GKE su 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 caso 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 scegliere 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 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 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. Ti consigliamo quindi di 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 Dockerfile
, puoi specificare per quale utente deve essere eseguito 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 denominato nonroot
all'interno del container. Questo utente ha un ID utente (UID) pari a 8877
.
Nella riga successiva del file Dockerfile
viene eseguito 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 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, a loro volta 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.
In questo modo, i processi all'interno di un container vengono eseguiti come UID 8877
, che ha meno privilegi rispetto all'account root.
I container di sistema in GKE su Bare Metal aiutano a installare e gestire i cluster. Gli UID e GID utilizzati da questi container possono essere controllati dal campo startUIDRangeRootlessContainers
nella specifica del cluster. startUIDRangeRootlessContainers
è un campo facoltativo che, se non specificato,
avrà un valore di 2000. I valori consentiti per startUIDRangeRootlessContainers
sono 1000-57.000. Il valore startUIDRangeRootlessContainers
può essere modificato
solo durante gli upgrade. I container di sistema utilizzeranno gli UID e gli ID GID compresi nell'intervallo da startUIDRangeRootlessContainers
a startUIDRangeRootlessContainers
+ 2999.
L'esempio seguente mostra un estratto di un file manifest per un cluster:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
Il valore di startUIDRangeRootlessContainers
deve essere scelto in modo che lo spazio UID e GID utilizzato dai container di sistema non si sovrapponga 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 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 nel 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 non è attiva, i container del piano di controllo e i container di sistema Kubernetes vengono eseguiti comeutente roott.
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 Eseguire l'upgrade dei cluster.
Limitare la capacità dei carichi di lavoro di effettuare modifiche automatiche
Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, sono autorizzati a modificarsi autonomamente. Ad esempio, alcuni carichi di lavoro scalano automaticamente in verticale. Per quanto pratico, questa operazione può consentire a un utente malintenzionato che ha già compromesso un nodo di scalare ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe avere un carico di lavoro sul nodo in modo da essere eseguito come account di servizio con privilegi più elevati all'interno dello stesso spazio dei nomi.
Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione iniziale per apportare modifiche. Se è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria Gatekeeper open source, 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. 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 GKE su Bare Metal, devi impostare i seguenti parametri in Constraint
:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Disattiva porta kubelet di sola lettura
A partire dalla release 1.15.0, GKE su Bare Metal disabilita per impostazione predefinita la porta kubelet di sola lettura 10255. Tutti i carichi di lavoro dei clienti configurati per leggere i dati da questa porta kubelet 10255 non sicura 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 successiva.
Questa modifica è stata apportata perché kubelet divulga informazioni a bassa sensibilità sulla 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 utente malintenzionato. Mostra inoltre metriche e informazioni sullo stato, che possono fornire insight sensibili all'attività.
La disabilitazione della porta kubelet di sola lettura è consigliata dal CIS Kubernetes Benchmark. Per disabilitare manualmente la porta nella versione 1.14, vedi Disabilitare la porta kubelet di sola lettura.
Manutenzione
Il monitoraggio dei bollettini sulla sicurezza e l'upgrade dei cluster sono importanti misure di sicurezza da adottare quando i cluster sono attivi e in esecuzione.
Monitora i bollettini sulla sicurezza
Il team per la sicurezza di GKE Enterprise pubblica bollettini sulla sicurezza per individuare le vulnerabilità con gravità alta e critica.
Questi bollettini seguono uno schema di numerazione delle vulnerabilità comune di Google Cloud e sono collegati dalla pagina principale dei bollettini di Google Cloud e dalle note di rilascio di GKE su Bare Metal. Utilizza questo feed XML per iscriverti ai bollettini
sulla sicurezza per GKE su Bare Metal e i prodotti correlati:
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml
Quando è necessario un intervento da parte del cliente per risolvere queste vulnerabilità critiche, Google lo contatta via email. Inoltre, Google potrebbe contattare i clienti con contratti di assistenza anche tramite canali di assistenza.
Per ulteriori informazioni su come Google gestisce vulnerabilità e 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 GKE su Bare Metal incorporano i miglioramenti di sicurezza di Kubernetes che risolvono le vulnerabilità di sicurezza che potrebbero interessare i tuoi cluster.
Spetta a te mantenere aggiornati i cluster GKE. Per ogni release, consulta le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster GKE, pianifica l'aggiornamento alle nuove patch ogni mese e alle versioni secondarie ogni tre mesi.
Uno dei tanti 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.