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 macchine host eseguono RHEL e vuoi per abilitare SELinux per il tuo cluster, devi abilitare SELinux in tutto il tuo host machine learning. Scopri come proteggere i container con SELinux per maggiori dettagli.
Utilizza seccomp
per limitare i container
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. 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 runtime del container,
profilo seccomp
predefinito. Anche i container e i carichi di lavoro che non specificano
Il profilo seccomp
nei file di configurazione è soggetto 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 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. Puoi invece scegliere determinati carichi di lavoro da eseguire
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 contenitori 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
sulla macchina host. È quindi consigliabile eseguire tutti i
come utente non root.
Le sezioni seguenti descrivono due modi per eseguire i container come server non root utente.
Metodo 1: aggiungi l'istruzione USER
in Dockerfile
Questo metodo utilizza un Dockerfile
per garantire che i container non vengano eseguiti come root
utente. In un Dockerfile
, puoi specificare per quale utente viene eseguita la procedura all'interno di un contenitore
deve essere eseguito. 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 con nome 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 dell'immagine i comandi vengono eseguiti
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
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 questi
processi 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. La
startUIDRangeRootlessContainers
è un campo facoltativo che, se non specificato,
ha un valore di 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 dell'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 UID e GID
gli spazi utilizzati dai contenitori di sistema non si sovrappongono a quelli assegnati all'utente
carichi di lavoro con scale out impegnativi.
Come disattivare la modalità rootless
A partire dalla release 1.10 di Google Distributed Cloud, piano di controllo Kubernetes
i container e quelli 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 gli UID e gli
I GID sono già stati allocati ai processi in esecuzione nell'ambiente.
A partire dalla release 1.11 di Google Distributed Cloud, puoi disabilitare il rootless quando esegui l'upgrade del cluster. Quando la modalità rootless è disabilitata, Kubernetes i container del piano di controllo e quelli di sistema vengono eseguiti come utente root.
Per disattivare la modalità rootless, 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 possibilità di automodifica dei carichi di lavoro
Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione si automodifica. Ad esempio, alcuni carichi di lavoro si adeguano automaticamente verticalmente. 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 in primo luogo. 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
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 la porta per impostazione predefinita
10255
, la porta di sola lettura kubelet. Qualsiasi carico di lavoro del cliente configurato
i dati di lettura da questa porta kubelet non sicura 10255
devono essere migrati per utilizzare la porta
porta kubelet 10250.
Questa porta è disabilitata solo nei cluster creati con versione 1.15.0 o successiva
predefinito. 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é il kubelet trapela informazioni di bassa sensibilità
porta 10255
, che non è autenticata. Le informazioni includono
informazioni sulla configurazione per tutti i pod in esecuzione su un nodo. Potrebbe essere utile
a un aggressore. Espone anche metriche e informazioni sullo stato, che possono
forniscono informazioni 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 aspetti di sicurezza importanti da adottare quando i cluster sono pronti e in esecuzione.
Monitorare i bollettini sulla sicurezza
Il team di sicurezza di GKE pubblica bollettini sulla sicurezza per le vulnerabilità con gravità alta 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.
Quando è necessario un intervento del cliente per far fronte a questi aspetti critici e vulnerabilità, Google contatta i clienti via email. Inoltre, Google potrebbe contatta anche i clienti con contratti di assistenza tramite i canali di assistenza.
Per ulteriori informazioni su come Google gestisce le vulnerabilità e per GKE e GKE Enterprise, consulta Applicazione delle patch di sicurezza.
Esegui l'upgrade dei cluster
Kubernetes introduce regolarmente nuove funzionalità di sicurezza e fornisce sicurezza patch. 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 per i tuoi cluster, pianifica un aggiornamento a una nuova patch ogni mese e le versioni secondarie 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
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.
Utilizza 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 scoprire di più su Cloud Interconnect, vedi Provisioning di Dedicated Interconnect Panoramica.
Cloud VPN connette in sicurezza la rete peer alla tua una rete Virtual Private Cloud (VPC) attraverso IPsec VPN connessione. Per saperne di più su Cloud VPN, consulta Panoramica di Cloud VPN.
Controlli di servizio VPC funziona con Cloud Interconnect o Cloud VPN per fornire ulteriore sicurezza per i tuoi cluster. Controlli di servizio VPC consente per ridurre 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 un VIP con limitazioni e aggiungere le API seguenti 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, utilizza --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.