Applica criteri di sicurezza predefiniti a livello di pod utilizzando PodSecurity

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. L'applicazione dei controlli di sicurezza ai pod può aiutarti a soddisfare i requisiti di sicurezza e conformità. In questa pagina scopri di più su PodSecurity e su come applicarlo ai pod.

Questa pagina è rivolta agli specialisti della sicurezza che vogliono applicare controlli di sicurezza ai propri cluster GKE. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Cloud de Confiance by S3NS contenuti, consulta Ruoli e attività utente GKE comuni.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Informazioni su PodSecurity

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 coprono le esigenze di alto livello della sicurezza dei pod in Kubernetes. Questi criteri variano da altamente permissivi ad altamente restrittivi.

Puoi applicare i seguenti standard di sicurezza dei pod ai tuoi cluster GKE:

  • Privileged: un criterio senza restrizioni che fornisce il livello di autorizzazioni più ampio. Consente le escalation dei privilegi note.
  • Baseline: un criterio minimamente restrittivo che consente la configurazione predefinita, minimamente specificata dei pod. Impedisce le escalation dei privilegi note.
  • Restricted: un criterio altamente restrittivo che segue le best practice di hardening 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 dei pod. Viene aggiunto un evento di controllo all'audit log.
  • Audit: le violazioni dei criteri attivano l'aggiunta di un evento di controllo all'audit log. La creazione dei pod è consentita.
  • Avviso: le violazioni dei criteri attivano un avviso rivolto all'utente. La creazione dei 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 invece.

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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti

Il controller di ammissione PodSecurity è disponibile e abilitato per impostazione predefinita sui cluster che eseguono le seguenti versioni GKE:

  • Versione 1.25 o successive: stabile
  • Versione 1.23 e versione 1.24: beta

Per verificare se una versione GKE è disponibile ed è la versione predefinita per il tuo canale di rilascio, consulta la programma delle pubblicazioni.

Applica gli standard di sicurezza dei pod utilizzando PodSecurity

Per utilizzare il controller di ammissione PodSecurity, devi applicare standard di sicurezza Pod specifici in modalità specifiche a spazi dei nomi specifici. Puoi farlo utilizzando le etichette dello spazio dei nomi. In questo esercizio:

  • Crea due nuovi spazi dei nomi
  • Applica i criteri di sicurezza a ogni spazio dei nomi
  • Testa i criteri configurati

Nelle seguenti versioni GKE, GKE ignora i criteri che applichi allo spazio dei nomi kube-system:

  • 1.23.6-gke.1900 e versioni successive
  • 1.24.0-gke.1200 e versioni successive

Nelle versioni GKE precedenti, evita di applicare i 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 i carichi di lavoro permissivi
  • restricted-ns: per i carichi di lavoro con restrizioni elevate

Utilizza le etichette per applicare i criteri di sicurezza

Applica i seguenti standard di sicurezza dei pod:

  • baseline: applica a baseline-ns in modalità warn
  • restricted: applica a restricted-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 criterio baseline sono consentiti e il client visualizza un messaggio di avviso.
  • I carichi di lavoro nello spazio dei nomi restricted-ns che violano il restricted criterio 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, distribuisci un carico di lavoro che violi i criteri restricted e baseline per entrambi gli spazi dei nomi. Il manifest di esempio seguente esegue il deployment di un container nginx che consente l'escalation dei privilegi.

  1. Salva il seguente manifest come psa-workload.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true

  2. 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 al pod di eseguire il deployment nello spazio dei nomi

  3. Verifica che il deployment del pod sia andato a buon fine:

    kubectl get pods --namespace=baseline-ns -l=app=nginx

  4. 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 ed enforce sono registrate negli audit log per il cluster. Puoi visualizzare questi log utilizzando Esplora log nella Cloud de Confiance console.

  1. Vai alla pagina Esplora log nella Cloud de Confiance console.

    Vai a Esplora log

  2. Nel campo Query, specifica quanto segue per recuperare gli audit log in modalità audit ed enforce:

    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")

  3. Fai clic su Esegui query.

  4. Nella sezione Risultati delle query, espandi la voce di log Forbidden per esaminare i log di rifiuto in 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"
}

  5. Espandi la voce di log audit-violations per esaminare i log in 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"
}

Libera spazio

Per evitare che al tuo Cloud de Confiance by S3NS account 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 di Kubernetes 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