Questa pagina contiene informazioni di riferimento per i criteri di Autorizzazione binaria specificati in formato YAML. Quando configuri un criterio utilizzando l'interfaccia a riga di comando, modifichi un file in formato YAML conforme a questa specifica. Per esempi di criteri in formato YAML, vedi Criteri di esempio.
I file YAML dei criteri 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 |
Nome del criterio. | Sì |
admissionWhitelistPatterns |
Specifica le immagini container di cui è sempre possibile eseguire il deployment. | No |
globalPolicyEvaluationMode |
Specifica se applicare un criterio di sistema che escluda i contenuti di proprietà di Google immagini di sistema. | No |
defaultAdmissionRule |
La regola da utilizzare quando non è applicabile alcuna regola specifica. | Sì |
clusterAdmissionRules |
Specifica le regole che si applicano a cluster specifici. | No |
name
Il nodo name
contiene il nome del criterio nel seguente formato:
name: projects/PROJECT_ID/policy
dove PROJECT_ID è il nome del tuo account Google Cloud progetto in cui vengono definiti i criteri.
Ad esempio:
name: projects/example-project/policy
admissionWhitelistPatterns
admissionWhitelistPatterns
specifica una lista consentita di immagini container che sono
esente dall'applicazione dei criteri. Devi specificare
alle immagini in Container Registry e Artifact Registry, in un altro registro oppure
un riferimento locale nel sottonodo namePattern
:
admissionWhitelistPatterns: - namePattern: MATCHING_PATTERN - ...
Sostituisci MATCHING_PATTERN con un percorso a una singola immagine oppure
un pattern corrispondente contenente uno dei simboli con caratteri 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*x
non 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
gcr.io/my-project/nginx-1.14.2/image:latest
.
L'esempio seguente aggiunge registri che contengono
Immagini Google Kubernetes Engine (GKE), un'immagine che si trova
gcr.io/example-project/helloworld
e un riferimento locale a un'immagine, alla
elenco di 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 contenitore la cui posizione nel registry 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 contrassegnata:
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 suo 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
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. Il criterio di sistema viene fornito
di Google ed esenta un elenco di immagini di sistema gestite da Google da ulteriori
la valutazione dei criteri. Se questa impostazione è attiva, le immagini sono obbligatorie
da GKE non sono bloccate dall'applicazione forzata dei criteri. Il sistema
vengono valutati prima e in aggiunta alla valutazione dei criteri relativi agli utenti,
tra cui 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 dei criteri di sistema:
globalPolicyEvaluationMode: DISABLE
defaultAdmissionRule
defaultAdmissionRule
specifica la regola predefinita
per le norme. La regola predefinita definisce i vincoli che si applicano a tutti
immagini container non esenti, ad eccezione di quelle che hanno
una regola specifica per il cluster. Specifica la regola predefinita utilizzando la raccoltaADMISSION_RULE:
defaultAdmissionRule: ADMISSION_RULE
L'esempio seguente mostra una regola predefinita che consente solo quelle container di cui eseguire il deployment che sono state autorizzate dall'autorità attestatore. Se tutti gli attestatori richiesti non hanno 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
dichiara
regole specifiche del cluster per il criterio.
I vincoli in queste regole si applicano solo al cluster specificato. Se
Autorizzazione binaria applica a un deployment una regola specifica del cluster, l'impostazione predefinita
non viene considerata. Come con le regole predefinite, devi specificare specifiche
utilizzando
Raccolta ADMISSION_RULE:
clusterAdmissionRules: CLUSTER_SPECIFIER: ADMISSION_RULE
dove CLUSTER_SPECIFIER è l'ID risorsa del cluster in cui
la regola si applica nel formato location.name
(ad esempio,
us-east1-a.prod-cluster
).
Gli esempi seguenti mostrano una regola specifica del cluster che consente solo quelle di immagini container di cui eseguire il deployment che sono state autorizzate dall'utente attestatori:
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 le limitazioni per la
regola nel seguente formato:
evaluationMode: EVAL_MODE enforcementMode: ENFORCEMENT_MODE requireAttestationsBy: - ATTESTOR - ...
Sia defaultAdmissionRule
che clusterAdmissionRule
fanno riferimento a questa
collezione.
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
: richiedono che uno o più attestatori autorizzino la release prima del deployment
Se evaluationMode
è REQUIRE_ATTESTATION
, devi fornire un riferimento ai soggetti attestanti richiesti in 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 controllo log.DRYRUN_AUDIT_LOG_ONLY
: consente il deployment di immagini non conformi e scrive i dettagli della violazione nell'audit log.
La maggior parte delle regole di produzione utilizza la modalità di applicazione forzata ENFORCED_BLOCK_AND_AUDIT_LOG
.
DRYRUN_AUDIT_LOG_ONLY
viene utilizzato principalmente per testare un criterio in
dell'ambiente di lavoro prima che entri in vigore.
requireAttestationsBy
requireAttestationsBy
specifica uno o più attestatori che devono autorizzare la release prima che sia possibile eseguire il deployment di un'immagine del contenitore. Obbligatorio per
Solo REQUIRE_ATTESTATION
regole. 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 la liberatoria.
Nell'esempio seguente viene illustrato come specificare gli attestatori:
requireAttestationsBy: - projects/example-project/attestors/secure-build - projects/example-project/attestors/prod-qualified