Questa pagina spiega come scrivere un modello di vincolo personalizzato e utilizzarlo per estendere Policy Controller se non riesci a trovare un modello di vincolo predefinito 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ù sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta 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, per impostazione predefinita viene installata una libreria di modelli di vincoli comuni. È 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.
Modello di vincolo di esempio
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 le 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 vincoli hanno due elementi importanti:
Lo schema della limitazione che vuoi che gli utenti creino. 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. In minuscolo, il valore
di questo campo deve essere uguale a metadata.name . |
spec.crd.spec.validation.openAPIV3Schema |
Lo schema per il campo |
L'aggiunta di un prefisso al nome del modello di vincolo K8s
è una convenzione che consente di evitare collisioni con altri tipi di modelli di vincolo, ad esempio i modelli di Foresti che hanno come target le risorse. Google Cloud
Codice sorgente Rego (campo targets
)
Le sezioni seguenti forniscono ulteriori informazioni sul codice sorgente Rego.
Località
Il codice sorgente Rego è archiviato nel campo spec.targets
, dove targets
è un array di oggetti del seguente formato:
{"target": "admission.k8s.gatekeeper.sh","rego": REGO_SOURCE_CODE , "libs": LIST_OF_REGO_LIBRARIES }
target
: indica a Policy Controller il sistema in esame (in questo caso Kubernetes); è consentita una sola voce intargets
.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 il vincolo precedente:
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 da OPA (il runtime di Rego). Il valore viene ignorato.- La regola Rego invocata da Policy Controller per verificare se sono presenti violazioni si chiama
violation
. Se questa regola ha corrispondenze, si è verificata una violazione del vincolo. - La regola
violation
ha la firmaviolation[{"msg": "violation message for the user"}]
, dove il valore di"msg"
è il messaggio di violazione restituito all'utente. - I parametri forniti al vincolo vengono resi disponibili nella parola chiave
input.parameters
. request-under-test
viene memorizzato sotto la parola chiaveinput.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 sul tipo per il
|
name |
Nome della risorsa. Potrebbe essere vuoto se l'utente si basa sul server API per generare il nome in 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 è disponibile durante il controllo. |
userInfo |
Le informazioni dell'utente che effettua la richiesta; non sono disponibili durante il controllo. Ha il seguente formato:
|
object |
L'oggetto che l'utente sta tentando di modificare o creare. |
oldObject |
Lo stato originale dell'oggetto; è disponibile solo per le operazioni UPDATE. |
dryRun |
Indica se questa richiesta è stata invocata con kubectl --dry-run ;
non è disponibile durante il controllo. |
Scrivere modelli di vincoli referenziali
I modelli di vincolo di riferimento consentono all'utente di vincolare un oggetto rispetto ad altri oggetti. Un esempio potrebbe essere "non consentire la creazione di un pod prima che sia noto che esiste un Ingress corrispondente". Un altro esempio potrebbe essere "non consentire a due servizi di avere lo stesso nome host".
Policy Controller ti consente di scrivere vincoli di riferimento monitorando il
server API per un insieme di risorse fornito dall'utente. Quando una risorsa viene modificata,
Policy Controller la memorizza nella cache locale in modo che possa essere facilmente richiamata dal codice sorgente Rego. Policy Controller rende disponibile questa cache sotto la parola chiave data.inventory
.
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 trovarsi in
data.inventory.cluster["v1"]["Node"]["my-favorite-node"]
Le risorse con ambito a livello 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 utilizzati come riferimento nel codice sorgente Rego.
Ulteriori informazioni su Rego
Le informazioni precedenti forniscono le funzionalità uniche di Policy Controller che facilitano la scrittura di vincoli sulle risorse Kubernetes in Rego. Un tutorial completo su come scrivere in Rego non rientra nell'ambito di questa guida. Tuttavia, la documentazione di Open Policy Agent contiene informazioni sulla sintassi e sulle funzionalità 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 i vincoli come descritto in Creare vincoli.
Rimuovere un modello di vincolo
Per rimuovere un modello di vincolo:
Verifica che nessun vincolo che vuoi conservare utilizzi il modello di vincolo:
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.shRimuovi il modello di vincolo:
kubectl delete constrainttemplate
CONSTRAINT_TEMPLATE_NAME
Quando rimuovi un modello di vincolo, non puoi più creare vincoli che fanno riferimento al modello.
Passaggi successivi
- Scopri di più su Policy Controller.
- Visualizza la documentazione di riferimento della libreria di modelli di vincolo.
- Scopri come utilizzare i vincoli anziché PodSecurityPolicies.