Insight sulla sicurezza per il runtime

1. Introduzione

In questo lab, eseguirai il deployment di un'applicazione in Cloud Run e in un cluster GKE e visualizzerai gli insight sulla sicurezza per il deployment nella sicurezza di Software Delivery Shield.

Cosa imparerai a fare

  • Insight sulla sicurezza di Artifact Registry
  • Insight sulla sicurezza di Cloud Run
  • Strategia di sicurezza di GKE

2. Configurazione e requisiti

Configurazione del progetto Cloud

  1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai già un account Gmail o Google Workspace, devi crearne uno.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È 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 l'impostazione). La console Cloud genera automaticamente una stringa univoca; in genere non ti interessa quale sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a inserirne uno e verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
  • Per tua informazione, esiste un terzo valore, un numero di progetto , utilizzato da alcune API. Scopri di più su tutti e tre i valori nella documentazione.
  1. Dopodiché, dovrai abilitare la fatturazione nella console Cloud per utilizzare le risorse/API Cloud. Completare questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in addebiti di fatturazione oltre questo tutorial, puoi eliminare le risorse create o l'intero progetto. I nuovi utenti di Google Cloud hanno diritto al programma di prova senza costi di 300$.

Configurazione dell'ambiente

Attiva Cloud Shell facendo clic sull'icona a destra della barra di ricerca.

ecdc43ada29e91b.png

Da Cloud Shell, abilita le API richieste per questo lab:

gcloud services enable run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  container.googleapis.com \
  containersecurity.googleapis.com

Se ti viene richiesto di concedere l'autorizzazione, fai clic su "Autorizza" per continuare.

6356559df3eccdda.png

Dovrebbe essere visualizzato un messaggio di operazione riuscita simile a questo:

Operation "operations/acf.p2-327036483151-73d90d00-47ee-447a-b600-a6badf0eceae" finished successfully.

Esegui il comando per creare il cluster GKE in modo asincrono. Verrà utilizzato più avanti nel lab:

gcloud beta container clusters create gke-cluster \
    --zone us-central1-a \
    --async

3. Prepara l'applicazione

Per prima cosa, preparerai una semplice applicazione Node.js basata su Express che risponde alle richieste HTTP.

In Cloud Shell crea una nuova directory denominata starter-nodejs, quindi passa a quella directory:

mkdir starter-nodejs
cd starter-nodejs

Crea un file package.json eseguendo i comandi riportati di seguito:

cat > ./package.json << EOF
{
  "name": "cloudrun-starter-app",
  "version": "1.0.0",
  "description": "Node.js Starter Application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}
EOF

Il file sopra contiene un comando di avvio di script e una dipendenza dal framework dell'applicazione web Express.

Quindi, nella stessa directory, crea un file index.js eseguendo i comandi riportati di seguito:

cat > ./index.js << EOF
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  console.log('Received a request.');
  res.send("Hello Cloud Run!");
});

const port = process.env.PORT || 8080;

app.listen(port, () => {
  console.log('Listening on port', port);
});
EOF

Questo codice crea un server web di base in ascolto sulla porta definita dalla variabile di ambiente PORT. La tua app è ora completa e pronta per essere containerizzata ed eseguita.

4. Esegui il deployment dell'applicazione Cloud Run

Esegui il comando riportato di seguito per eseguire il deployment dell'applicazione:

gcloud run deploy starter-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --max-instances=3

Conferma la creazione del repository Artifact Registry:

Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [cloud-run-source-deploy] in region [us-central1] will be created.

Do you want to continue (Y/n)? y

5. Insight sulla sicurezza di Artifact Registry e Cloud Build

Il completamento della build richiede alcuni minuti.

Apri Cloud Build ed esamina gli artefatti di build per l'ultima build.

L'interfaccia utente di Cloud Build nella console Google Cloud contiene il riquadro degli insight sulla sicurezza di Software Delivery Shield che mostra le informazioni sulla sicurezza relative alla build, come il livello SLSA, eventuali vulnerabilità nelle dipendenze e la provenienza della build.

7d9fd2213f3704c4.png

Esamina gli insight sulla sicurezza per l'immagine container creata. Segui il link per gli artefatti analizzati per visualizzare i dettagli delle vulnerabilità per questa immagine in Artifact Registry.

Torna alla console Cloud Shell e verifica che il deployment dell'applicazione Cloud Run sia stato completato.

Done.
Service [starter-app] revision [starter-app-00001-maw] has been deployed and is serving 100 percent of traffic.
Service URL: https://starter-app-nin5jpgefq-uc.a.run.app

6. Insight sulla sicurezza di Cloud Run

Cloud Run contiene un riquadro di sicurezza (anteprima) che mostra gli insight sulla sicurezza della catena di fornitura del software, come le informazioni sulla conformità al livello di build SLSA, la provenienza della build e le vulnerabilità rilevate nei servizi in esecuzione.

Apri Cloud Run ed esamina gli insight sulla sicurezza nella scheda REVISIONI / SICUREZZA.

62a9f5d26207e58e.png

Questo riquadro mostra le seguenti informazioni:

  • Identità e criptaggio: l'indirizzo email del service account predefinito di Compute Engine e la chiave di criptaggio utilizzata per il deployment.
  • Livello SLSA: questa build è al livello SLSA 3, che identifica il livello di maturità del processo di compilazione del software in conformità con la specifica SLSA.
  • Vulnerabilità: eventuali vulnerabilità rilevate nelle dipendenze dell'applicazione.
  • Dettagli della build: dettagli della build, come il builder e il link per visualizzare i log.
  • Provenienza della build: provenienza della build, ovvero una raccolta di metadati verificabili su una build. Include dettagli come i digest delle immagini create, le località di origine di ingresso, la toolchain di build, i passaggi di build e la durata della build.

7. Strategia di sicurezza di GKE

GKE può valutare la strategia di sicurezza dei container e fornire indicazioni attive sulle impostazioni del cluster, sulla configurazione dei workload e sulle vulnerabilità. Include la dashboard della security posture (anteprima), che analizza i cluster e i workload GKE per fornire suggerimenti attendibili e strategici al fine di migliorare la security posture.

Nei passaggi successivi, eseguirai il deployment dell'applicazione nel cluster GKE ed esaminerai gli insight sulla sicurezza nella dashboard della security posture di GKE.

Verifica che il cluster sia pronto eseguendo il seguente comando:

gcloud beta container clusters list

Esempio di output:

NAME: gke-cluster
LOCATION: us-central1-a
MASTER_VERSION: 1.24.9-gke.3200
MASTER_IP: 34.29.226.228
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.24.9-gke.3200
NUM_NODES: 3
STATUS: RUNNING

Recupera le credenziali e la configurazione per il cluster GKE:

gcloud container clusters get-credentials gke-cluster  \
    --region=us-central1-a

Esegui il comando per eseguire il deployment dell'applicazione utilizzando l'immagine creata nel passaggio precedente:

export PROJECT_ID=$(gcloud config get-value project)

kubectl run starter-app \
  --image us-central1-docker.pkg.dev/${PROJECT_ID}/cloud-run-source-deploy/starter-app:latest \
  --port 8080

Idealmente, i workload GKE dovrebbero avere una configurazione rafforzata che limiti la superficie di attacco. La verifica manuale dei problemi di configurazione dei workload su più cluster può essere difficile da eseguire su larga scala. Puoi utilizzare la dashboard della strategia di sicurezza per analizzare automaticamente la configurazione di tutti i workload in esecuzione su più cluster e restituire risultati strategici e ponderati e suggerimenti per migliorare la strategia di sicurezza.

Abilita l'analisi della configurazione dei workload:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-config-audit

Oltre all'analisi della configurazione dei workload, puoi anche abilitare l'analisi delle vulnerabilità dei workload ed esaminare i risultati nella dashboard della security posture, che è un insieme di funzionalità che forniscono informazioni e suggerimenti ponderati per migliorare la sicurezza dei cluster e dei workload GKE.

GKE analizza automaticamente le immagini container in ogni pod idoneo in esecuzione nel cluster GKE per rilevare vulnerabilità note, utilizzando i dati sulle vulnerabilità provenienti da database CVE pubblici come NIST.

Se viene rilevata una vulnerabilità nelle immagini container, GKE assegna un livello di gravità e visualizza i risultati nella dashboard della security posture nella console Google Cloud. GKE aggiunge anche voci a Cloud Logging per l'audit e la tracciabilità.

Abilita l'analisi delle vulnerabilità dei workload:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-vulnerability-scanning \
    --async

Apri la pagina Strategia di sicurezza di GKE.

Attendi alcuni minuti per il completamento dell'audit dei workload, quindi esamina i risultati.

5b1b8158bc55ce67.png

Esamina i problemi di configurazione e i workload interessati.

58e6f4b6d8eaa99a.png

Perché utilizzare la dashboard della security posture

La dashboard della security posture è una misura di sicurezza fondamentale che puoi abilitare per qualsiasi cluster GKE idoneo. Google Cloud consiglia di utilizzare la dashboard della strategia di sicurezza in tutti i cluster per i seguenti motivi:

  • Interruzioni minime: le funzionalità non interferiscono con i workload in esecuzione né li interrompono.
  • Suggerimenti strategici: quando disponibile, la dashboard della strategia di sicurezza fornisce elementi di azione per risolvere i problemi rilevati. Queste azioni includono comandi che puoi eseguire, esempi di modifiche alla configurazione da apportare e consigli su cosa fare per mitigare le vulnerabilità.
  • Visualizzazione: la dashboard della security posture fornisce una visualizzazione di alto livello dei problemi che interessano i cluster del progetto e include grafici e diagrammi per mostrare i progressi compiuti e il potenziale impatto di ogni problema.
  • Risultati ponderati: GKE assegna un livello di gravità ai problemi rilevati in base all'esperienza dei team di sicurezza di Google e agli standard di settore.
  • Log degli eventi sottoponibili ad audit: GKE aggiunge tutti i problemi rilevati a Logging per una migliore reportistica e osservabilità.

8. Complimenti!

Complimenti! Hai completato il codelab.

Argomenti trattati:

  • Informazioni sugli insight sulla sicurezza per gli artefatti di build e l'applicazione in esecuzione su Cloud Run e GKE

Libera spazio

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 è eliminare il progetto creato per il tutorial.

Ultimo aggiornamento: 21/03/2023