Questa pagina è stata tradotta dall'API Cloud Translation.

Applicare criteri di sicurezza personalizzati a livello di pod utilizzando Gatekeeper

Autopilot Standard

Questa pagina mostra come utilizzare il controller di ammissione Gatekeeper per applicare controlli di sicurezza a livello di pod ai tuoi cluster Google Kubernetes Engine (GKE). In questa pagina scoprirai come utilizzare Gatekeeper per applicare vincoli che ti consentano di applicare criteri di sicurezza per aiutarti a soddisfare i requisiti di sicurezza della tua organizzazione.

Questa pagina è rivolta agli esperti di sicurezza che vogliono applicare controlli di sicurezza ai propri cluster GKE. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

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

Panoramica

Gatekeeper è un controller di ammissione che convalida le richieste di creazione e aggiornamento dei pod su cluster Kubernetes utilizzando Open Policy Agent (OPA).

L'utilizzo di Gatekeeper consente agli amministratori di definire criteri con un vincolo, ovvero un insieme di condizioni che consentono o negano i comportamenti di deployment in Kubernetes. Puoi quindi applicare questi criteri a un cluster utilizzando un ConstraintTemplate. Questo documento fornisce esempi per limitare le funzionalità di sicurezza dei carichi di lavoro al fine di applicare, testare e controllare i criteri di sicurezza utilizzando Gatekeeper.

Gatekeeper può anche:

Implementazione dei criteri:applica i criteri in modo graduale e limitato per limitare il rischio di interruzioni dei carichi di lavoro.
Modifiche ai criteri di prova: fornisci meccanismi per testare l'impatto e l'intervallo dei criteri prima dell'applicazione.
Esegui la revisione dei criteri esistenti:assicurati l'applicazione dei controlli di sicurezza ai workload nuovi ed esistenti (controlli di revisione).

Concetti

Gatekeeper introduce due concetti per fornire agli amministratori un metodo efficace e flessibile per controllare il cluster: vincoli e modelli di vincoli, entrambi concetti ereditati dal Constraint Framework di Open Policy Agent.

I vincoli sono la rappresentazione dei criteri di sicurezza: definiscono i requisiti e l'ambito dell'applicazione. I modelli di vincoli sono istruzioni riutilizzabili (scritte in Rego) che applicano la logica per valutare campi specifici negli oggetti Kubernetes, in base ai requisiti definiti nei vincoli.

Ad esempio, potresti avere una limitazione che dichiara i profili seccomp consentiti che possono essere applicati ai pod in uno spazio dei nomi specifico e un modello di limitazione paragonabile che fornisce la logica per estrarre questi valori e gestire l'applicazione.

Il seguente modello di vincolo, del repository Gatekeeper, verifica l'esistenza di securityContext.privileged in una specifica del pod:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8spspprivilegedcontainer
spec:
  crd:
    spec:
      names:
        kind: K8sPSPPrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspprivileged

        violation[{"msg": msg, "details": {}}] {
            c := input_containers[_]
            c.securityContext.privileged
            msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
        }
        input_containers[c] {
            c := input.review.object.spec.containers[_]
        }
        input_containers[c] {
            c := input.review.object.spec.initContainers[_]
        }

Per estendere il modello di vincoli riportato sopra, il seguente vincolo definisce l'ambito (kinds) per l'applicazione specifica di questo modello di vincoli in una modalità dryrun:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Con Gatekeeper, puoi creare i tuoi vincoli e modelli di vincoli per soddisfare le tue esigenze specifiche. Puoi anche utilizzare un insieme standard di vincoli e modelli di vincoli nel repository Gatekeeper che sono stati definiti per consentire un'adozione rapida e l'applicazione della sicurezza. Ogni vincolo è inoltre accompagnato da configurazioni di pod di esempio.

Google Cloud fornisce una versione gestita e supportata ufficialmente di Gatekeeper open source denominata Policy Controller. Google non supporta ufficialmente il progetto open source Gatekeeper.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Attivare Gatekeeper su un cluster con Policy Controller

Policy Controller è un motore di criteri basato sul progetto open source Gatekeeper. Google consiglia di utilizzare Policy Controller perché include funzionalità aggiuntive per contribuire a applicare i criteri su larga scala, tra cui policy as code, supporto multi-cluster, integrazione con Cloud Logging e la possibilità di visualizzare lo stato dei criteri nella console Google Cloud. Policy Controller è disponibile con una licenza della versione Enterprise di Google Kubernetes Engine (GKE), ma puoi installare Gatekeeper sul tuo cluster.

Per attivare Policy Controller su un cluster, segui la guida all'installazione di Policy Controller.

Attivare i vincoli e i modelli di vincoli

Gatekeeper e i relativi modelli di vincoli possono essere installati e attivati senza influire negativamente sui carichi di lavoro esistenti o nuovi. Per questo motivo, è consigliabile applicare al cluster tutti i modelli di vincoli di sicurezza dei pod applicabili.

Inoltre, i vincoli di Gatekeeper possono essere implementati per applicare controlli per oggetti specifici, come spazi dei nomi e pod.

Osserva l'esempio seguente che limita l'ambito ai pod nello spazio dei nomi production definendoli nell'istruzione di corrispondenza delle limitazioni:

...
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "production"

Per ulteriori informazioni sulle opzioni disponibili per gli oggetti Constraint e ConstraintTemplate, consulta Come utilizzare Gatekeeper.

Norme relative ai test

L'introduzione di nuovi criteri nei cluster esistenti può avere un comportamento sfavorevole, ad esempio limitando i workload esistenti. Uno dei vantaggi dell'utilizzo di Gatekeeper per la sicurezza dei pod è la possibilità di verificare l'efficacia e l'impatto di un criterio senza apportare modifiche effettive, utilizzando una modalità di prova. In questo modo, la configurazione dei criteri può essere testata sui cluster in esecuzione senza applicazione. Le violazioni delle norme vengono registrate e identificate senza interferenze.

I passaggi che seguono mostrano come uno sviluppatore, un operatore o un amministratore può applicare modelli e vincoli per determinare la loro efficacia o il loro potenziale impatto:

Applica la configurazione di Gatekeeper per la replica dei dati per la funzionalità di controllo e dry run:

kubectl create -f- <<EOF
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: ""
        version: "v1"
        kind: "Pod"
EOF

Senza vincoli applicati, eseguiamo un workload con privilegi elevati:

kubectl create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

Carica il modello di vincolo k8spspprivilegedcontainer sopra indicato:

kubectl create -f- <<EOF
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8spspprivilegedcontainer
spec:
  crd:
    spec:
      names:
        kind: K8sPSPPrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspprivileged

        violation[{"msg": msg, "details": {}}] {
            c := input_containers[_]
            c.securityContext.privileged
            msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
        }
        input_containers[c] {
            c := input.review.object.spec.containers[_]
        }
        input_containers[c] {
            c := input.review.object.spec.initContainers[_]
        }
EOF

Ora creiamo un nuovo vincolo per estendere questo modello di vincolo. Questa volta imposteremo enforcementAction su dryrun:

kubectl create -f- <<EOF
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
EOF

Poiché Gatekeeper sincronizza i dati degli oggetti in esecuzione e controlla passivamente la presenza di violazioni, possiamo verificare se sono state rilevate violazioni controllando il valore status del vincolo:

kubectl get k8spspprivilegedcontainer.constraints.gatekeeper.sh/psp-privileged-container -o yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
...
 name: psp-privileged-container
...
spec:
 enforcementAction: dryrun
 match:
   kinds:
   - apiGroups:
     - ""
     kinds:
     - Pod
status:
 auditTimestamp: "2019-12-15T22:19:54Z"
 byPod:
 - enforced: true
   id: gatekeeper-controller-manager-0
 violations:
 - enforcementAction: dryrun
   kind: Pod
   message: 'Privileged container is not allowed: nginx, securityContext: {"privileged":
     true}'
   name: nginx
   namespace: default

Eseguiamo un altro pod con privilegi per verificare che il criterio non interferisca con i deployment:

kubectl create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privpod
  labels:
    app: privpod
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

Il nuovo pod verrà implementato correttamente.

Per rimuovere le risorse create in questa sezione, esegui i seguenti comandi:

kubectl delete k8spspprivilegedcontainer.constraints.gatekeeper.sh/psp-privileged-container
kubectl delete constrainttemplate k8spspprivilegedcontainer
kubectl delete pod/nginx
kubectl delete pod/privpod

Applicazione delle norme

Ora che possiamo confermare la validità e l'impatto di un criterio senza influire su workload esistenti o nuovi, implementiamo un criterio con applicazione completa.

Sulla base degli esempi utilizzati per convalidare il criterio riportato sopra, i passaggi riportati di seguito mostrano come uno sviluppatore, un operatore o un amministratore può applicare modelli di vincoli e vincoli per applicare un criterio:

Carica il modello di vincolo k8spspprivilegedcontainer menzionato in precedenza:

kubectl create -f- <<EOF
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8spspprivilegedcontainer
spec:
  crd:
    spec:
      names:
        kind: K8sPSPPrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspprivileged

        violation[{"msg": msg, "details": {}}] {
            c := input_containers[_]
            c.securityContext.privileged
            msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
        }
        input_containers[c] {
            c := input.review.object.spec.containers[_]
        }
        input_containers[c] {
            c := input.review.object.spec.initContainers[_]
        }
EOF

Ora creiamo un nuovo vincolo per estendere questo modello di vincolo. Questa volta, non imposteremo la chiave enforcementAction. Per impostazione predefinita, la chiave enforcementAction è impostata su deny:

kubectl create -f- <<EOF
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
EOF

Prova a eseguire il deployment di un contenitore che dichiara autorizzazioni con privilegi:

kubectl create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

Dovresti ricevere il seguente messaggio di errore:

Error from server ([denied by psp-privileged-container] Privileged container is not allowed:
nginx, securityContext: {"privileged": true}): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container]
Privileged container is not allowed: nginx, securityContext: {"privileged": true}

Per eseguire la pulizia, esegui i seguenti comandi:

kubectl delete k8spspprivilegedcontainer.constraints.gatekeeper.sh/psp-privileged-container
kubectl delete constrainttemplate k8spspprivilegedcontainer

Alternative a Gatekeeper

Gatekeeper ti consente di dichiarare e applicare criteri di sicurezza personalizzati a livello di pod. Puoi anche utilizzare il PodSecurity controller di ammissione integrato di Kubernetes per applicare criteri di sicurezza predefiniti a livello di pod. Questi criteri predefiniti sono in linea con i livelli definiti dagli standard di sicurezza dei pod.

Passaggi successivi

Gatekeeper fornisce un mezzo incredibilmente efficace per applicare e convalidare la sicurezza nei cluster GKE utilizzando criteri dichiarativi. Tuttavia, l'uso di Gatekeeper va oltre la sicurezza e può essere utilizzato in altri aspetti dell'amministrazione e delle operazioni.