Insight sulla sicurezza per il runtime

1. Introduzione

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

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 ancora un account Gmail o Google Workspace, devi crearne uno.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • 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.
  1. 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

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 richiesta 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à utilizzata più avanti nel lab:

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

3. Prepara la richiesta

Innanzitutto, 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 seguenti:

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 precedente contiene un comando di avvio e una dipendenza dal framework dell'applicazione web Express.

Quindi, nella stessa directory, crea un file index.js eseguendo i comandi seguenti:

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 e sottoposta a deployment.

4. Esegui il deployment dell'applicazione Cloud Run

Esegui questo comando per eseguire il deployment della tua 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. Artifact Registry e insight sulla sicurezza di Cloud Build

Il completamento della build richiede qualche minuto.

Apri Cloud Build ed esamina gli artefatti della build per la build più recente.

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 di sicurezza relative alla build, ad esempio 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 di Cloud Shell e verifica che il deployment dell'applicazione Cloud Run sia 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 insight sulla sicurezza della catena di fornitura del software, come le informazioni sulla conformità a livello di build SLSA, la provenienza della build e le vulnerabilità trovate nei servizi in esecuzione.

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

62a9f5d26207e58e.png

In questo riquadro vengono visualizzate le seguenti informazioni:

  • Identità e crittografia:l'indirizzo email dell'account di servizio Compute Engine predefinito e la chiave di crittografia utilizzata per il deployment.
  • Livello SLSA: questa build è al livello 3 SLSA, 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 build:i dettagli della build, ad esempio il builder e il link per visualizzare i log.
  • Provenienza build: la provenienza della build, ovvero una raccolta di metadati verificabili su una build. Include dettagli come la sintesi delle immagini create, le posizioni dell'origine di input, la toolchain di build, i passaggi della 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 carichi di lavoro e sulle vulnerabilità. Include la dashboard della security posture (anteprima), che analizza i cluster e i carichi di lavoro GKE per fornirti suggerimenti utili e strategici per migliorare la tua strategia di sicurezza.

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

Verifica che il cluster sia pronto eseguendo questo 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

Ottieni 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 carichi di lavoro GKE dovrebbero avere una configurazione protetta che ne limiti la superficie di attacco. Verificare manualmente su larga scala i carichi di lavoro nei vari cluster per verificare la presenza di problemi di configurazione. Puoi utilizzare la dashboard della security posture per analizzare automaticamente la configurazione di tutti i carichi di lavoro in esecuzione su più cluster e restituire risultati strategici e con punteggio e suggerimenti utili per migliorare la security posture.

Abilita l'analisi della configurazione dei carichi di lavoro:

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

Oltre ad analizzare la configurazione del carico di lavoro, puoi anche abilitare l'analisi delle vulnerabilità dei carichi di lavoro ed esaminare i risultati nella dashboard della security posture, un insieme di funzionalità che forniscono informazioni e suggerimenti utili per migliorare la sicurezza dei tuoi cluster e carichi di lavoro GKE.

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

Se viene rilevata una vulnerabilità nelle immagini container, GKE assegna un punteggio di gravità e mostra i risultati nella dashboard della security posture nella console Google Cloud. Inoltre, GKE aggiunge a Cloud Logging voci per il controllo e la tracciabilità.

Abilita l'analisi delle vulnerabilità dei carichi di lavoro:

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

Apri la pagina Security posture di GKE.

Attendi alcuni minuti per il completamento del controllo del carico di lavoro, quindi esamina i risultati.

5b1b8158bc55ce67.png

Esamina i problemi di configurazione e i carichi di lavoro interessati.

58e6f4b6d8eaa99a.png

Perché utilizzare la dashboard della security posture

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

  • Interruzioni minime: le funzionalità non interferiscono con i carichi di lavoro in esecuzione né interrompono la loro esecuzione.
  • Consigli pratici: se disponibile, la dashboard della security posture fornisce attività 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 tabelle e grafici per mostrare i progressi compiuti e l'impatto potenziale di ogni problema.
  • Risultati definitivi: GKE assegna un grado di gravità ai problemi rilevati in base all'esperienza dei team di sicurezza di Google e agli standard di settore.
  • Log degli eventi verificabili: GKE aggiunge a Logging tutti i problemi rilevati per migliorare la segnalabilità e l'osservabilità.

8. Complimenti!

Complimenti! Hai completato il codelab.

Argomenti trattati:

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

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