Questa pagina mostra come utilizzare la convalida continua (CV) di Autorizzazione binaria controllo SLSA, che verifica le Provenienza conforme a SLSA delle immagini container associate ai pod in esecuzione Cluster GKE in cui CV è abilitata.
Per utilizzare questo controllo, devi creare immagini con Cloud Build, che produce Provenienza conforme a SLSA.
L'esempio in questa guida utilizza Cloud Source Repositories per il codice sorgente repository, Artifact Registry per il registro delle immagini e Cloud Build per creare l'immagine e produrre la provenienza.
L'unico builder attendibile supportato dal controllo SLSA è Cloud Build.
Costi
Questa guida utilizza i seguenti servizi Google Cloud:
- Artifact Registry
- Autorizzazione binaria, ma CV è disponibile senza costi durante la fase di anteprima
- Cloud Build
- Cloud Source Repositories
- GKE
Per generare una stima dei costi basata sull'utilizzo previsto, utilizza Calcolatore prezzi.
Prima di iniziare
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories.
gcloud services enable artifactregistry.googleapis.com
binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com - Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories.
gcloud services enable artifactregistry.googleapis.com
binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com - Assicurati che gcloud CLI sia aggiornato all'ultima versione.
- Installa lo strumento a riga di comando
kubectl
. - Se i criteri di Autorizzazione binaria e i cluster GKE si trovano in progetti diversi, assicurati che Autorizzazione binaria sia abilitata in entrambi i progetti.
Ruoli obbligatori
Questa sezione mostra come impostare i ruoli per questo controllo.
Panoramica
Se pubblichi tutti i prodotti menzionati in questa guida nello stesso non devi impostare alcuna autorizzazione. Autorizzazione binaria configura i ruoli correttamente quando lo abiliti. Se pubblichi i prodotti in in progetti diversi, devi impostare i ruoli come descritto in questa sezione.
per garantire che l'agente di servizio di Autorizzazione binaria in ogni progetto disponga delle autorizzazioni necessarie autorizzazioni per valutare il controllo CV SLSA, chiedi all'amministratore di concedere all'agente di servizio di Autorizzazione binaria in ciascun progetto seguenti ruoli IAM:
-
Lettore Artifact Registry (
roles/artifactregistry.reader
) sull'account di servizio Compute Engine del progetto cluster -
Se il progetto del cluster è diverso dal progetto dei criteri:
Valutatore criteri di autorizzazione binaria (
roles/binaryauthorization.policyEvaluator
) sull'agente di servizio di Autorizzazione binaria del progetto cluster, affinché possa accedere al progetto dei criteri -
Se il progetto di attestazione è diverso dal progetto dei criteri:
Visualizzatore occorrenze Container Analysis (
roles/containeranalysis.occurrences.viewer
) sull'agente di servizio di Autorizzazione binaria del progetto di criteri, affinché possa accedere al progetto di attestazione
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.
L'amministratore potrebbe anche essere in grado di fornire all'agente di servizio di Autorizzazione binaria in ciascun progetto le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.
Concedi ruoli utilizzando gcloud CLI
Per garantire che gli account di servizio in ogni progetto dispongano delle risorse necessarie autorizzazioni per valutare questo controllo, concedi agli account di servizio in ogni progetto i seguenti ruoli IAM:
Se il progetto in cui esegui il cluster è diverso da quello in cui si trova il criterio, devi concedere l'autorizzazione per il cluster all'agente di servizio di Autorizzazione binaria del progetto per accedere al criterio per il progetto dei criteri.
Ottieni l'agente di servizio di Autorizzazione binaria del progetto cluster:
PROJECT_NUMBER=$(gcloud projects list \ --filter="projectId:CLUSTER_PROJECT_ID" \ --format="value(PROJECT_NUMBER)") CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
Sostituisci
CLUSTER_PROJECT_ID
con l'ID progetto nel cluster.Consenti a CV di valutare il criterio sul cluster:
gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \ --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \ --role='roles/binaryauthorization.policyEvaluator'
Sostituisci
POLICY_PROJECT_ID
con l'ID del contenente il criterio.
Consenti all'agente di servizio del progetto del criterio di accedere alle attestazioni:
Ottenere l'agente di servizio di Autorizzazione binaria associato al criterio progetto:
PROJECT_NUMBER=$(gcloud projects list \ --filter="projectId:POLICY_PROJECT_ID" \ --format="value(PROJECT_NUMBER)") POLICY_PROJECT_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
Sostituisci
POLICY_PROJECT_ID
con l'ID del contenente il criterio.Concedi il ruolo:
gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \ --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \ --role='roles/containeranalysis.occurrences.viewer'
Sostituisci
ATTESTATION_PROJECT_ID
con l'ID del che contiene le tue attestazioni.
Consenti all'autorizzazione predefinita dell'account di servizio Compute Engine di eseguire il pull un'immagine dal repository:
Recupera l'account di servizio Compute Engine associato progetto cluster:
PROJECT_NUMBER=$(gcloud projects list \ --filter="projectId:CLUSTER_PROJECT_ID" \ --format="value(PROJECT_NUMBER)") COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"
Sostituisci
CLUSTER_PROJECT_ID
con l'ID del progetto cluster che contiene il tuo criterio.Concedi il ruolo:
gcloud projects add-iam-policy-binding ARTIFACT_PROJECT_ID \ --member="serviceAccount:$COMPUTE_ENGINE_SERVICE_ACCOUNT" \ --role='roles/artifactregistry.reader'
Sostituisci
ARTIFACT_PROJECT_ID
con l'ID del progetto Artifact Registry che archivia le immagini da di cui è stato eseguito il deployment.
(Facoltativo) Crea e carica un'immagine di esempio
Questa sezione è inclusa a scopo illustrativo, per mostrare come creare un immagine di esempio con provenienza conforme a SLSA. La provenienza viene utilizzata in seguito la guida per dimostrare il controllo. Scopri di più sulla provenienza di Cloud Build.
Crea il repository di esempio
Per creare un repository in Cloud Source Repositories, segui questi passaggi:
Crea il repository e clonalo localmente:
gcloud source repos create SOURCE_REPO_NAME \ --project=SOURCE_REPO_PROJECT_ID && \ gcloud source repos clone SOURCE_REPO_NAME \ --project=SOURCE_REPO_PROJECT_ID && \ cd SOURCE_REPO_NAME
Sostituisci quanto segue:
SOURCE_REPO_NAME
: il nome del codice sorgente un repository attendibile, ad esempio:slsa-check-test-repo
SOURCE_REPO_PROJECT_ID
: l'ID progetto del repository
Per creare i file di origine, di configurazione e di build, procedi nel seguente modo: seguenti:
Crea l'origine dell'immagine:
cat > quickstart.sh <<EOF #!/bin/sh echo "Hello, world! The time is $(date)." sleep infinity EOF
Rendi eseguibile il file:
chmod +x quickstart.sh
Crea il file di configurazione Dockerfile:
cat > Dockerfile <<EOF FROM alpine COPY quickstart.sh / CMD ["/quickstart.sh"] EOF
Crea il file
cloudbuild.yaml
di Cloud Build, che esegue il push dell'immagine in Artifact Registry:cat > cloudbuild.yaml <<EOF steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ] options: requestedVerifyOption: VERIFIED images: - 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE' EOF
Sostituisci quanto segue:
LOCATION
: la posizione di Artifact Registry, per esempio:us-west2
,europe-central2
oasia-east1
ARTIFACT_PROJECT_ID
: l'ID del progetto che archivia gli artefatti di Artifact RegistryARTIFACT_REPO_NAME
: Artifact Registry nome del repository, ad esempio:slsa-check-test-repo
DIRECTORY
: la directory, ad esempio:slsa-check
IMAGE
: il percorso dell'immagine, per esempio:slsa-check-image
Esegui il commit dei file in Cloud Source Repositories:
git add . git commit -a
Crea e carica l'immagine di esempio
Per semplificare l'utilizzo di questa guida, ti consigliamo di usare lo stesso progetto per SOURCE_REPO_PROJECT_ID e ARTIFACT_PROJECT_ID. Se progetti diversi, potresti dover configurare autorizzazioni aggiuntive. Scopri di più sul controllo dell'accesso di Artifact Registry. Per saperne di più su Cloud Build, consulta Panoramica di Cloud Build.
Per creare il repository:
Crea il repository Artifact Registry:
gcloud artifacts repositories create ARTIFACT_REPO_NAME \ --project=ARTIFACT_PROJECT_ID \ --repository-format=docker \ --location=LOCATION \ --description="Docker repository"
Sostituisci quanto segue:
ARTIFACT_REPO_NAME
: il nome del repositoryARTIFACT_PROJECT_ID
: ID progetto dell'artefattoLOCATION
: la posizione di Artifact Registry, per esempio:us-west2
,europe-central2
oasia-east1
Crea il trigger di build di Cloud Build:
gcloud beta builds triggers create cloud-source-repositories \ --project=SOURCE_REPO_PROJECT_ID \ --repo=SOURCE_REPO_NAME \ --region=LOCATION \ --branch-pattern=.* \ --build-config=cloudbuild.yaml
Sostituisci quanto segue:
SOURCE_REPO_NAME
: il repository del codice sorgente nomeSOURCE_REPO_PROJECT_ID
: il ID progetto Cloud BuildLOCATION
: la località
Per attivare una build, esegui il push dei file che hai creato in precedenza guida.
git push
Quando l'immagine viene creata correttamente, Cloud Build genera provenienza e carica l'immagine nel repository Artifact Registry.
Per controllare l'ultima immagine e ottenerne il digest, segui questi passaggi:
Assicurati che Cloud Build abbia creato la tua immagine:
gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \ --project=ARTIFACT_PROJECT_ID \ --sort-by=create_time
Sostituisci quanto segue:
LOCATION
: la posizione di Artifact RegistryARTIFACT_PROJECT_ID
: ID progetto per gli artefattiARTIFACT_REPO_NAME
: il nome del repositoryDIRECTORY
: la directory
Copia il digest dell'immagine più recente. Il digest è simile a: quanto segue:
sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
(Facoltativo) Visualizza la provenienza dell'immagine:
gcloud artifacts docker images describe \ LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \ --project=ARTIFACT_PROJECT_ID \ --show-provenance
Sostituisci quanto segue:
ARTIFACT_PROJECT_ID
: ID progetto per gli artefattiLOCATION
: la posizione di Artifact RegistryARTIFACT_REPO_NAME
: il repository degli artefatti nomeDIRECTORY
: la directoryIMAGE
: il percorso dell'immagineDIGEST
: il digest associato all'immagine
L'output comando è simile al seguente:
image_summary: digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59 fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59 registry: us-west2-docker.pkg.dev repository: slsa-check-repo slsa_build_level: 3 provenance_summary: provenance: - build: intotoStatement: _type: https://in-toto.io/Statement/v0.1 predicateType: https://slsa.dev/provenance/v0.1 slsaProvenance: builder: id: https://cloudbuild.googleapis.com/GoogleHostedWorker materials: - digest: sha1: de4e4227fff1d00d6f7785a827608627e4a369ea uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo metadata: ... envelope: payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0= payloadType: application/vnd.in-toto+json signatures: - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1 sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g== - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1 sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=
L'output deve contenere il blocco
provenance_summary
affinché il controllo SLSA personalizzata. Se l'output non contiene il blocco, verifica che Cloud Build è stato richiamato da un trigger di build. Cloud Build non produce informazioni sulla provenienza quando manualmente.
Crea un criterio relativo alla piattaforma
Per generare la provenienza, devi utilizzare un trigger di Cloud Build l'immagine, come descritto in Creare e caricare l'immagine di esempio.
Per creare un criterio della piattaforma con un controllo SLSA:
Crea il file YAML dei criteri della piattaforma:
cat > POLICY_PATH <<EOF gkePolicy: checkSets: - checks: - displayName: My SLSA check imageAllowlist: # This policy exempts images that are in the following artifact registry allowPattern: - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/** slsaCheck: rules: - attestationSource: containerAnalysisAttestationProjects: - projects/ATTESTATION_PROJECT_ID configBasedBuildRequired: true trustedBuilder: GOOGLE_CLOUD_BUILD trustedSourceRepoPatterns: - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME customConstraints: - CEL_EXPRESSION displayName: My check set EOF
Sostituisci quanto segue:
POLICY_PATH
: un percorso per il file del criterio.ARTIFACT_LOCATION
: la località del repository in Artifact Registry.ARTIFACT_PROJECT_ID
: l'ID del progetto che contiene gli artefatti.ARTIFACT_REPO_NAME
: il repository che contiene dell'immagine.EXEMPT_IMAGE_PATH
: un percorso facoltativo a uno o più immagini esenti, ad esempio:not-built-by-cloud-build
. La Il bloccoimageAllowlist
è incluso in questo criterio della piattaforma per consentirti immagini esenti che non hanno la provenienza in modo da non violare la piattaforma . Se invece vuoi registrare le violazioni da queste immagini, ometti questo blocco.ATTESTATION_PROJECT_ID
: l'ID progetto che per archiviare le attestazioni create da Cloud Build.SOURCE_REPO_PROJECT_ID
: l'ID del progetto che contiene il codice sorgente.SOURCE_REPO_NAME
: il repository che contiene dell'immagine. A scopo illustrativo, per forzare una violazione di questo controllo, impostaSOURCE_REPO_NAME
a un repository di codice sorgente altro rispetto al luogo in cui si trova l'immagine.POLICY_PROJECT_ID
: l'ID del progetto che contiene il criterio CV.POLICY_ID
: l'ID di questo criterio.CEL_EXPRESSION
: una CEL che fornisce vincoli aggiuntivi per il criterio SLSA. Per per aggiungere un vincolo personalizzato che richieda inoltre che le immagini vengano da un percorso directory specifico, sostituisciCEL_EXPRESSION
con la seguente espressione:payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")
Crea il criterio della piattaforma:
Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
- POLICY_ID: un ID criterio della piattaforma
di tua scelta. Se il criterio si trova in un altro progetto, puoi utilizzare il nome completo della risorsa:
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
. - POLICY_PATH: un percorso al file del criterio.
- POLICY_PROJECT_ID: l'ID progetto del criterio.
Esegui la persone che seguo :
Linux, macOS o Cloud Shell
gcloud beta container binauthz policy create POLICY_ID \ --platform=gke \ --policy-file=POLICY_PATH \ --project=POLICY_PROJECT_ID
Windows (PowerShell)
gcloud beta container binauthz policy create POLICY_ID ` --platform=gke ` --policy-file=POLICY_PATH ` --project=POLICY_PROJECT_ID
Windows (cmd.exe)
gcloud beta container binauthz policy create POLICY_ID ^ --platform=gke ^ --policy-file=POLICY_PATH ^ --project=POLICY_PROJECT_ID
- POLICY_ID: un ID criterio della piattaforma
di tua scelta. Se il criterio si trova in un altro progetto, puoi utilizzare il nome completo della risorsa:
Abilita CV
Puoi creare un nuovo cluster o aggiornarne uno esistente per utilizzare il monitoraggio delle conversioni con criteri della piattaforma basati su controlli.
Crea un cluster che utilizza il monitoraggio CV
In questa sezione creerai un cluster che utilizza solo CV il monitoraggio con criteri della piattaforma basati su controlli.
Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
CLUSTER_NAME
: il nome di un cluster.LOCATION
: la località, ad esempious-central1
oasia-south1
.POLICY_PROJECT_ID
: l'ID del progetto in cui è archiviato il criterio.POLICY_ID
: l'ID del criterio.CLUSTER_PROJECT_ID
: l'ID progetto del cluster.
Esegui la persone che seguo :
Linux, macOS o Cloud Shell
gcloud beta container clusters create CLUSTER_NAME \ --location=LOCATION \ --binauthz-evaluation-mode=POLICY_BINDINGS \ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \ --project=CLUSTER_PROJECT_ID
Windows (PowerShell)
gcloud beta container clusters create CLUSTER_NAME ` --location=LOCATION ` --binauthz-evaluation-mode=POLICY_BINDINGS ` --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ` --project=CLUSTER_PROJECT_ID
Windows (cmd.exe)
gcloud beta container clusters create CLUSTER_NAME ^ --location=LOCATION ^ --binauthz-evaluation-mode=POLICY_BINDINGS ^ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^ --project=CLUSTER_PROJECT_ID
Crea un cluster che utilizza l'applicazione forzata e il monitoraggio delle conversioni
In questa sezione creerai un cluster che utilizza Applicazione dei criteri project-singleton e monitoraggio delle conversioni con criteri della piattaforma basati su controlli:
Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
CLUSTER_NAME
: il nome di un cluster.LOCATION
: la località, ad esempious-central1
oasia-south1
.POLICY_PROJECT_ID
: l'ID del progetto in cui è archiviato il criterio.POLICY_ID
: l'ID del criterio.CLUSTER_PROJECT_ID
: l'ID progetto del cluster.
Esegui la persone che seguo :
Linux, macOS o Cloud Shell
gcloud beta container clusters create CLUSTER_NAME \ --location=LOCATION \ --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \ --project=CLUSTER_PROJECT_ID
Windows (PowerShell)
gcloud beta container clusters create CLUSTER_NAME ` --location=LOCATION ` --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ` --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ` --project=CLUSTER_PROJECT_ID
Windows (cmd.exe)
gcloud beta container clusters create CLUSTER_NAME ^ --location=LOCATION ^ --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^ --project=CLUSTER_PROJECT_ID
Aggiorna un cluster per utilizzare il monitoraggio CV
In questa sezione aggiorni un cluster per utilizzare il monitoraggio CV solo con criteri della piattaforma basati su controlli. Se il cluster ha già applicazione del criterio project-singleton abilitata; l'esecuzione di questo comando disabilita li annotino. Valuta invece la possibilità di aggiornare il cluster con applicazione forzata Monitoraggio CV abilitato.
Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
CLUSTER_NAME
: il nome del clusterLOCATION
: la località, ad esempious-central1
oasia-south1
POLICY_PROJECT_ID
: l'ID del progetto in cui è archiviato il criterioPOLICY_ID
: l'ID del criterioCLUSTER_PROJECT_ID
: l'ID progetto del cluster
Esegui la persone che seguo :
Linux, macOS o Cloud Shell
gcloud beta container clusters update CLUSTER_NAME \ --location=LOCATION \ --binauthz-evaluation-mode=POLICY_BINDINGS \ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \ --project=CLUSTER_PROJECT_ID
Windows (PowerShell)
gcloud beta container clusters update CLUSTER_NAME ` --location=LOCATION ` --binauthz-evaluation-mode=POLICY_BINDINGS ` --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ` --project=CLUSTER_PROJECT_ID
Windows (cmd.exe)
gcloud beta container clusters update CLUSTER_NAME ^ --location=LOCATION ^ --binauthz-evaluation-mode=POLICY_BINDINGS ^ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^ --project=CLUSTER_PROJECT_ID
Aggiorna un cluster per utilizzare l'applicazione forzata e il monitoraggio delle conversioni
In questa sezione aggiorni un cluster in modo che utilizzi il criterio di singleton progetto applicazione delle norme e monitoraggio delle conversioni con una piattaforma basata su controlli criteri.
Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
CLUSTER_NAME
: il nome di un clusterLOCATION
: la località, ad esempious-central1
oasia-south1
POLICY_PROJECT_ID
: l'ID del progetto in cui è archiviato il criterioPOLICY_ID
: l'ID del criterioCLUSTER_PROJECT_ID
: l'ID progetto del cluster
Esegui la persone che seguo :
Linux, macOS o Cloud Shell
gcloud beta container clusters update CLUSTER_NAME \ --location=LOCATION \ --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \ --project=CLUSTER_PROJECT_ID
Windows (PowerShell)
gcloud beta container clusters update CLUSTER_NAME ` --location=LOCATION ` --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ` --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ` --project=CLUSTER_PROJECT_ID
Windows (cmd.exe)
gcloud beta container clusters update CLUSTER_NAME ^ --location=LOCATION ^ --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^ --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^ --project=CLUSTER_PROJECT_ID
Esegui il deployment dell'immagine
Configura
kubectl
:gcloud container clusters get-credentials CLUSTER_NAME \ --location=LOCATION \ --project=CLUSTER_PROJECT_ID
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo clusterLOCATION
: la località del clusterCLUSTER_PROJECT_ID
: l'ID progetto del cluster
Esegui il deployment del pod:
kubectl run hello-app \ --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'
È stato eseguito il deployment del pod. Perché l'immagine è stata creata e da un repository di codice sorgente affidabile, non violerà le Controllo CV SLSA e nessuna voce di log generata.
Per forzare una violazione del controllo SLSA, puoi impostare:
SOURCE_REPO_NAME
a un altro repository di codice sorgente rispetto al luogo in cui si trova l'immagine. Puoi anche attivare manualmente la build, che ignora la generazione della provenienza. Controlla quindi le voci di log.
Visualizza i log per le voci CV
Puoi cercare le voci di Cloud Logging per trovare gli errori di configurazione CV e violazioni dei criteri della piattaforma CV.
Errori e violazioni dei log CV di Cloud Logging entro 24 ore. In genere, puoi visualizzare le voci entro poche ore.
Visualizza i log degli errori di configurazione CV
Per visualizzare i log degli errori di configurazione CV, esegui questo comando:
gcloud logging read \
--order="desc" \
--freshness=7d \
--project=CLUSTER_PROJECT_ID \
'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'
L'output seguente mostra un errore di configurazione in cui un CV criterio della piattaforma non trovato:
{
"insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
"jsonPayload": {
"@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
"configErrorEvent": {
"description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
}
},
"resource": {
"type": "k8s_cluster",
"labels": {
"cluster_name": "my-cluster",
"location": "us-central1-c",
"project_id": "my-project"
}
},
"timestamp": "2024-05-28T15:31:03.999566Z",
"severity": "WARNING",
"logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
"receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}
Visualizza le violazioni dei criteri della piattaforma CV
Se nessuna immagine viola le norme relative alla piattaforma che hai attivato, nessuna voce vengono visualizzate nei log.
Per visualizzare le voci di log CV relative agli ultimi sette giorni, esegui questo comando :
gcloud logging read \
--order="desc" \
--freshness=7d \
--project=CLUSTER_PROJECT_ID \
'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'
Sostituisci CLUSTER_PROJECT_ID
con l'ID progetto del cluster.
Tipi di controlli
I log CV controllano le informazioni sulle violazioni per checkResults
. Nella
, il valore checkType
indica il controllo. I valori di ogni controllo sono
come segue:
ImageFreshnessCheck
SigstoreSignatureCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck
Log di esempio
La voce di logging CV di esempio che segue descrive un'immagine non conforme che viola un controllo delle directory attendibili:
{
"insertId": "637c2de7-0000-2b64-b671-24058876bb74",
"jsonPayload": {
"podEvent": {
"endTime": "2022-11-22T01:14:30.430151Z",
"policyName": "projects/123456789/platforms/gke/policies/my-policy",
"images": [
{
"result": "DENY",
"checkResults": [
{
"explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
"checkSetName": "My check set",
"checkSetIndex": "0",
"checkName": "My trusted directory check",
"verdict": "NON_CONFORMANT",
"checkType": "TrustedDirectoryCheck",
"checkIndex": "0"
}
],
"image": "gcr.io/my-project/hello-app:latest"
}
],
"verdict": "VIOLATES_POLICY",
"podNamespace": "default",
"deployTime": "2022-11-22T01:06:53Z",
"pod": "hello-app"
},
"@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
},
"resource": {
"type": "k8s_cluster",
"labels": {
"project_id": "my-project",
"location": "us-central1-a",
"cluster_name": "my-test-cluster"
}
},
"timestamp": "2022-11-22T01:44:28.729881832Z",
"severity": "WARNING",
"logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
"receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}
Esegui la pulizia
Questa sezione descrive come eseguire la pulizia del monitoraggio CV configurate in precedenza in questa guida.
Puoi disabilitare il monitoraggio degli errori o entrambe le funzionalità di Autorizzazione binaria e CV nel tuo cluster.
Disabilita Autorizzazione binaria in un cluster
Per disattivare l'applicazione forzata di CV e di Autorizzazione binaria in esegui questo comando:
gcloud beta container clusters update CLUSTER_NAME \
--binauthz-evaluation-mode=DISABLED \
--location=LOCATION \
--project=CLUSTER_PROJECT_ID
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del clusterLOCATION
: la località del clusterCLUSTER_PROJECT_ID
: l'ID progetto del cluster
Disabilita il monitoraggio dei criteri basato su controlli in un cluster
a disabilitare la correzione CV con criteri basati su controllo nel cluster riattiva l'applicazione utilizzando il criterio di applicazione di Autorizzazione binaria, esegui il seguente comando:
gcloud beta container clusters update CLUSTER_NAME \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--location=LOCATION \
--project="CLUSTER_PROJECT_ID"
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del clusterLOCATION
: la località del clusterCLUSTER_PROJECT_ID
: l'ID progetto del cluster
Tieni presente che --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
è
equivalente al precedente flag --enable-binauthz
.
Elimina il criterio
Per eliminare il criterio, esegui questo comando. Non è necessario eliminare il criterio della piattaforma basata sui controlli per disabilitare il controllo dei criteri basati sui controlli.
gcloud beta container binauthz policy delete POLICY_ID \
--platform=gke \
--project="POLICY_PROJECT_ID"
Sostituisci quanto segue:
POLICY_ID
: l'ID del criterioPOLICY_PROJECT_ID
: l'ID progetto del criterio
Passaggi successivi
- Utilizzare il controllo di aggiornamento delle immagini
- Utilizzare il semplice controllo dell'attestazione della firma
- Utilizzare il controllo della firma di Sigstore
- Utilizzare il controllo SLSA
- Utilizzare il controllo della directory attendibile
- Utilizza il controllo delle vulnerabilità
- Visualizza log CV