Questa pagina mostra come applicare i controlli di sicurezza predefiniti a livello di pod nei cluster Google Kubernetes Engine (GKE) utilizzando il controller di ammissione PodSecurity
.
Per ulteriori informazioni su come funziona PodSecurity
, consulta
Pod Security Admission.
Panoramica
PodSecurity
è un controller di ammissione Kubernetes che ti consente di applicare gli
standard di sicurezza dei pod
ai pod in esecuzione sui tuoi cluster GKE. Gli standard di sicurezza dei pod sono criteri di sicurezza predefiniti che soddisfano le esigenze di alto livello relative alla sicurezza dei pod in Kubernetes. Questi criteri possono essere molto permissivi o molto restrittivi.
Puoi applicare i seguenti standard di sicurezza dei pod ai tuoi cluster GKE:
- Con privilegi: un criterio senza restrizioni che fornisce il massimo livello di autorizzazioni. Consente di riassegnare i privilegi noti.
- Base di riferimento: una norma minimamente restrittiva che consente la configurazione del pod predefinita e minimamente specificata. Impedisce le riassegnazioni note dei privilegi.
- Limitata: un criterio altamente restrittivo che segue le best practice di protezione dei pod.
Puoi utilizzare il controller di ammissione PodSecurity
per applicare gli standard di sicurezza dei pod nelle seguenti modalità:
- Applica: le violazioni dei criteri rifiutano la creazione di pod. Viene aggiunto un evento di controllo all'audit log.
- Controllo: le violazioni dei criteri attivano l'aggiunta di un evento di controllo al log di controllo. La creazione di pod è consentita.
- Avviso: le violazioni delle norme attivano un avviso rivolto agli utenti. la creazione di pod è consentita.
Il controller di ammissione PodSecurity
incorpora questi criteri nell'API Kubernetes.
Se vuoi creare e applicare criteri di sicurezza personalizzati a livello di pod, valuta la possibilità di utilizzare il controller di ammissione Gatekeeper.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
- Assicurati di avere un cluster GKE Autopilot o Standard in esecuzione 1.23 o versioni successive.
- Per i cluster Autopilot, registrati in un canale di rilascio in cui la versione predefinita è 1.23 o successive.
- Per i cluster Standard, registrati in un canale di rilascio o esegui l'upgrade del cluster a una versione specifica.
Requisiti
Il controller di ammissione PodSecurity
è disponibile e abilitato per impostazione predefinita sui cluster che eseguono le seguenti versioni di GKE:
- Versione 1.25 o successive: stabile
- Versione 1.23 e versione 1.24: beta
Per verificare se una versione GKE è disponibile e corrisponde a quella predefinita per il tuo canale di rilascio, consulta la Pianificazione delle release.
Applica gli standard di sicurezza dei pod utilizzando PodSecurity
Per utilizzare il controller di ammissione PodSecurity
, devi applicare standard di sicurezza dei pod specifici in modalità specifiche a spazi dei nomi specifici. Per farlo, puoi utilizzare le etichette dello spazio dei nomi.
In questo esercizio procedi nel seguente modo:
- Crea due nuovi spazi dei nomi
- Applica criteri di sicurezza a ogni spazio dei nomi
- Testa i criteri configurati
Nelle seguenti versioni di GKE, GKE ignora i criteri
applicati allo spazio dei nomi kube-system
:
- 1.23.6-gke.1900 e versioni successive
- 1.24.0-gke.1200 e versioni successive
Nelle versioni precedenti di GKE, evita di applicare criteri in kube-system
.
Crea nuovi spazi dei nomi
Crea spazi dei nomi nel tuo cluster:
kubectl create ns baseline-ns
kubectl create ns restricted-ns
Questo comando crea i seguenti spazi dei nomi:
baseline-ns
: per carichi di lavoro permissivirestricted-ns
: per carichi di lavoro altamente limitati
Utilizza le etichette per applicare i criteri di sicurezza
Applica i seguenti standard di sicurezza dei pod:
baseline
: applica abaseline-ns
in modalitàwarn
restricted
: applica arestricted-ns
in modalitàenforce
kubectl label --overwrite ns baseline-ns pod-security.kubernetes.io/warn=baseline
kubectl label --overwrite ns restricted-ns pod-security.kubernetes.io/enforce=restricted
Questi comandi ottengono i seguenti risultati:
- I carichi di lavoro nello spazio dei nomi
baseline-ns
che violano il criteriobaseline
sono consentiti e il client visualizza un messaggio di avviso. - I carichi di lavoro nello spazio dei nomi
restricted-ns
che violano il criteriorestricted
vengono rifiutati e GKE aggiunge una voce agli audit log.
Verifica che le etichette siano state aggiunte:
kubectl get ns --show-labels
L'output è simile al seguente:
baseline-ns Active 74s kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline
restricted-ns Active 18s kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted
default Active 57m kubernetes.io/metadata.name=default
kube-public Active 57m kubernetes.io/metadata.name=kube-public
kube-system Active 57m kubernetes.io/metadata.name=kube-system
Testa i criteri configurati
Per verificare che il controller di ammissione PodSecurity
funzioni come previsto, esegui il deployment di un carico di lavoro che viola i criteri baseline
e restricted
in entrambi gli spazi dei nomi. Il seguente manifest di esempio esegue il deployment di un container nginx
che consente l'escalation dei privilegi.
Salva il seguente manifest con il nome
psa-workload.yaml
:apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx securityContext: privileged: true
Applica il manifest allo spazio dei nomi
baseline-ns
:kubectl apply -f psa-workload.yaml --namespace=baseline-ns
L'output è simile al seguente:
Warning: would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true)
Il criterio
baseline
consente il deployment del pod nello spazio dei nomi.Verifica che il deployment del pod sia andato a buon fine:
kubectl get pods --namespace=baseline-ns -l=app=nginx
Applica il manifest allo spazio dei nomi
restricted-ns
:kubectl apply -f psa-workload.yaml --namespace=restricted-ns
L'output è simile al seguente:
Error from server (Forbidden): error when creating "workload.yaml": pods "nginx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
Il pod non esegue il deployment nello spazio dei nomi. Viene aggiunta una voce di controllo nel log.
Visualizza le violazioni dei criteri negli audit log
Le violazioni dei criteri nelle modalità audit
e enforce
vengono registrate negli audit log per il cluster. Puoi visualizzare questi log utilizzando Esplora log nella console Google Cloud.
Vai alla pagina Esplora log nella console Google Cloud.
Nel campo Query, specifica quanto segue per recuperare gli audit log delle modalità
audit
eenforce
:resource.type="k8s_cluster" protoPayload.resourceName:"/pods/nginx" protoPayload.methodName="io.k8s.core.v1.pods.create" (labels."pod-security.kubernetes.io/audit-violations":"PodSecurity" OR protoPayload.response.reason="Forbidden")
Fai clic su Esegui query.
Nella sezione Risultati delle query, espandi la voce di log
Forbidden
per ispezionare i log di rifiuto della modalitàenforce
. I dettagli sono simili ai seguenti:{ ... protoPayload: { @type: "type.googleapis.com/google.cloud.audit.AuditLog" authenticationInfo: {1} authorizationInfo: [1] methodName: "io.k8s.core.v1.pods.create" request: {6} requestMetadata: {2} resourceName: "core/v1/namespaces/restricted-ns/pods/nginx" response: { @type: "core.k8s.io/v1.Status" apiVersion: "v1" code: 403 details: {2} kind: "Status" message: "pods "nginx" is forbidden: violates PodSecurity "restricted:latest": privileged (container "nginx" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")" metadata: {0} reason: "Forbidden" status: "Failure" } serviceName: "k8s.io" status: {2} } receiveTimestamp: "2022-02-01T19:19:25.353235326Z" resource: {2} timestamp: "2022-02-01T19:19:21.469360Z" }
Espandi la voce di log
audit-violations
per ispezionare i log della modalitàaudit
. I dettagli sono simili ai seguenti:{ ... labels: { ... pod-security.kubernetes.io/audit-violations: "would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true)" pod-security.kubernetes.io/enforce-policy: "privileged:latest" } operation: {4} protoPayload: {10} receiveTimestamp: "2023-12-26T05:18:04.533631468Z" resource: {2} timestamp: "2023-12-26T05:17:36.102387Z" }
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi, elimina gli spazi dei nomi:
kubectl delete ns baseline-ns
kubectl delete ns restricted-ns
Alternative a PodSecurity
Oltre a utilizzare il controller di ammissione PodSecurity
integrato per applicare gli standard di sicurezza dei pod, puoi anche utilizzare Gatekeeper, un controller di ammissione basato su Open Policy Agent (OPA), per creare e applicare controlli di sicurezza personalizzati a livello di pod.
Passaggi successivi
- Scopri di più sugli standard di sicurezza dei pod.
- Scopri di più sul controller di ammissione
PodSecurity
. - Esegui la migrazione da PodSecurityPolicy al controller di ammissione
PodSecurity
.