Questa pagina contiene informazioni di riferimento per i criteri di Autorizzazione binaria, come specificato nel 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, consulta i 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 consentito il deployment. | No |
globalPolicyEvaluationMode |
Specifica se applicare un criterio di sistema che esenta le immagini di sistema di proprietà di Google. | No |
defaultAdmissionRule |
La regola da utilizzare quando non si applicano regole specifiche. | 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 progetto Google Cloud in cui è definito il criterio.
Ad esempio:
name: projects/example-project/policy
admissionWhitelistPatterns
admissionWhitelistPatterns
specifica una lista consentita di immagini container
esenti dall'applicazione dei criteri. Devi specificare il percorso delle immagini in Container Registry e Artifact Registry, un altro registro o un riferimento locale nel sottonodo namePattern
:
admissionWhitelistPatterns: - namePattern: MATCHING_PATTERN - ...
Sostituisci MATCHING_PATTERN con un percorso di una singola immagine o con un pattern corrispondente contenente uno dei simboli di 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, al contrario di gcr.io/my-project/n*x
. 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 a
gcr.io/my-project/nginx-1.14.2/image:latest
.
L'esempio seguente aggiunge all'elenco delle immagini esenti per il criterio i registri contenenti immagini di Google Kubernetes Engine (GKE) di uso comune, un'immagine situata in gcr.io/example-project/helloworld
e un riferimento locale a un'immagine:
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 di sistema corrisponde al percorso specificato:
admissionWhitelistPatterns: ... - namePattern: gcr.io/example-project/*
Per inserire un'immagine specifica nella lista consentita:
admissionWhitelistPatterns: ... - namePattern: gcr.io/example-project/helloworld
Per inserire una versione taggata nella lista consentita:
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 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 di criteri che consente ad Autorizzazione binaria di valutare un criterio di sistema prima di valutare quello che configuri. Il criterio di sistema è fornito da Google ed esenta un elenco di immagini di sistema gestite da Google da un'ulteriore valutazione dei criteri. Se questa impostazione è abilitata, le immagini richieste da GKE non vengono bloccate dall'applicazione dei criteri. Il criterio di sistema viene valutato 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 disabilitare la modalità di valutazione dei criteri di sistema:
globalPolicyEvaluationMode: DISABLE
defaultAdmissionRule
defaultAdmissionRule
specifica la regola predefinita per 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 per il cluster. Puoi specificare la regola predefinita utilizzando la raccolta ADMISSION_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 nell'audit log.
defaultAdmissionRule: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/example-project/attestors/secure-build
clusterAdmissionRules
clusterAdmissionRules
dichiarano
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 per il cluster, la regola predefinita non viene considerata. Come per le regole predefinite, devi specificare regole specifiche del 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 per il cluster che consente il deployment solo delle immagini container che sono state 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 uno o più attestatori per autorizzare la release prima del deployment
Se evaluationMode
è REQUIRE_ATTESTATION
, devi fornire un riferimento agli attestatori richiesti in requireAttestationsBy
.
enforcementMode
enforcementMode
specifica l'azione eseguita 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 nell'audit 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 di ENFORCED_BLOCK_AND_AUDIT_LOG
.
DRYRUN_AUDIT_LOG_ONLY
viene utilizzato principalmente per testare un criterio nel
tuo ambiente prima che venga applicato.
requireAttestationsBy
requireAttestationsBy
specifica uno o più attestatori che devono autorizzare la release prima di poter eseguire il deployment di un'immagine container. Questo attributo è obbligatorio solo per
le regole REQUIRE_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 la release.
Nell'esempio seguente viene illustrato come specificare gli attestatori:
requireAttestationsBy: - projects/example-project/attestors/secure-build - projects/example-project/attestors/prod-qualified