Utilizzo della libreria dei modelli di vincolo

Questa pagina mostra come definire i vincoli di Policy Controller utilizzando i modelli di vincolo preesistenti forniti da Google.

Questa pagina è rivolta ad amministratori IT e operatori che vogliono assicurarsi che tutte le risorse in esecuzione all'interno della piattaforma cloud soddisfino i requisiti di conformità dell'organizzazione fornendo e mantenendo l'automazione per eseguire controlli o applicare le norme e utilizzando i modelli di configurazione dichiarativa. 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.

Policy Controller ti consente di applicare i criteri per un cluster Kubernetes definendo uno o più oggetti vincolo. Dopo l'installazione di una limitazione, le richieste al server API vengono controllate in base alla limitazione e rifiutate se non sono conformi. Le risorse non conformi esistenti vengono segnalate al momento del controllo.

Ogni vincolo è supportato da un modello di vincolo che definisce lo schema e la logica del vincolo. I modelli di vincolo possono essere ricavati da Google e da terze parti oppure puoi crearne uno tuo. Per saperne di più sulla creazione di nuovi modelli, consulta Scrivere un modello di vincolo.

Prima di iniziare

• Installa Policy Controller.

Esaminare la libreria dei modelli di vincolo

Quando definisci un vincolo, specifichi il modello di vincolo che estende. Per impostazione predefinita è installata una libreria di modelli di vincoli comuni sviluppati da Google e molte organizzazioni non devono creare modelli di vincoli personalizzati direttamente in Rego. I modelli di vincolo forniti da Google hanno l'etichetta configmanagement.gke.io/configmanagement.

Per elencare le limitazioni, utilizza il seguente comando:

kubectl get constrainttemplates \
    -l="configmanagement.gke.io/configmanagement=config-management"

Per descrivere un modello di vincolo e controllare i relativi parametri obbligatori, utilizza il seguente comando:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Puoi anche visualizzare tutti i modelli di vincolo nella raccolta.

Definire un vincolo

Definisci una limitazione utilizzando YAML e non devi comprendere o scrivere Rego. Un vincolo, invece, richiama un modello di vincolo e fornisce parametri specifici per il vincolo.

Se utilizzi Config Sync con un repository gerarchico, ti consigliamo di creare i vincoli nella directory cluster/.

I vincoli hanno i seguenti campi:

• kind in minuscolo corrisponde al nome di un modello di vincolo.
• metadata.name è il nome della limitazione.
• Il campo match definisce a quali oggetti si applica la limitazione. Tutte le condizioni specificate devono essere soddisfatte prima che un oggetto rientri nell'ambito di una limitazione. Le condizioni match sono definite dai seguenti campi secondari:
  • kinds sono i tipi di risorse a cui si applica la limitazione, determinati da due campi: apiGroups è un elenco di gruppi di API Kubernetes corrispondenti e kinds è un elenco di tipi corrispondenti. "*" corrisponde a tutto. Se almeno una voce apiGroup e una kind corrispondono, la condizione kinds è soddisfatta.
  • scope accetta *, Cluster o Namespaced, che determina se sono selezionate risorse con ambito cluster o con ambito nello spazio dei nomi (il valore predefinito è *).
  • namespaces è un elenco di nomi di spazi dei nomi a cui può appartenere l'oggetto. L'oggetto deve appartenere ad almeno uno di questi spazi dei nomi. Le risorse dello spazio dei nomi vengono trattate come se appartenessero a se stesse.
  • excludedNamespaces è un elenco di spazi dei nomi a cui l'oggetto non può appartenere.
  • labelSelector è un selettore di etichette Kubernetes che l'oggetto deve soddisfare.
  • namespaceSelector è un selettore di etichette nello spazio dei nomi a cui appartiene l'oggetto. Se lo spazio dei nomi non soddisfa l'oggetto, non corrisponderà. Le risorse dello spazio dei nomi vengono trattate come se appartenessero a se stesse.
• Il campo parameters definisce gli argomenti per il vincolo, in base a quanto previsto dal modello di vincolo.

Il seguente vincolo, denominato ns-must-have-geo, richiama un modello di vincolo chiamato K8sRequiredLabels, incluso nella libreria di modelli di vincolo fornita da Google. Il vincolo definisce i parametri utilizzati dal modello di vincolo per valutare se gli spazi dei nomi hanno l'etichetta geo impostata su un valore.

# ns-must-have-geo.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-geo
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "geo"

Per creare il vincolo, utilizza kubectl apply -f:

kubectl apply -f ns-must-have-geo.yaml

Controllare un vincolo

Se il vincolo è configurato e installato correttamente, il suo status.byPod[].enforced campo è impostato su true, indipendentemente dal fatto che il vincolo sia configurato per l'applicazione o solo per il test.

I vincoli vengono applicati per impostazione predefinita e una violazione di un vincolo impedisce una determinata operazione del cluster. Puoi impostare spec.enforcementAction di una limitazione su dryrun per segnalare le violazioni nel campo status.violations senza impedire l'operazione.

Per scoprire di più sul controllo, consulta Controlla con vincoli.

Limitazioni della sincronizzazione

Se sincronizzi i vincoli con un'origine centralizzata, come un repository Git, con Config Sync o un altro strumento di tipo GitOps, tieni presente i seguenti accorgimenti quando sincronizzi i vincoli.

Coerenza finale

Puoi eseguire il commit dei vincoli in una fonte attendibile come un repository Git e limitarne gli effetti utilizzando ClusterSelectors o NamespaceSelectors. Poiché la sincronizzazione è eventualmente coerente, tieni presente i seguenti accorgimenti:

• Se un'operazione del cluster attiva una limitazione il cui NamespaceSelector fa riferimento a un ambito che non è stato sincronizzato, la limitazione viene applicata e l'operazione viene impedita. In altre parole, uno spazio dei nomi mancante "non viene chiuso".
• Se modifichi le etichette di uno spazio dei nomi, la cache potrebbe contenere dati obsoleti per breve tempo.

Riduci al minimo la necessità di rinominare uno spazio dei nomi o modificarne le etichette e testa le limitazioni che influiscono su uno spazio dei nomi rinominato o con etichette diverse per assicurarti che funzionino come previsto.

Configura Policy Controller per i vincoli di referenza

Prima di poter attivare i vincoli di riferimento, devi creare una configurazione che indichi a Policy Controller quali tipi di oggetti monitorare, ad esempio i namespace.

Salva il seguente manifest YAML in un file e applicalo con kubectl. Il manifest configura Policy Controller per monitorare gli spazi dei nomi e gli ingressi. Crea una voce con group, version e kind in spec.sync.syncOnly, con i valori per ogni tipo di oggetto che vuoi monitorare.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "extensions"
        version: "v1beta1"
        kind: "Ingress"

Attiva i vincoli referenziali

Un vincolo referenziale fa riferimento a un altro oggetto nella sua definizione. Ad esempio, puoi creare un vincolo che richieda agli oggetti Ingress in un cluster di avere nomi host univoci. Il vincolo è referenziale se il relativo modello contiene la stringa data.inventory in Rego.

I vincoli di riferimento sono abilitati per impostazione predefinita se installi Policy Controller utilizzando la console Google Cloud. Se installi Policy Controller utilizzando Google Cloud CLI, puoi scegliere se attivare le limitazioni referenziali quando esegui l'installazione di Policy Controller. È garantito che i vincoli di riferimento siano eventualmente coerenti e questo crea rischi:

• Su un server API sovraccaricato, i contenuti della cache di Policy Controller possono diventare inattivi, causando un "errore aperto" per un vincolo referenziale, il che significa che l'azione di applicazione sembra funzionare, ma non è così. Ad esempio, puoi creare ingressi con nomi host duplicati troppo rapidamente per consentire al controller di ammissione di rilevare i duplicati.

• L'ordine in cui vengono installati i vincoli e l'ordine in cui viene aggiornata la cache sono entrambi casuali.

Puoi aggiornare un cluster esistente per consentire i vincoli di referenza.

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --referential-rules

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: true

Disattivare i vincoli referenziali

Quando disattivi le limitazioni referenziali, vengono rimosse dal cluster anche tutte le limitazioni che utilizzano questi modelli, nonché i modelli stessi.

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --no-referential-rules

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: false

Elenca tutti i vincoli

Per elencare tutti i vincoli installati in un cluster, utilizza il seguente comando:

kubectl get constraint

Puoi anche visualizzare una panoramica dei vincoli applicati nella console Google Cloud. Per ulteriori informazioni, consulta Metriche del controller dei criteri.

Rimuovere un vincolo

Per trovare tutti i vincoli che utilizzano un modello di vincolo, utilizza il seguente comando per elencare tutti gli oggetti con lo stesso kind del metadata.name del modello di vincolo:

kubectl get CONSTRAINT_TEMPLATE_NAME

Per rimuovere una limitazione, specifica kind e name:

kubectl delete CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Quando rimuovi un vincolo, l'applicazione del vincolo viene interrotta non appena il server API lo contrassegni come eliminato.

Rimuovi tutti i modelli di vincoli

gcloud container fleet policycontroller content templates disable \
    --memberships=MEMBERSHIP_NAME

kubectl delete constrainttemplate --all

Ripristinare la libreria dei modelli di vincolo

gcloud container fleet policycontroller content templates enable \
    --memberships=MEMBERSHIP_NAME

Per riavviare il pod dell'operatore, utilizza il seguente comando:

kubectl delete pod -n config-management-system -l k8s-app=config-management-operator

Passaggi successivi

• Scopri di più sui bundle di Policy Controller.
• Visualizza la documentazione di riferimento della libreria di modelli di vincolo.
• Scopri come creare vincoli personalizzati.
• Risolvi i problemi di Policy Controller.