Riferimento YAML per i criteri (original) (raw)
Questa pagina contiene informazioni di riferimento per le policy di Autorizzazione binaria specificate in formato YAML. Quando configuri una policy utilizzando l'interfaccia a riga di comando, modifica un file in formato YAML conforme a questa specifica. Per esempi di criteri in formato YAML, consulta Criteri di esempio.
I file YAML delle policy hanno il seguente formato:
name: projects/<PROJECT_ID>/policy
admissionWhitelistPatterns:
- namePattern: <MATCHING_PATTERN>
- ...
globalPolicyEvaluationMode: <GLOBAL_EVAL_MODE>
defaultAdmissionRule:
<ADMISSION_RULE>
clusterAdmissionRules:
<CLUSTER_SPECIFIER>:
<ADMISSION_RULE>
...
Nodi
Il formato YAML ha i seguenti nodi di primo livello:
| Nodo | Descrizione | Obbligatorio |
|---|---|---|
| name | Il nome del criterio. | Sì |
| admissionWhitelistPatterns | Specifica le immagini container per cui è sempre consentito il deployment. | No |
| globalPolicyEvaluationMode | Specifica se applicare una policy di sistema che esenta le immagini di sistema di proprietà di Google. | No |
| defaultAdmissionRule | La regola da utilizzare quando non si applica alcuna regola specifica. | Sì |
| clusterAdmissionRules | Specifica le regole che si applicano a cluster specifici. | No |
name
Il nodo name contiene il nome della policy nel seguente formato:
name: projects/PROJECT_ID/policy
dove PROJECT_ID è il nome del tuo progetto Google Cloudin cui è definito il criterio.
Ad esempio:
name: projects/example-project/policy
admissionWhitelistPatterns
admissionWhitelistPatterns specifica una lista consentita di immagini container che sonoesenti dall'applicazione delle policy. Specifica il percorso delle immagini in Container Registry e Artifact Registry, un altro registro o un riferimento locale nel nodo secondario namePattern:
admissionWhitelistPatterns:
- namePattern: MATCHING_PATTERN
- ...
Sostituisci MATCHING_PATTERN con un percorso a una singola immagine o un pattern corrispondente contenente uno dei simboli jolly (*, **).
Tieni presente che i caratteri jolly sono validi solo alla fine del pattern. Ad esempio,gcr.io/my-project/nginx* è un pattern valido, ma gcr.io/my-project/n*xnon lo è. Il carattere jolly * corrisponde solo alle immagini nella directory specificata. Ad esempio, gcr.io/my-project/nginx* corrisponde a gcr.io/my-project/nginx:latest, ma non a gcr.io/my-project/nginx-images/nginx. Il carattere jolly ** corrisponde alle immagini nelle sottodirectory. Ad esempio, il percorso gcr.io/my-project/nginx** corrisponde agcr.io/my-project/nginx-1.14.2/image:latest.
L'esempio seguente aggiunge i registri contenenti immagini Google Kubernetes Engine (GKE) di uso comune, un'immagine che si trova in gcr.io/example-project/helloworld e un riferimento locale a un'immagine all'elenco delle immagini esenti per il criterio:
admissionWhitelistPatterns:
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/gke-release/asm/*
- namePattern: gcr.io/stackdriver-agents/*
- namePattern: gcr.io/example-project/helloworld
- namePattern: loc-ref
Pattern della lista consentita
Per inserire nella lista consentita tutte le immagini container la cui posizione del registro corrisponde al percorso specificato:
admissionWhitelistPatterns: ...
- namePattern: gcr.io/example-project/*
Per inserire nella lista consentita un'immagine specifica:
admissionWhitelistPatterns: ...
- namePattern: gcr.io/example-project/helloworld
Per inserire nella lista consentita una versione attualmente taggata:
admissionWhitelistPatterns: ...
- namePattern: gcr.io/example-project/helloworld:latest
- namePattern: gcr.io/example-project/helloworld:my-tag
- namePattern: gcr.io/example-project/helloworld:v1.*
Per inserire nella lista consentita una versione specifica di un'immagine in base al relativo digest:
admissionWhitelistPatterns: ...
- namePattern: gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
Per inserire nella lista consentita le immagini nelle sottodirectory di un determinato percorso:
admissionWhitelistPatterns: ...
- namePattern: gcr.io/example-project/**
globalPolicyEvaluationMode
La modalità di valutazione dei criteri di sistema è un'impostazione dei criteri che fa sì che Autorizzazione binaria valuti un criterio di sistema prima di valutare il criterio che configuri. Le norme di sistema sono fornite da Google ed esentano un elenco di immagini di sistema gestite da Google da ulteriori valutazioni delle norme. Se questa impostazione è attivata, le immagini richieste da GKE non vengono bloccate dall'applicazione dei criteri. I criteri di sistema vengono valutati prima e in aggiunta alla valutazione dei criteri utente, inclusi admissionWhitelistPatterns.
Per consentire tutte le immagini di sistema gestite da Google, imposta la proprietàglobalPolicyEvaluationMode su ENABLE:
globalPolicyEvaluationMode: ENABLE
Per disattivare la modalità di valutazione delle policy di sistema:
globalPolicyEvaluationMode: DISABLE
defaultAdmissionRule
defaultAdmissionRule specifica la regola predefinitaper il criterio. La regola predefinita definisce i vincoli che si applicano a tutte le immagini container non esenti, ad eccezione di quelle che hanno una propria regola specifica del cluster. Specifica la regola predefinita utilizzando la raccoltaADMISSION_RULE:
defaultAdmissionRule: ADMISSION_RULE
L'esempio seguente mostra una regola predefinita che consente il deployment solo delle immagini container autorizzate dall'attestatore specificato. Nel caso in cui tutti gli attestatori richiesti non abbiano autorizzato l'immagine, Autorizzazione binaria blocca il deployment e scrive nel log di controllo.
defaultAdmissionRule: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy:
- projects/example-project/attestors/secure-build
clusterAdmissionRules
clusterAdmissionRules dichiararegole specifiche per il cluster per le norme. I vincoli di queste regole si applicano solo al cluster specificato. Se Autorizzazione binaria applica una regola specifica per il cluster a un deployment, la regola predefinita non viene presa in considerazione. Come per le regole predefinite, specifica le regole specifiche per il cluster utilizzando la raccolta ADMISSION_RULE:
clusterAdmissionRules: CLUSTER_SPECIFIER: ADMISSION_RULE
dove CLUSTER_SPECIFIER è l'ID risorsa del cluster a cui si applica la regola nel formato location.name (ad esempio,us-east1-a.prod-cluster).
Gli esempi seguenti mostrano una regola specifica del cluster che consente il deployment solo delle immagini container autorizzate dagli attestatori specificati:
clusterAdmissionRules: us-east1-a.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/example-project/attestors/secure-build - projects/example-project/attestors/prod-qualified
Raccolte di nodi
ADMISSION_RULE
ADMISSION_RULE è una raccolta di nodi che specificano i vincoli per la regola nel seguente formato:
evaluationMode: EVAL_MODE enforcementMode: ENFORCEMENT_MODE requireAttestationsBy:
- ATTESTOR
- ...
Sia defaultAdmissionRule che clusterAdmissionRule fanno riferimento a questa raccolta.
evaluationMode
evaluationMode specifica l'operazione eseguita da Autorizzazione binaria per valutare se eseguire il deployment di un'immagine container. I valori possibili sono:
ALWAYS_ALLOW: Consenti sempre il deployment delle immagini valutate da questa regolaALWAYS_DENY: Nega sempre il deployment delle immagini valutate da questa regolaREQUIRE_ATTESTATION: richiedi a uno o più attestatori di autorizzare il rilascio prima del deployment
Se evaluationMode è REQUIRE_ATTESTATION, devi fornire un riferimento agli attestatori richiesti in[requireAttestationsBy](#requireattestationsby).
enforcementMode
enforcementMode specifica l'azione intrapresa da Autorizzazione binaria se un'immagine container non è conforme ai vincoli definiti nella regola. I valori possibili sono:
ENFORCED_BLOCK_AND_AUDIT_LOG: blocca il deployment e scrive nel log di controllo.DRYRUN_AUDIT_LOG_ONLY: consente il deployment di immagini non conformi e scrive i dettagli della violazione nel log di controllo.
La maggior parte delle regole di produzione utilizza la modalità di applicazione ENFORCED_BLOCK_AND_AUDIT_LOG.DRYRUN_AUDIT_LOG_ONLY viene utilizzato principalmente per testare una norma nel tuo ambiente prima che entri in vigore.
requireAttestationsBy
requireAttestationsBy specifica uno o più attestatori che devono autorizzare il rilascio prima che si possa eseguire il deployment di un'immagine container. Questo è necessario solo per le regoleREQUIRE_ATTESTATION. Il formato di questo nodo è:
requireAttestationsBy:
- projects/PROJECT_ID/attestors/ATTESTOR_NAME
- ...
dove PROJECT_ID è il nome del progetto in cui sono definiti gli attestatori e ATTESTOR_NAME è il nome di un attestatore che deve firmare il rilascio.
Il seguente esempio mostra come specificare gli attestatori:
requireAttestationsBy:
- projects/example-project/attestors/secure-build
- projects/example-project/attestors/prod-qualified