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 abilitarlo in tutte le macchine host. Per maggiori dettagli, consulta Proteggere i container tramite SELinux.
Utilizza seccomp per limitare i container
La modalità di computing sicura (seccomp) è disponibile nella versione 1.11 di Anthos clusters on bare metal.
L'esecuzione di container con un profilo seccomp migliora la sicurezza del tuo cluster perché limita le chiamate di sistema che i container sono autorizzati a eseguire sul kernel. In questo modo si riducono le possibilità di sfruttamento delle vulnerabilità del kernel.
Il profilo seccomp predefinito contiene un elenco di chiamate di sistema che un container
può eseguire. Tutte le chiamate di sistema non incluse nell'elenco non sono consentite. seccomp
è abilitato per impostazione predefinita nella versione 1.11 di Anthos clusters on 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 del container. Anche i container e i carichi di lavoro che non specificano un profilo seccomp nei loro file di configurazione sono soggetti a limitazioni seccomp.
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
che seccomp blocca per impostazione predefinita, non è necessario disabilitare seccomp sull'intero cluster. In alternativa, puoi scegliere determinati carichi di lavoro da eseguire in
unconfined mode. L'esecuzione di un carico di lavoro in unconfined mode libera quel carico di lavoro dalle restrizioni che il profilo seccomp impone 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 container come utente root
Per impostazione predefinita, i processi nei container vengono eseguiti come root. Questo pone un potenziale problema di sicurezza, perché se un processo esce dal container, quel processo viene eseguito come root sulla macchina host. Ti consigliamo quindi di eseguire
tutti i carichi di lavoro come utenti non root.
Le seguenti sezioni 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 utenti root. In un Dockerfile, puoi specificare a quale utente deve essere eseguito il processo all'interno del container. Il seguente snippet da 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. Questo utente ha un ID utente (UID) di 8877.
La riga successiva in Dockerfile esegue il comando USER nonroot. Questo comando specifica che, a partire da questo punto 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 utenti root. Le impostazioni di sicurezza vengono specificate per un pod e vengono applicate a tutti i container all'interno del pod.
L'esempio seguente mostra un estratto del 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 (GID) principale di 8877. Ricorda di concedere le autorizzazioni necessarie e sufficienti all'UID 8877 per consentire l'esecuzione corretta dei processi container.
Questo 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 in Anthos clusters on bare metal aiutano a installare e gestire i cluster e hanno UID e GID nell'intervallo 2000-4999. Pertanto, quando assegni le autorizzazioni ai carichi di lavoro degli utenti, utilizza UID e GID che non sono inclusi in questo intervallo riservato.
Come disattivare la modalità rootless
A partire dalla versione 1.10 di Anthos clusters on bare metal, i container del piano di controllo e i container di sistema di Kubernetes vengono eseguiti per impostazione predefinita come utenti non principali. Anthos clusters on bare metal assegna questi UID e GID a questi utenti nell'intervallo 2000-4999. Tuttavia, questa assegnazione può causare problemi se tali UID e GID sono già stati assegnati a processi in esecuzione all'interno del tuo ambiente.
A partire dalla versione 1.11 di Anthos clusters on bare metal, puoi disabilitare la modalità rootless quando esegui l'upgrade del cluster. Se la modalità rootless è disabilitata, i container del piano di controllo e i container di sistema Kubernetes vengono eseguiti come utente root.
Per disattivare la modalità rootless, procedi nel seguente modo:
Aggiungi la seguente sezione
clusterSecurityal 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.
Limita la capacità di modifica dei carichi di lavoro
Alcuni carichi di lavoro Kubernetes, in particolare i carichi di lavoro di sistema, sono autorizzati ad apportare modifiche in autonomia. Ad esempio, alcuni carichi di lavoro vengono scalati automaticamente in verticale. Mentre è pratico, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di fugare ulteriormente nel cluster. Ad esempio, un utente malintenzionato potrebbe modificare un carico di lavoro sul nodo stesso per eseguire un account di servizio con privilegi più esistente nello stesso spazio dei nomi.
Idealmente, ai primi carichi di lavoro non dovrebbe essere concessa l'autorizzazione per potersi modificare. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount, provenienti 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 bypassare i criteri. Questo è necessario in modo che i controller possano apportare modifiche al cluster, ad esempio applicando gli upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su Anthos clusters on bare metal, devi impostare i seguenti parametri in Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Manutenzione
Il monitoraggio dei bollettini sulla sicurezza e l'upgrade dei cluster sono misure di sicurezza importanti da eseguire una volta che i cluster sono attivi e in esecuzione.
Monitorare i bollettini sulla sicurezza
Il team per la sicurezza di Anthos 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 di Google Cloud e dalle note di rilascio di Anthos clusters on bare metal. Utilizza questo feed XML per iscriverti ai bollettini sulla sicurezza per Anthos clusters on bare metal e i prodotti correlati:
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
Quando è necessario un intervento del cliente per affrontare 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 ulteriori informazioni su come Google gestisce le vulnerabilità e le patch di sicurezza per GKE e Anthos, consulta Applicazione di patch di sicurezza.
Esegui l'upgrade dei cluster
Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce patch di sicurezza. I cluster Anthos su release bare metal incorporano miglioramenti della sicurezza di Kubernetes che risolvono le vulnerabilità di sicurezza che possono influire sui tuoi cluster.
È tua responsabilità mantenere aggiornati i cluster Anthos. Per ogni release, leggi le note di rilascio. Per ridurre al minimo i rischi per la sicurezza dei tuoi cluster Anthos, pianifica di eseguire l'aggiornamento a nuove release delle patch ogni mese e a 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 quel 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, consulta la pagina relativa all'upgrade dei cluster.