Scrivere un modello di vincolo personalizzato

Questa pagina mostra come scrivere un modello di vincolo personalizzato e utilizzarlo per estendere Policy Controller se non riesci a trovare un modello di vincolo precompilato più adatto alle tue esigenze.

Questa pagina è rivolta agli amministratori IT e agli 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ù su i ruoli comuni e le attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, vedi Ruoli e attività utente comuni di GKE Enterprise.

I criteri di Policy Controller sono descritti utilizzando il OPA Constraint Framework e sono scritti in Rego. Un criterio può valutare qualsiasi campo di un oggetto Kubernetes.

La scrittura di criteri utilizzando Rego è una competenza specializzata. Per questo motivo, libreria di modelli di vincoli comuni è sono già installati per impostazione predefinita. È probabile che tu possa richiamare questi modelli di vincoli quando crei i vincoli. Se hai esigenze specifiche, puoi creare i tuoi modelli di vincoli.

I modelli di vincoli ti consentono di separare la logica di un criterio dai suoi requisiti specifici, per il riutilizzo e la delega. Puoi creare vincoli utilizzando modelli di vincoli sviluppati da terze parti, come progetti open source, fornitori di software o esperti di normative.

Prima di iniziare

• Installa Policy Controller.

Esempio di modello di vincolo

Di seguito è riportato un esempio di modello di vincolo che nega tutte le risorse il cui nome corrisponde a un valore fornito dall'autore del vincolo. Il resto di questa pagina discute i contenuti del modello, evidenziando concetti importanti.

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

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sdenyname
spec:
  crd:
    spec:
      names:
        kind: K8sDenyName
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            invalidName:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdenynames
        violation[{"msg": msg}] {
          input.review.object.metadata.name == input.parameters.invalidName
          msg := sprintf("The name %v is not allowed", [input.parameters.invalidName])
        }

Vincolo di esempio

Di seguito è riportato un esempio di vincolo che potresti implementare per negare tutte risorse denominate policy-violation:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDenyName
metadata:
  name: no-policy-violation
spec:
  parameters:
    invalidName: "policy-violation"

Parti di un modello di vincolo

I modelli di vincolo sono costituiti da due parti importanti:

• Lo schema del vincolo che vuoi che venga creato dagli utenti. Lo schema di un modello di vincolo è memorizzato nel campo crd.

• Il codice sorgente Rego che viene eseguito quando viene valutato il vincolo. Il codice sorgente Rego di un modello è memorizzato nel campo targets.

Schema (campo crd)

Il campo CRD è un modello per la creazione della definizione di risorsa personalizzata Kubernetes che definisce la risorsa vincolo per il server API Kubernetes. Devi solo compilare i seguenti campi.

Campo	Descrizione
spec.crd.spec.names.kind	Il tipo di vincolo. Se è minuscolo, il valore di questo campo deve essere uguale a metadata.name.
spec.crd.spec.validation.openAPIV3Schema	Lo schema per il campo spec.parameters della risorsa vincolo (Policy Controller definisce automaticamente il resto dello schema del vincolo). Segue le stesse convenzioni di una normale risorsa CRD.

L'aggiunta del nome K8s al modello di vincolo è una convenzione che consente di evitare collisioni con altri tipi di modelli di vincoli, come Modelli Forseti che hanno come target risorse Google Cloud.

Codice sorgente Rego (campo targets)

Le sezioni seguenti forniscono ulteriori informazioni sull'origine di Rego le API nel tuo codice.

Località

Il codice sorgente di Rego viene archiviato nel campo spec.targets, dove targets è un array di oggetti nel seguente formato:

{"target": "admission.k8s.gatekeeper.sh","rego": REGO_SOURCE_CODE, "libs": LIST_OF_REGO_LIBRARIES}

• target: indica a Policy Controller quale sistema stiamo esaminando (in questo case Kubernetes); è consentita una sola voce in targets.
• rego: il codice sorgente della limitazione.
• libs: un elenco facoltativo di librerie di codice Rego messe a disposizione del modello di vincolo. Ha lo scopo di semplificare l'utilizzo delle librerie condivise ed è fuori dall'ambito di questo documento.

Codice sorgente

Di seguito è riportato il codice sorgente Rego per la precedente limitazione:

package k8sdenynames

violation[{"msg": msg}] {
   input.review.object.metadata.name == input.parameters.invalidName
   msg := sprintf("The name %v is not allowed", [input.parameters.invalidName])
}

Tieni presente quanto segue:

• package k8sdenynames è richiesto dall'OPA (runtime di Rego). Il valore è ignorato.
• La regola di recupero che Policy Controller richiama per verificare se sono presenti violazioni sono chiamate violation. Se questa regola ha corrispondenze, si è verificata una violazione del vincolo.
• La regola violation ha la firma violation[{"msg": "violation message for the user"}], dove il valore "msg" è il messaggio di violazione che viene restituito all'utente.
• I parametri forniti al vincolo vengono resi disponibili all'interno della parola chiave input.parameters.
• request-under-test viene memorizzato nella parola chiave input.review.

La parola chiave input.review ha i seguenti campi.

Campo	Descrizione
uid	L'ID univoco per questa richiesta specifica; non è disponibile durante il controllo.
kind	Le informazioni su Kind per object-under-test. Ha il seguente formato: kind: il tipo di risorsa group: gruppo di risorse version: la versione della risorsa
name	Nome della risorsa. Potrebbe essere vuoto se l'utente si basa su API server per generare il nome su una richiesta CREATE.
namespace	Lo spazio dei nomi della risorsa (non fornito per le risorse con ambito cluster).
operation	L'operazione richiesta (ad esempio CREATE o UPDATE); non è disponibili durante il controllo.
userInfo	Le informazioni dell'utente che effettua la richiesta; non sono disponibili durante il controllo. Ha il seguente formato: username: l'utente che effettua la richiesta uid: l'UID dell'utente groups: un elenco di gruppi di cui l'utente è membro extra: eventuali informazioni utente aggiuntive fornite da Kubernetes
object	L'oggetto che l'utente sta tentando di modificare o creare.
oldObject	Lo stato originale dell'oggetto; è disponibile solo su UPDATE operazioni aziendali.
dryRun	Se questa richiesta è stata richiamata con kubectl --dry-run; non sono disponibili durante il controllo.

Scrivere modelli di vincoli referenziali

Nota: se non hai attivato le limitazioni referenziali quando hai installato Policy Controller, devi prima attivarle. Inoltre, tieni presente il preciso sulla coerenza finale e le sue implicazioni per l'applicazione delle norme fornite nell'ambito delle istruzioni su come attivare questa funzionalità. Inoltre, tieni presente che per le query dei vincoli sul funzionamento, la sincronizzazione degli oggetti deve essere abilitata per le risorse a cui si fa riferimento.

I modelli di vincoli referenziali sono modelli che consentono all'utente di applicare vincoli di un oggetto rispetto ad altri. Un esempio potrebbe essere "Non consentire la creazione di un pod prima che esista un Ingress corrispondente". Un altro esempio potrebbe essere "non consentire a due servizi di avere lo stesso nome host".

Policy Controller consente di scrivere vincoli referenziali esaminando il Server API per un insieme di risorse fornite dall'utente. Quando una risorsa viene modificata, Policy Controller lo memorizza localmente in modo che possa essere facilmente referenziato da Rego codice sorgente. Policy Controller rende disponibile questa cache nel data.inventory parola chiave.

Le risorse con ambito cluster vengono memorizzate nella cache nella seguente posizione:

data.inventory.cluster["GROUP_VERSION"]["KIND"]["NAME"]

Ad esempio, un nodo denominato my-favorite-node potrebbe essere trovato in

data.inventory.cluster["v1"]["Node"]["my-favorite-node"]

Le risorse con ambito di spazio dei nomi vengono memorizzate nella cache qui:

data.inventory.namespace["NAMESPACE"]["GROUP_VERSION"]["KIND"]["NAME"]

Ad esempio, un ConfigMap denominato production-variables nello spazio dei nomi shipping-prod potrebbe essere trovato in

data.inventory.namespace["shipping-prod"]["v1"]["ConfigMap"]["production-variables"]

I contenuti completi dell'oggetto vengono archiviati in questa posizione della cache e possono essere richiamati nel codice sorgente Rego come preferisci.

Ulteriori informazioni su Rego

Le informazioni riportate sopra forniscono le funzionalità univoche di Policy Controller che semplifica la scrittura di vincoli sulle risorse Kubernetes in Rego. Un il tutorial su come scrivere in Rego non rientra nell'ambito di questa guida. Tuttavia, Apri la documentazione di Policy Agent contiene informazioni sulla sintassi e sulle caratteristiche del linguaggio Rego stesso.

Installa il modello di vincolo

Dopo aver creato il modello di vincolo, utilizza kubectl apply per applicarlo e Controller criteri si occupa di importarlo. Assicurati di controllare il campo status del modello di vincolo per assicurarti che non siano stati rilevati errori durante l'inizializzazione. Al termine dell'importazione, il campo status dovrebbe mostrare created: true e il valore observedGeneration indicato nel campo status dovrebbe essere uguale al campo metadata.generation.

Dopo aver importato il modello, puoi applicare vincoli come descritto in Creazione di vincoli.

Rimuovere un modello di vincolo

Attenzione: quando rimuovi un modello di vincolo utilizzato da vincoli, Policy Controller rimuove i vincoli che dipendono da quel modello.

Per rimuovere un modello di vincolo:

1. Verifica che nessun vincolo da conservare utilizzi il vincolo modello:

   kubectl get TEMPLATE_NAME
   

   Se esiste un conflitto di nomi tra il nome del modello di vincolo e un altro oggetto nel cluster, utilizza invece il seguente comando:

   kubectl get TEMPLATE_NAME.constraints.gatekeeper.sh
   

2. Rimuovi il modello di vincolo:

   kubectl delete constrainttemplate CONSTRAINT_TEMPLATE_NAME
   

Se rimuovi un modello di vincolo, non puoi più creare vincoli che vi fanno riferimento.

Passaggi successivi

• Scopri di più su Policy Controller.
• Visualizza la documentazione di riferimento della libreria di modelli di vincolo.
• Scopri come utilizzare i vincoli invece di PodSecurityPolicies.