Questo documento descrive come rafforzare la sicurezza dei tuoi cluster Anthos su cluster 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 abilitarle in tutte le tue macchine host. Per ulteriori dettagli, consulta la pagina su come proteggere i container tramite SELinux.
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 si svolge all'esterno del container, tale processo
viene eseguito come root sulla macchina host. Si consiglia quindi di eseguire tutti i carichi di lavoro come utente non root.
Le seguenti sezioni descrivono due modi per eseguire i container come utenti non root.
Metodo n. 1: aggiungi l'istruzione USER in Dockerfile
Questo metodo utilizza un Dockerfile per garantire che i container non vengano eseguiti come utenti root. In un Dockerfile, puoi specificare quale utente deve essere eseguito nel processo all'interno di un container. Il seguente snippet di 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 chiamato nonroot
all'interno del container. Questo utente ha un ID utente (UID) 8877.
La riga successiva in Dockerfile esegue il comando USER nonroot. Questo comando specifica che da questo momento 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 campi securityContext nel file manifest Kubernetes
Questo metodo utilizza un file manifest Kubernetes per garantire che i container non vengano eseguiti come utenti root. Le impostazioni di sicurezza vengono specificate per un pod, le quali vengono a loro volta applicate a tutti i container all'interno del pod.
Nell'esempio seguente è riportato 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 ID utente 8877. Il campo runAsGroup specifica che questi
processi hanno un ID gruppo principale (GID) di 8877. Ricorda 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 al root.
I container di sistema nei cluster Anthos su Bare Metal utilizzano UID e GID nell'intervallo 2000-4999. Pertanto, quando assegni le autorizzazioni ai carichi di lavoro utente, utilizza ID e GID che non rientrano in questo intervallo riservato.
Limita la capacità di modificare autonomamente i carichi di lavoro
Alcuni carichi di lavoro Kubernetes, in particolare i carichi di lavoro di sistema, dispongono dell'autorizzazione per l'automodifica. Ad esempio, alcuni carichi di lavoro scalano automaticamente in verticale. Sebbene sia pratico, in questo modo è possibile consentire a un utente malintenzionato che ha già compromesso un nodo di esplodere ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe fare in modo che un carico di lavoro sul nodo si modifichi per funzionare come un 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 apportare modifiche in primo luogo. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount, nella 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 ignorare i criteri. Questo è necessario per consentire ai controller di apportare modifiche al cluster, ad esempio agli upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount nei cluster Anthos su Bare Metal, devi impostare i seguenti parametri in Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Manutenzione
Il monitoraggio dei bollettini di sicurezza e l'upgrade dei cluster sono misure di sicurezza importanti da adottare una volta che i cluster sono in esecuzione.
Monitorare i bollettini di sicurezza
Il team per la sicurezza di Anthos pubblica bollettini sulla sicurezza per le vulnerabilità di gravità elevata e critica.
Questi bollettini seguono uno schema di numerazione delle vulnerabilità Google Cloud comune e sono collegati dalla pagina dei bollettini principali di Google Cloud e dai cluster Anthos sulle note di rilascio di Bare Metal. Utilizza questo feed XML per iscriverti ai bollettini di sicurezza per i cluster Anthos su Bare Metal e sui prodotti correlati:
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
Quando è richiesto un intervento da parte del cliente per far fronte a queste vulnerabilità alte e critiche, Google contatta i clienti via email. Inoltre, Google potrebbe anche contattare i clienti con contratti di assistenza tramite canali di assistenza.
Per scoprire di più su come Google gestisce le vulnerabilità e le patch di sicurezza per GKE e Anthos, consulta le patch di sicurezza.
Esegui l'upgrade dei cluster
Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce patch di sicurezza. I cluster Anthos sulle release bare metal incorporano miglioramenti della sicurezza di Kubernetes che risolvono le vulnerabilità di sicurezza che possono influire sui tuoi cluster.
Sei responsabile dell'aggiornamento dei tuoi cluster Anthos. Per ogni release, consulta le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster Anthos, pianifica l'aggiornamento alle nuove release di patch ogni mese e alle versioni secondarie ogni tre 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 di tale cluster viene rinnovato automaticamente. In caso contrario, il file kubeconfig scade un anno dopo la creazione.
Per informazioni su come eseguire l'upgrade dei cluster, vedi eseguire l'upgrade dei cluster.