1. Introduzione
Autorizzazione binaria è un controllo di sicurezza applicato in fase di deployment per garantire che venga eseguito il deployment su Google Kubernetes Engine (GKE) o Cloud Run solo delle immagini container attendibili. Con Autorizzazione binaria, puoi richiedere che le immagini vengano firmate da autorità attendibili durante il processo di sviluppo e quindi applicare la convalida della firma durante il deployment. Se applichi la convalida, puoi controllare più strettamente l'ambiente dei container assicurando che solo le immagini verificate siano integrate nel processo di build e rilascio.
Il seguente diagramma mostra i componenti di una configurazione di Autorizzazione binaria/Cloud Build:
**Figura 1.**Pipeline Cloud Build che crea un'attestazione di Autorizzazione binaria.
In questa pipeline:
- Il codice per la creazione dell'immagine container viene inviato a un repository di codice sorgente, come Cloud Source Repositories.
- Cloud Build, uno strumento di integrazione continua (CI), crea e testa il container.
- La build esegue il push dell'immagine container in Container Registry o in un altro registro in cui sono archiviate le immagini create.
- Cloud Key Management Service, che fornisce la gestione delle chiavi per la coppia di chiavi crittografiche, firma l'immagine container. La firma risultante viene quindi archiviata in un'attestazione appena creata.
- Durante il deployment, l'attestatore verifica l'attestazione utilizzando la chiave pubblica della coppia di chiavi. Autorizzazione binaria applica il criterio richiedendo attestazioni firmate per eseguire il deployment dell'immagine container.
In questo lab ti concentrerai sugli strumenti e sulle tecniche per proteggere gli artefatti di cui è stato eseguito il deployment. Questo lab è incentrato sugli artefatti (container) dopo che sono stati creati, ma di cui non è stato eseguito il deployment in nessun ambiente specifico.
Cosa imparerai a fare
- Firma immagine
- Norme sul controllo di ammissione
- Firma delle immagini scansionate in corso...
- Autorizzazione delle immagini firmate
- Immagini non firmate bloccate
2. Configurazione e requisiti
Configurazione dell'ambiente autogestito
- Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
- Il Nome progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarla in qualsiasi momento.
- L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; di solito non ti importa cosa sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere è identificato come
PROJECT_ID). Se l'ID generato non ti soddisfa, puoi generarne un altro casuale. In alternativa, puoi provarne una personalizzata per verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto. - Per informazione, c'è un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare risorse/API Cloud. Eseguire questo codelab non dovrebbe costare molto. Per arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial, puoi eliminare le risorse che hai creato o eliminare l'intero progetto. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.
Configurazione dell'ambiente
In Cloud Shell, imposta l'ID e il numero del progetto. Salvale come variabili PROJECT_ID e PROJECT_ID.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
--format='value(projectNumber)')
Abilitazione dei servizi
Abilita tutti i servizi necessari:
gcloud services enable \
cloudkms.googleapis.com \
cloudbuild.googleapis.com \
container.googleapis.com \
containerregistry.googleapis.com \
artifactregistry.googleapis.com \
containerscanning.googleapis.com \
ondemandscanning.googleapis.com \
binaryauthorization.googleapis.com
Crea repository Artifact Registry
In questo lab utilizzerai Artifact Registry per archiviare e scansionare le tue immagini. Crea il repository con il comando seguente.
gcloud artifacts repositories create artifact-scanning-repo \
--repository-format=docker \
--location=us-central1 \
--description="Docker repository"
Configura docker per utilizzare le tue credenziali gcloud durante l'accesso ad Artifact Registry.
gcloud auth configure-docker us-central1-docker.pkg.dev
Crea e modifica in una directory di lavoro
mkdir vuln-scan && cd vuln-scan
Definisci un'immagine di esempio
Crea un file denominato Dockerfile con il contenuto seguente.
cat > ./Dockerfile << EOF
from python:3.8-slim
# App
WORKDIR /app
COPY . ./
RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0
CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app
EOF
Crea un file denominato main.py con i seguenti contenuti
cat > ./main.py << EOF
import os
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello_world():
name = os.environ.get("NAME", "Worlds")
return "Hello {}!".format(name)
if __name__ == "__main__":
app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF
Crea ed esegui il push dell'immagine in AR
Utilizza Cloud Build per creare il container ed eseguirne automaticamente il push ad Artifact Registry.
gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
3. Firma immagine
Cos'è un attestatore
Attestatore
- Questa persona/processo è responsabile di un anello della catena di attendibilità del sistema.
- Sono in possesso di una chiave di crittografia e firmano un'immagine se supera il processo di approvazione.
- Mentre l'autore delle norme determina le norme in modo astratto e generale, l'attestatore è responsabile dell'applicazione concreta di alcuni aspetti delle norme.
- Può essere una persona reale, come un tester QA o un manager, oppure un bot in un sistema CI.
- La sicurezza del sistema dipende dall'affidabilità, quindi è importante che le loro chiavi private siano protette.
Ciascuno di questi ruoli può rappresentare una singola persona o un team di persone della tua organizzazione. In un ambiente di produzione, questi ruoli verrebbero probabilmente gestiti da progetti separati della piattaforma Google Cloud e l'accesso alle risorse verrebbe condiviso tra i ruoli in modo limitato utilizzando Cloud IAM.
Gli attestatori in Autorizzazione binaria vengono implementati sull'API Cloud Container Analysis, pertanto è importante descriverne il funzionamento prima di procedere. L'API Container Analysis è stata progettata per consentirti di associare i metadati a immagini container specifiche.
Ad esempio, potrebbe essere creata una nota per tracciare la vulnerabilità Heartbleed. I fornitori di sicurezza creavano quindi scanner per testare le immagini dei container per individuare la vulnerabilità e creano un'occorrenza associata a ogni container compromesso.
Oltre alle vulnerabilità di monitoraggio, Container Analysis è stato progettato come API di metadati generica. Autorizzazione binaria utilizza Container Analysis per associare le firme alle immagini container che vengono verificate**.** Una nota Container Analysis viene utilizzata per rappresentare un singolo attestatore e le occorrenze vengono create e associate a ogni container approvato dall'attestatore.
L'API Binary Authorization utilizza i concetti di "attestori" e "attestazioni", ma queste vengono implementate utilizzando Note e occorrenze corrispondenti nell'API Container Analysis.
Crea una nota attestatore
Una nota attestatore è semplicemente un piccolo dato che funge da etichetta per il tipo di firma applicata. Ad esempio, una nota potrebbe indicare un'analisi delle vulnerabilità, mentre un'altra potrebbe essere utilizzata per la firma del QA. Verrà fatto riferimento alla nota durante il processo di firma.
Creare una nota
cat > ./vulnz_note.json << EOM
{
"attestation": {
"hint": {
"human_readable_name": "Container Vulnerabilities attestation authority"
}
}
}
EOM
Archivia la nota
NOTE_ID=vulnz_note
curl -vvv -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
--data-binary @./vulnz_note.json \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
Verifica la nota
curl -vvv \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"
La tua nota è ora salvata all'interno dell'API Container Analysis.
Creazione di un attestatore
Gli attestatori vengono utilizzati per eseguire l'effettivo processo di firma dell'immagine e allegheranno un'occorrenza della nota all'immagine per una verifica successiva. Per utilizzare l'attestatore, devi anche registrare la nota con Autorizzazione binaria:
Crea attestatore
ATTESTOR_ID=vulnz-attestor
gcloud container binauthz attestors create $ATTESTOR_ID \
--attestation-authority-note=$NOTE_ID \
--attestation-authority-note-project=${PROJECT_ID}
Verifica attestatore
gcloud container binauthz attestors list
Tieni presente che l'ultima riga indica NUM_PUBLIC_KEYS: 0 che fornirai le chiavi in un passaggio successivo
Tieni inoltre presente che Cloud Build crea automaticamente l'attestatore built-by-cloud-build nel tuo progetto quando esegui una build che genera immagini. Il comando riportato sopra restituisce quindi due attestatori, vulnz-attestor e built-by-cloud-build. Una volta create correttamente le immagini, Cloud Build firma e crea automaticamente le attestazioni.
Aggiunta di un ruolo IAM
L'account di servizio di Autorizzazione binaria dovrà disporre dei diritti per visualizzare le note di attestazione. Fornisci l'accesso con la seguente chiamata API
PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)")
BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
cat > ./iam_request.json << EOM
{
'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
'policy': {
'bindings': [
{
'role': 'roles/containeranalysis.notes.occurrences.viewer',
'members': [
'serviceAccount:${BINAUTHZ_SA_EMAIL}'
]
}
]
}
}
EOM
Utilizza il file per creare il criterio IAM
curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
--data-binary @./iam_request.json \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
Aggiunta di una chiave KMS
Prima di poter utilizzare questo attestatore, l'autorità deve creare una coppia di chiavi di crittografia da utilizzare per firmare le immagini container. Questa operazione può essere eseguita mediante Google Cloud Key Management Service (KMS).
Innanzitutto aggiungi alcune variabili di ambiente per descrivere la nuova chiave
KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1
Crea un keyring per contenere un set di chiavi
gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"
Crea una nuova coppia di chiavi di firma asimmetrica per l'attestatore
gcloud kms keys create "${KEY_NAME}" \
--keyring="${KEYRING}" --location="${KEY_LOCATION}" \
--purpose asymmetric-signing \
--default-algorithm="ec-sign-p256-sha256"
La chiave dovrebbe essere visualizzata nella pagina KMS della console Google Cloud.
Ora associa la chiave all'attestatore tramite il comando gcloud binauthz:
gcloud beta container binauthz attestors public-keys add \
--attestor="${ATTESTOR_ID}" \
--keyversion-project="${PROJECT_ID}" \
--keyversion-location="${KEY_LOCATION}" \
--keyversion-keyring="${KEYRING}" \
--keyversion-key="${KEY_NAME}" \
--keyversion="${KEY_VERSION}"
Se stampi di nuovo l'elenco delle autorità, a questo punto dovresti vedere una chiave registrata:
gcloud container binauthz attestors list
Creazione di un'attestazione firmata
A questo punto hai configurato le funzionalità che ti consentono di firmare le immagini. Utilizza l'attestatore creato in precedenza per firmare l'immagine container che stai utilizzando.
Un'attestazione deve includere una firma crittografica per indicare che l'attestatore ha verificato una determinata immagine container ed è sicura per l'esecuzione sul cluster. Per specificare quale immagine container attestare, devi determinarne il digest.
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
--format='get(image_summary.digest)')
Ora puoi utilizzare gcloud per creare la tua attestazione. Il comando inserisce semplicemente i dettagli della chiave che vuoi utilizzare per la firma e l'immagine container specifica che vuoi approvare
gcloud beta container binauthz attestations sign-and-create \
--artifact-url="${CONTAINER_PATH}@${DIGEST}" \
--attestor="${ATTESTOR_ID}" \
--attestor-project="${PROJECT_ID}" \
--keyversion-project="${PROJECT_ID}" \
--keyversion-location="${KEY_LOCATION}" \
--keyversion-keyring="${KEYRING}" \
--keyversion-key="${KEY_NAME}" \
--keyversion="${KEY_VERSION}"
Nei termini di Container Analysis, viene creata una nuova occorrenza che viene allegata alla nota dell'attestatore. Per assicurarti che tutto abbia funzionato come previsto, puoi elencare le tue attestazioni
gcloud container binauthz attestations list \
--attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}
4. Norme sul controllo di ammissione
Autorizzazione binaria è una funzionalità di GKE e Cloud Run che offre la possibilità di convalidare le regole prima che sia consentita l'esecuzione di un'immagine container. La convalida viene eseguita su qualsiasi richiesta di esecuzione di un'immagine, che si tratti di una pipeline CI/CD attendibile o di un utente che tenta manualmente di eseguire il deployment di un'immagine. Questa funzionalità consente di proteggere gli ambienti di runtime in modo più efficace rispetto ai soli controlli della pipeline CI/CD.
Per comprendere questa funzionalità modificherai il criterio GKE predefinito in modo da applicare una regola di autorizzazione rigorosa.
Crea il cluster GKE
Crea il cluster GKE con Autorizzazione binaria abilitata:
gcloud beta container clusters create binauthz \
--zone us-central1-a \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Consenti a Cloud Build di eseguire il deployment in questo cluster:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/container.developer"
Consenti tutti i criteri
Prima verifica lo stato del criterio predefinito e la tua possibilità di eseguire il deployment di qualsiasi immagine
- Esamina il criterio esistente
gcloud container binauthz policy export
- Tieni presente che il criterio di applicazione è impostato su
ALWAYS_ALLOW
evaluationMode: ALWAYS_ALLOW
- Esegui il deployment di Sample per verificare che sia possibile eseguire il deployment di qualsiasi cosa
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- Verifica che il deployment sia stato eseguito correttamente
kubectl get pods
Verrà visualizzato l'output seguente
- Elimina deployment
kubectl delete pod hello-server
Nega tutti i criteri
Ora aggiorna la norma per non consentire tutte le immagini.
- Esporta il criterio corrente in un file modificabile
gcloud container binauthz policy export > policy.yaml
- Modifica la norma
In un editor di testo, cambia il valore assessmentMode da ALWAYS_ALLOW a ALWAYS_DENY.
edit policy.yaml
Il file YAML del criterio dovrebbe essere visualizzato come segue:
globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy
Questo criterio è relativamente semplice. La riga globalPolicyEvaluationMode dichiara che questo criterio estende il criterio globale definito da Google. In questo modo tutti i container GKE ufficiali possono essere eseguiti per impostazione predefinita. Inoltre, il criterio dichiara una defaultAdmissionRule che indica che gli altri pod verranno rifiutati. La regola di ammissione include una riga enforcementMode, che indica che l'esecuzione sul cluster di tutti i pod non conformi a questa regola deve essere bloccata.
Per istruzioni su come creare criteri più complessi, consulta la documentazione di Autorizzazione binaria.
- Apri Terminale, applica il nuovo criterio e attendi alcuni secondi per la propagazione della modifica
gcloud container binauthz policy import policy.yaml
- Prova il deployment del carico di lavoro di esempio
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- Il deployment ha esito negativo con il seguente messaggio
Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule
Ripristina il criterio per consentire tutte
Prima di passare alla sezione successiva, assicurati di annullare le modifiche alle norme
- Modifica la norma
In un editor di testo, modifica il valore assessmentMode da ALWAYS_DENY a ALWAYS_ALLOW.
edit policy.yaml
Il file YAML del criterio dovrebbe essere visualizzato come segue:
globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy
- Applica il criterio ripristinato
gcloud container binauthz policy import policy.yaml
5. Firma delle immagini scansionate in corso...
Hai abilitato la firma dell'immagine e utilizzato manualmente l'attestatore per firmare la tua immagine di esempio. In pratica è consigliabile applicare le attestazioni durante i processi automatizzati, come le pipeline CI/CD.
In questa sezione configurerai Cloud Build per Attestare automaticamente le immagini
Ruoli
Aggiungi il ruolo Visualizzatore attestatore autorizzazione binaria all'account di servizio Cloud Build:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/binaryauthorization.attestorsViewer
Aggiungi il ruolo Firmatario/Verificatore CryptoKey Cloud KMS all'account di servizio Cloud Build (firma basata su KMS):
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/cloudkms.signerVerifier
Aggiungi il ruolo Autore associazione note di Container Analysis all'account di servizio Cloud Build:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/containeranalysis.notes.attacher
Fornisci l'accesso per l'account di servizio Cloud Build
Cloud Build avrà bisogno dei diritti per accedere all'API di scansione on demand. Fornisci l'accesso con i seguenti comandi.
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/ondemandscanning.admin"
Prepara il passaggio di Cloud Build per la build personalizzata
Utilizzerai un passaggio della build personalizzata in Cloud Build per semplificare il processo di attestazione. Google fornisce questo passaggio di Creazione personalizzata che contiene funzioni helper per semplificare il processo. Prima dell'uso, il codice per il passaggio di build personalizzato deve essere incorporato in un container e sottoposto a push a Cloud Build. Per farlo, esegui questi comandi:
git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community
Aggiungi un passaggio di firma al file cloudbuild.yaml
In questo passaggio aggiungerai il passaggio di attestazione alla pipeline di Cloud Build.
- Rivedi il passaggio di firma qui sotto.
Solo revisione. Non copiare
#Sign the image only if the previous severity check passes
- id: 'create-attestation'
name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
args:
- '--artifact-url'
- 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
- '--attestor'
- 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
- '--keyversion'
- 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'
- Scrivi un file cloudbuild.yaml con la pipeline completa riportata di seguito.
cat > ./cloudbuild.yaml << EOF
steps:
# build
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
waitFor: ['-']
#Run a vulnerability scan at _SECURITY level
- id: scan
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
(gcloud artifacts docker images scan \
us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
--location us \
--format="value(response.scan)") > /workspace/scan_id.txt
#Analyze the result of the scan
- id: severity check
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
--format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi
#Retag
- id: "retag"
name: 'gcr.io/cloud-builders/docker'
args: ['tag', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']
#pushing to artifact registry
- id: "push"
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']
#Sign the image only if the previous severity check passes
- id: 'create-attestation'
name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
args:
- '--artifact-url'
- 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
- '--attestor'
- 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
- '--keyversion'
- 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'
images:
- us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF
Esegui la build
gcloud builds submit
Rivedi la build nella cronologia di Cloud Build
Apri la pagina Cronologia di Cloud Build nella console Cloud e rivedi l'ultima build e la riuscita esecuzione dei relativi passaggi.
6. Autorizzazione delle immagini firmate
In questa sezione aggiornerà GKE in modo che utilizzi Autorizzazione binaria per convalidare l'immagine che ha una firma dall'analisi delle vulnerabilità prima di consentire l'esecuzione dell'immagine.
Aggiorna il criterio GKE per richiedere l'attestazione
Richiedi che le immagini vengano firmate dall'attestatore aggiungendo clusterAdmissionRules al tuo criterio BinAuth GKE
Attualmente, il tuo cluster esegue un criterio con una regola: consentire i container dei repository ufficiali e rifiutare tutti gli altri.
Sovrascrivi il criterio con la configurazione aggiornata utilizzando il comando seguente.
COMPUTE_ZONE=us-central1-a
cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
${COMPUTE_ZONE}.binauthz:
evaluationMode: REQUIRE_ATTESTATION
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
requireAttestationsBy:
- projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM
Ora dovresti avere un nuovo file su disco, denominato updated_policy.yaml. Ora, invece di rifiutare tutte le immagini, la regola predefinita controlla prima le verifiche dell'attestatore.
Carica il nuovo criterio in Autorizzazione binaria:
gcloud beta container binauthz policy import binauth_policy.yaml
Esegui il deployment di un'immagine firmata
Ottieni la sintesi delle immagini per ottenere un'immagine di qualità
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
--format='get(image_summary.digest)')
Utilizza il digest nella configurazione di Kubernetes
cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
name: deb-httpd
spec:
selector:
app: deb-httpd
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deb-httpd
spec:
replicas: 1
selector:
matchLabels:
app: deb-httpd
template:
metadata:
labels:
app: deb-httpd
spec:
containers:
- name: deb-httpd
image: ${CONTAINER_PATH}@${DIGEST}
ports:
- containerPort: 8080
env:
- name: PORT
value: "8080"
EOM
Esegui il deployment dell'app in GKE
kubectl apply -f deploy.yaml
Esamina il carico di lavoro nella console e prendi nota del corretto deployment dell'immagine.
7. Immagini non firmate bloccate
Crea un'immagine
In questo passaggio utilizzerai il Docker locale per creare l'immagine nella cache locale.
docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .
Esegui il push dell'immagine non firmata nel repository
docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad
Ottieni il digest dell'immagine per l'immagine di scarsa qualità
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
--format='get(image_summary.digest)')
Utilizza il digest nella configurazione di Kubernetes
cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
name: deb-httpd
spec:
selector:
app: deb-httpd
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deb-httpd
spec:
replicas: 1
selector:
matchLabels:
app: deb-httpd
template:
metadata:
labels:
app: deb-httpd
spec:
containers:
- name: deb-httpd
image: ${CONTAINER_PATH}@${DIGEST}
ports:
- containerPort: 8080
env:
- name: PORT
value: "8080"
EOM
Tentativo di eseguire il deployment dell'app su GKE
kubectl apply -f deploy.yaml
Esamina il carico di lavoro nella console e annota l'errore che indica che il deployment è stato negato:
No attestations found that were valid and signed by a key trusted by the attestor
8. Complimenti!
Complimenti, hai completato il codelab.
Argomenti trattati:
- Firma immagine
- Norme sul controllo di ammissione
- Firma delle immagini scansionate in corso...
- Autorizzazione delle immagini firmate
- Immagini non firmate bloccate
Passaggi successivi
- Protezione dei deployment delle immagini in Cloud Run e Google Kubernetes Engine | Documentazione di Cloud Build
- Guida rapida: configura un criterio di Autorizzazione binaria con GKE | Google Cloud
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Elimina il progetto
Il modo più semplice per eliminare la fatturazione è quello di eliminare il progetto che hai creato per il tutorial.
—
Ultimo aggiornamento: 21/03/23