Statistiken zur Laufzeitsicherheit

1. Einführung

In diesem Lab stellen Sie eine Anwendung in einem Cloud Run- und GKE-Cluster bereit und sehen sich Sicherheitsinformationen für das Deployment in Software Delivery Shield Security an.

Aufgaben in diesem Lab

• Artifact Registry-Sicherheitsinformationen
• Cloud Run-Sicherheitsinformationen
• GKE-Sicherheitsstatus

2. Einrichtung und Anforderungen

Cloud-Projekt einrichten

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

• Der Projektname ist der Anzeigename für die Projektteilnehmer. Es handelt sich um eine Zeichenfolge, die von Google APIs nicht verwendet wird. Sie können sie jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich. Sie kann nach dem Festlegen nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du dich auf die Projekt-ID beziehen, die üblicherweise als PROJECT_ID gekennzeichnet ist. Wenn Ihnen die generierte ID nicht gefällt, können Sie eine weitere zufällige ID erstellen. Alternativ können Sie einen eigenen verwenden und nachsehen, ob er verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information gibt es noch einen dritten Wert, die Projektnummer, die von manchen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.

Achtung:Eine Projekt-ID ist global eindeutig und kann nach der Auswahl von niemandem verwendet werden. Sie sind der einzige Nutzer dieser ID. Selbst wenn ein Projekt gelöscht wurde, kann die ID nicht mehr verwendet werden

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie die Standardeinstellung Keine Organisation beibehalten. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Dieses Codelab sollte ohne großen Aufwand betrieben werden. Wenn Sie Ressourcen herunterfahren möchten, um über diese Anleitung hinaus keine Kosten zu verursachen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.

Umgebung einrichten

Aktivieren Sie Cloud Shell, indem Sie auf das Symbol rechts neben der Suchleiste klicken.

Aktivieren Sie in Cloud Shell die für dieses Lab erforderlichen APIs:

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

Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf „Autorisieren“. um fortzufahren.

Wenn die Aktivierung erfolgreich war, erhalten Sie eine Meldung, die ungefähr so aussieht:

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

Führen Sie den Befehl aus, um den GKE-Cluster asynchron zu erstellen. Sie wird später in diesem Lab verwendet:

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

3. Antrag vorbereiten

Zuerst bereiten Sie eine einfache Express-basierte Node.js-Anwendung vor, die auf HTTP-Anfragen reagiert.

Erstellen Sie in Cloud Shell ein neues Verzeichnis mit dem Namen starter-nodejs und wechseln Sie zu diesem Verzeichnis:

mkdir starter-nodejs
cd starter-nodejs

Erstellen Sie mit den folgenden Befehlen eine package.json-Datei:

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

Die Datei oben enthält einen Startskriptbefehl und eine Abhängigkeit vom Express-Framework für Webanwendungen.

Erstellen Sie als Nächstes im selben Verzeichnis eine index.js-Datei, indem Sie die folgenden Befehle ausführen:

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

Mit diesem Code wird ein einfacher Webserver erstellt, der den von der Umgebungsvariable PORT definierten Port überwacht. Ihre Anwendung ist jetzt fertig und kann containerisiert und bereitgestellt werden.

4. Cloud Run-Anwendung bereitstellen

Führen Sie den folgenden Befehl aus, um die Anwendung bereitzustellen:

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

Bestätigen Sie das Erstellen des Artifact Registry-Repositorys:

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 und Cloud Build Security Insights

Es dauert einige Minuten, bis der Build abgeschlossen ist.

Öffnen Sie Cloud Build und überprüfen Sie die Build-Artefakte auf den neuesten Build.

Die Cloud Build-Benutzeroberfläche in der Google Cloud Console enthält den Bereich „Software Delivery Shield Security“ mit Sicherheitsinformationen zum Build, z. B. SLSA-Level, Sicherheitslücken in den Abhängigkeiten und Build-Herkunft.

Prüfen Sie die Sicherheitsinformationen für das erstellte Container-Image. Folgen Sie dem Link zu gescannten Artefakten, um Details zu Sicherheitslücken für dieses Image in Artifact Registry aufzurufen.

Kehren Sie zur Cloud Shell-Konsole zurück und prüfen Sie, ob die Bereitstellung der Cloud Run-Anwendung abgeschlossen ist.

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. Cloud Run-Sicherheitsinformationen

Cloud Run enthält einen Sicherheitsbereich (Vorabversion), in dem Statistiken zur Sicherheit der Softwarelieferkette angezeigt werden, z. B. Informationen zur Compliance auf SLSA-Build-Ebene, zur Build-Herkunft und zu Sicherheitslücken in ausgeführten Diensten.

Öffnen Sie Cloud Run und sehen Sie sich die Sicherheitsinformationen auf dem Tab „ÜBERARBEITUNGEN / SICHERHEIT“ an.

In diesem Bereich werden die folgenden Informationen angezeigt:

• Identität und Verschlüsselung: Die E-Mail-Adresse des Compute Engine-Standarddienstkontos und der Verschlüsselungsschlüssel, der für die Bereitstellung verwendet wird.
• SLSA-Level:Dieser Build entspricht dem SLSA-Level 3. Damit wird der Reifegrad des Software-Build-Prozesses gemäß der SLSA-Spezifikation angegeben.
• Sicherheitslücken: Alle Sicherheitslücken in Anwendungsabhängigkeiten.
• Build-Details:Details zum Build, z. B. der Builder und der Link zum Ansehen von Logs.
• Build-Herkunft:Herkunft für den Build, d. h. eine Sammlung überprüfbarer Metadaten zu einem Build. Sie enthält Details wie die Digests der erstellten Images, die Speicherorte der Eingabequellen, die Build-Toolchain, Build-Schritte und die Build-Dauer.

7. GKE-Sicherheitsstatus

GKE kann den Sicherheitsstatus von Containern bewerten und aktiv Unterstützung in Bezug auf Clustereinstellungen, Arbeitslastkonfiguration und Sicherheitslücken bieten. Dazu gehört das Dashboard für den Sicherheitsstatus (Vorabversion), das Ihre GKE-Cluster und -Arbeitslasten scannt. So erhalten Sie fundierte, umsetzbare Empfehlungen zur Verbesserung Ihres Sicherheitsstatus.

In den nächsten Schritten stellen Sie die Anwendung im GKE-Cluster bereit und prüfen die Sicherheitsinformationen im GKE-Dashboard für den Sicherheitsstatus.

Prüfen Sie mit dem folgenden Befehl, ob der Cluster bereit ist:

gcloud beta container clusters list

Beispielausgabe:

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

Rufen Sie die Anmeldedaten und die Konfiguration für den GKE-Cluster ab:

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

Führen Sie den Befehl aus, um die Anwendung mit dem im vorherigen Schritt erstellten Image bereitzustellen:

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

Die GKE-Arbeitslasten sollten idealerweise eine gehärtete Konfiguration haben, die ihre Angriffsfläche begrenzt. Es kann schwierig sein, Arbeitslasten clusterübergreifend auf Konfigurationsprobleme zu prüfen, und zwar in großem Umfang manuell. Sie können das Dashboard für den Sicherheitsstatus verwenden, um die Konfiguration aller ausgeführten Arbeitslasten in mehreren Clustern automatisch zu scannen und umsetzbare, bewertete Ergebnisse sowie spezifische Empfehlungen zur Verbesserung Ihres Sicherheitsstatus zurückzugeben.

Aktivieren Sie das Scannen der Arbeitslastkonfiguration:

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

Neben dem Scannen der Arbeitslastkonfiguration können Sie auch das Scannen von Arbeitslasten auf Sicherheitslücken aktivieren und die Ergebnisse im Sicherheitsstatus-Dashboard prüfen. Dieses Dashboard umfasst eine Reihe von Features, die spezifische Informationen und Empfehlungen zur Verbesserung der Sicherheit Ihrer GKE-Cluster und -Arbeitslasten enthalten.

GKE scannt die Container-Images in jedem zulässigen Pod, der in Ihrem GKE-Cluster ausgeführt wird, automatisch auf bekannte Sicherheitslücken. Dazu werden Daten zu Sicherheitslücken aus öffentlichen CVE-Datenbanken wie NIST verwendet.

Wenn in Ihren Container-Images eine Sicherheitslücke gefunden wird, weist GKE einen Schweregrad zu und zeigt die Ergebnisse im Dashboard für den Sicherheitsstatus in der Google Cloud Console an. GKE fügt Cloud Logging außerdem Einträge zur Prüfung und Rückverfolgbarkeit hinzu.

Aktivieren Sie das Scannen von Arbeitslasten auf Sicherheitslücken:

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

Öffnen Sie die GKE-Seite Security Posture (Sicherheitsstatus).

Warten Sie einige Minuten, bis die Prüfung der Arbeitslast abgeschlossen ist, und prüfen Sie dann die Ergebnisse.

Prüfen Sie Konfigurationsbedenken und betroffene Arbeitslasten.

Vorteile des Dashboards für den Sicherheitsstatus

Das Dashboard für den Sicherheitsstatus ist eine grundlegende Sicherheitsmaßnahme, die Sie für jeden geeigneten GKE-Cluster aktivieren können. Google Cloud empfiehlt aus folgenden Gründen, das Dashboard für den Sicherheitsstatus in allen Clustern zu verwenden:

• Minimale Unterbrechungen: Laufende Arbeitslasten werden nicht durch Features beeinträchtigt oder unterbrochen.
• Umsetzbare Empfehlungen: Sofern verfügbar, werden im Dashboard für den Sicherheitsstatus Maßnahmen zur Behebung erkannter Probleme angezeigt. Zu diesen Aktionen gehören Befehle, die Sie ausführen können, Beispiele für erforderliche Konfigurationsänderungen und Tipps dazu, wie Sie Sicherheitslücken mindern können.
• Visualisierung: Das Dashboard für den Sicherheitsstatus bietet eine allgemeine Visualisierung der Bedenken, die Cluster in Ihrem Projekt betreffen, und enthält Diagramme und Grafiken, die den von Ihnen gemachten Fortschritt und die möglichen Auswirkungen der einzelnen Bedenken darstellen.
• Überprüfte Ergebnisse: Die GKE vergibt für erkannte Bedenken einen Schweregrad, der auf dem Fachwissen der Sicherheitsteams von Google und den Branchenstandards basiert.
• Überprüfbare Ereignislogs: GKE fügt alle erkannten Probleme in Logging hinzu, um die Berichterstellung und Beobachtbarkeit zu verbessern.

8. Glückwunsch!

Glückwunsch! Sie haben das Codelab abgeschlossen.

Behandelte Themen:

• Security Insights-Informationen zu Build-Artefakten und Anwendungen, die in Cloud Run und GKE ausgeführt werden

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten durch Löschen des für die Anleitung erstellten Projekts.

–

Letzte Aktualisierung: 21.03.2023