Utilizzo della libreria dei modelli di vincolo

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

Policy Controller consente di applicare i criteri per un cluster Kubernetes definendo uno o più oggetti vincolo. Una volta installato un vincolo, le richieste al server API vengono verificate rispetto al vincolo e vengono rifiutate se non sono conformi. Le risorse preesistenti non conformi 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 provenire da Google e terze parti oppure puoi scriverne di nuovi. Per scoprire di più sulla creazione di nuovi modelli, consulta Scrivere un modello di vincolo.

Prima di iniziare

Esamina la libreria dei modelli di vincolo

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

Per elencare i vincoli, utilizza il comando seguente:

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

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

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Puoi anche visualizzare tutti i modelli di vincoli nella libreria.

Definisci un vincolo

Puoi definire un vincolo utilizzando YAML e non è necessario comprendere o scrivere Rego. Piuttosto, un vincolo richiama un modello di vincolo e lo fornisce a parametri specifici.

Se utilizzi un repository strutturato, ti consigliamo di creare i vincoli nella directory cluster/.

I vincoli hanno i seguenti campi:

  • kind minuscolo corrisponde al nome di un modello di vincolo.
  • metadata.name è il nome del vincolo.
  • Il campo match definisce gli oggetti a cui si applica il vincolo. Tutte le condizioni specificate devono essere soddisfatte prima che un oggetto rientri nell'ambito di un vincolo. Le condizioni match sono definite dai seguenti campi secondari:
    • kinds sono i tipi di risorse a cui si applica il vincolo, determinato da due campi: apiGroups è un elenco di gruppi di API Kubernetes che troveranno una corrispondenza e kinds è un elenco di tipi che corrisponderanno. "*" corrisponde a tutto. Se almeno una voce apiGroup e una voce kind corrispondono, la condizione kinds è soddisfatta.
    • scope accetta *, Cluster oNamepaced, che determina se sono selezionate le risorse con ambito cluster e/o con spazio dei nomi (il valore predefinito è *).
    • namespaces è un elenco di nomi dello spazio 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 fossero di per sé
    • 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 sullo 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 fossero di per sé.
  • Il campo parameters definisce gli argomenti per il vincolo, in base a ciò che il modello del vincolo prevede.

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

# 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

Controlla un vincolo

Se il vincolo è configurato e installato correttamente, il campo status.byPod[].enforced viene impostato su true, se il vincolo è configurato per l'applicazione o il test del vincolo.

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

Per scoprire di più sul controllo, consulta Utilizzo dei vincoli.

Avvertenze per la sincronizzazione dei vincoli

Tieni presente le seguenti avvertenze durante la sincronizzazione dei vincoli.

Coerenza finale

Puoi eseguire il commit dei vincoli nel repository Git e limitarne gli effetti utilizzando ClusterSelector o NamespaceSelectors. Poiché la sincronizzazione è eventualmente coerente, tieni presente i seguenti aspetti:

  • Se un'operazione di cluster attiva un vincolo il cui NamespaceSelector si riferisce a uno spazio dei nomi che non è stato sincronizzato, il vincolo viene applicato e l'operazione viene impedita. In altre parole, lo spazio dei nomi mancante "non è riuscito".
  • Se modifichi le etichette di uno spazio dei nomi, la cache potrebbe contenere dati obsoleti per un breve periodo di tempo.

Riduci al minimo la necessità di rinominare uno spazio dei nomi o di modificare le relative etichette e testare i vincoli che influiscono su uno spazio dei nomi rinominato o rietichettato per garantire che funzionino come previsto.

Configura Policy Controller per i vincoli referenziali

Prima di poter abilitare i vincoli referenziali, devi creare una configurazione che indichi a Policy Controller i tipi di oggetti da tenere d'occhio, ad esempio gli spazi dei nomi.

Salva il seguente manifest YAML in un file e applicalo con kubectl. Il manifest configura il controller di criteri per osservare gli spazi dei nomi e le risorse Ingress. Crea una voce con group, version e kind in spec.sync.syncOnly, con i valori per ogni tipo di oggetto da guardare.

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"

Abilita vincoli referenziali

Un vincolo di riferimento fa riferimento a un altro oggetto nella sua definizione. Ad esempio, potresti creare un vincolo che richiede che gli oggetti Ingress in un cluster abbiano nomi host univoci. Il vincolo è referenziale se il suo modello contiene la stringa data.inventory nel suo Rego.

In Policy Controller, i vincoli referenziali sono disabilitati per impostazione predefinita. Garantiamo che i vincoli referenziali siano solo coerenti alla fine e questo crea rischi:

  • Su un server API sovraccaricato, i contenuti della cache di Policy Controller potrebbero diventare inattivi, causando il vincolo di un errore di riferimento "fail open", ovvero l'azione di applicazione sembra funzionare quando non lo è. Ad esempio, puoi creare risorse Ingress 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.

Se sei consapevole di questi rischi e vuoi comunque abilitare il supporto per i vincoli referenziali, puoi attivare i vincoli referenziali nella console Google Cloud. Per scoprire di più, consulta Installare Policy Controller.

Puoi anche impostare policyController.referentialRulesEnabled su true nel file config-management.yaml:

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

Elenca tutti i vincoli

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

kubectl get constraint

Puoi anche visualizzare una panoramica dei vincoli applicati nella console Google Cloud. Per ulteriori informazioni, consulta le metriche di Policy Controller.

Rimuovi 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 un vincolo, specifica kind e name:

kubectl delete CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Se vuoi eliminare il modello di vincolo in uso, prendi nota della kind.

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

Rimuovi tutti i modelli di vincoli

Imposta spec.policyController.templateLibraryInstalled su false. Questo impedisce ad Anthos Config Management di reinstallare automaticamente la libreria.

Per rimuovere tutti i modelli e tutti i vincoli, utilizza il comando seguente:

kubectl delete constrainttemplate --all

Ripristina la libreria dei modelli di vincolo

Se hai disabilitato la libreria dei modelli di vincoli o hai disinstallato tutti i modelli di vincoli, puoi ripristinarli impostando spec.policyController.templateLibraryInstalled su true nella configurazione di Anthos Config Management.

Passaggi successivi