Attestierungen mit Kritis Signer erstellen

In dieser Anleitung wird erläutert, wie Sie Kritis Signer erstellen und damit Container-Images auf Sicherheitslücken prüfen, bevor Sie Attestierungen von Binärautorisierungen erstellen.

Übersicht

Kritis Signer ist ein Open-Source-Befehlszeilentool, das Attestierungen für Binärautorisierung auf der Grundlage einer von Ihnen konfigurierten Richtlinie erstellen kann. Sie können Kritis Signer auch verwenden, um Attestierungen zu erstellen, nachdem Sie ein Image auf von Artefaktanalyse erkannte Sicherheitslücken geprüft haben.

Darüber hinaus kann Cloud Build Kritis Signer als benutzerdefinierten Builder in einer Build-Pipeline ausführen.

In dieser Anleitung führen Sie einen einmaligen Build des benutzerdefinierten Builder von Kritis Signer aus und führen dann Beispiel-Build-Pipelines aus. Jede Beispielpipeline enthält die folgenden Build-Schritte:

1. Beispiel-Container-Image erstellen
2. Laden Sie das Image in Container Registry hoch.
3. Image prüfen und signieren: Mit Kritis Signer eine Attestierung anhand der Richtlinie erstellen.

Im Build-Schritt "Check-and-Sign" jeder Pipeline führt Kritis Signer Folgendes aus:

1. Scannt das neu erstellte Image mit Artefaktanalyse und ruft eine Liste mit Sicherheitslücken ab.
2. Überprüft die Liste der Sicherheitslücken anhand der Regeln zur Signierung von Sicherheitslücken in der Richtlinie und führt dann folgende Schritte aus:
   1. Wenn alle identifizierten Sicherheitslücken die Signaturregeln für Sicherheitslücken erfüllen, erstellt Kritis Signer die Attestierung.
   2. Wenn eine der erkannten Sicherheitslücken gegen die Signaturregeln für Sicherheitslücken verstößt, erstellt Kritis Signer die Attestierung nicht.

Bei der Bereitstellung prüft der Binärautorisierungserzwinger nach einer überprüfbaren Attestierung. Ohne eines kann der Erzwinger das Image nicht bereitstellen.

In dieser Anleitung wird auch erläutert, wie Kritis Signer im Prüfmodus in einer Cloud Build-Pipeline ausgeführt wird. In diesem Modus erstellt Kritis Signer keine Attestierung, sondern nur, ob die Ergebnisse der Sicherheitslücke den Signaturregeln für Sicherheitslücken in der Richtlinie entsprechen. In diesem Fall ist der Build-Schritt von Kritis Signer erfolgreich und die Pipeline wird weiterhin ausgeführt. Andernfalls schlägt der Schritt fehl und die Pipeline wird beendet.

Ziele

In dieser Anleitung tun Sie Folgendes:

1. Kritis Signer als benutzerdefinierten Cloud Build-Builder einrichten.
2. Sehen Sie sich eine Richtlinie an, die Signaturregeln für Sicherheitslücken enthält.
3. Führen Sie Kritis Signer aus, um Attestierungen basierend auf dem Scannen von Sicherheitslücken zu erstellen.
4. Führen Sie Kritis Signer im Prüfmodus aus.

Kosten

Hinweis: In dieser Anleitung werden die folgenden Google Cloud-Produkte verwendet.

• Container Registry
• Artefaktanalyse
• Cloud Build
• Cloud Key Management Service

Mithilfe des Preisrechners können Sie anhand Ihrer voraussichtlichen Nutzung eine Kostenschätzung vornehmen.

Hinweis

In diesem Abschnitt führen Sie eine einmalige Einrichtung des Systems durch.

Umgebung einrichten

1. Speichern Sie Ihr Google Cloud-Projekt in einer Umgebungsvariable.

   Hinweis: Dieses Google Cloud-Projekt wird für diese Anleitung verwendet.

   export PROJECT_ID=PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch Ihr Google Cloud-Projekt.

2. Legen Sie als Standardprojekt-ID Ihr Google Cloud-Projekt fest:

   gcloud config set project $PROJECT_ID
   

3. Speichern Sie die Projektnummer für zukünftige Schritte in einer Umgebungsvariable:

   export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
    --format="value(PROJECT_NUMBER)")
   

4. APIs aktivieren:

   Führen Sie den folgenden Befehl aus, um sicherzustellen, dass die für diese Anleitung erforderlichen Dienste aktiviert sind:

   gcloud services enable \
     cloudbuild.googleapis.com \
     containerregistry.googleapis.com \
     containerscanning.googleapis.com \
     cloudkms.googleapis.com
   

IAM-Rollen einrichten

Führen Sie die folgenden Befehle aus, um das Cloud Build-Dienstkonto mit den folgenden Rollen zu konfigurieren:

• containeranalysis.notes.editor: fügt die Rolle Bearbeiter von Artefaktanalyse-Hinweisen hinzu, um den Attestierer zu verwalten
• containeranalysis.notes.occurrences.viewer: fügt die Rolle Artefaktanalyse-Vorkommen für Hinweise hinzu, um sowohl Sicherheitslücken als auch Attestierungen zu verwalten
• roles/containeranalysis.occurrences.editor: Fügt die Rolle Bearbeiter von Artefaktanalysen hinzu, um Attestierungen in Artifact Analysis zu erstellen.

• cloudkms.signer: fügt die Rolle Cloud KMS CryptoKey-Signer hinzu, mit der das Dienstkonto auf den Cloud KMS-Signaturdienst zugreifen kann.

  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.occurrences.viewer
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.occurrences.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/cloudkms.signer
  

Benutzerdefinierten Builder von Kritis Signer einrichten

In diesem Abschnitt führen Sie eine einmalige Einrichtung des benutzerdefinierten Builder von Kritis Signer durch. Sobald Sie Kritis Signer erhalten, erstellt und hochgeladen haben, kann er in jeder Cloud Build-Pipeline verwendet werden.

In diesem Abschnitt wird Folgendes erläutert:

• Das Kritis-Repository klonen.
• Den benutzerdefinierten Cloud Build-Builder von Kritis Signer einrichten
• Übertragen Sie Kritis Signer nach Container Registry, um sie für einen Build-Schritt in Cloud Build zur Verfügung zu stellen.

Führen Sie die folgenden Befehle aus, um die in dieser Anleitung verwendeten Code- und Konfigurationsdateien abzurufen:

1. Das Kritis-Repository klonen:

   git clone https://github.com/grafeas/kritis.git
   

   Dieses Repository enthält Folgendes:

   • Quellcode für Kritis, der auch Kritis Signer enthält.
   • Eine Cloud Build-Konfigurationsdatei, die von Cloud Build verwendet wird, um den benutzerdefinierten Builder von Kritis Signer zu erstellen.
   • Eine Beispielrichtlinie, die Regeln zum Signieren von Sicherheitslücken enthält.
   • Beispiele für Cloud Build-Konfigurationsdateien. Jede Konfigurationsdatei verwendet Kritis Signer in einer Pipeline zum Scannen auf Sicherheitslücken.

2. Rufen Sie das Verzeichnis kritis/ auf.

   cd kritis
   

3. Ein benutzerdefinierter Builder von Kritis Signer erstellen und registrieren.

   Dieser einmalige Einrichtungsschritt erstellt den benutzerdefinierten Builder von Kritis Signer und registriert ihn bei Cloud Build. Nach der Registrierung steht der benutzerdefinierte Builder zur Verwendung in jeder Cloud Build-Pipeline zur Verfügung.

   gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml
   

Vorhandene Richtlinie ansehen

In diesem Abschnitt wird ein Beispiel für die Kritis-Signer-Richtlinie gezeigt.

Diese Richtlinie konfiguriert Kritis Signer so, dass Artefaktanalyse das Image auf Sicherheitslücken prüft. Nach Abschluss des Scans prüft Kritis Signer die Ergebnisse der Sicherheitslücken anhand der Signaturregeln für Sicherheitslücken in der Richtlinie.

Sie können die Signaturregeln für Sicherheitslücken in dieser Richtlinie bearbeiten, um eine Attestierung zu erstellen, die auf folgenden Elementen basiert:

• Schweregrade erkannter Sicherheitslücken.
• Bestimmte Sicherheitslücken

Sie können auch die Richtlinie so festlegen, dass sie bedingungslos erstellt (ALLOW_ALL) oder keine Attestierung (BLOCK_ALL) erstellen.

Führen Sie den folgenden Befehl aus, um die Kritis-Signer-Richtlinie aufzurufen:

cat samples/signer/policy-strict.yaml

Die Richtlinie sieht in etwa so aus:

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2021-20305

Dabei gilt:

• maximumUnfixableSeverity und maximumFixableSeverity definieren Schwellenwerte für häufige Sicherheitslücken (Common Vulnerabilities and Exposures, CVE), bei denen Kritis Signer Attestierungen erstellt. maximumUnfixableSeverity definiert den Schwellenwert für den Schweregrad, für den eine Lösungist nicht derzeit verfügbar. maximumFixableSeverity definiert den Schwellenwert für den Schweregrad, für den derzeit eine Fehlerkorrektur verfügbar ist. maximumUnfixableSeverity und maximumFixableSeverity können jeweils auf eine der folgenden Schweregrade gesetzt werden:

  • CRITICAL
  • HIGH
  • MEDIUM
  • LOW

  Weitere Informationen zu Schweregraden finden Sie unter Schweregradebenen.

  Alternativ können Sie maximumUnfixableSeverity und maximumFixableSeverity so festlegen:

  • BLOCK_ALL: Die Attestierung wird nicht erstellt, wenn eine Sicherheitslücke identifiziert wird.
  • ALLOW_ALL: Die Attestierung wird immer erstellt.

• allowlistCVEs ist eine Liste bestimmter CVEs, die zugelassen werden sollen. Kritis Signer ignoriert CVEs in dieser Liste bei der Bewertung, ob eine Attestierung erstellt werden soll. Jeder Eintrag in der Zulassungsliste muss genau mit dem Namen des Artefaktanalyse-Hinweis für die CVE-Ressource übereinstimmen. Weitere Informationen zu Artefaktanalyse-Sicherheitslückenquellen. Weitere Informationen zu Hinweisen finden Sie unter Metadatenspeicher.

Cloud KMS-Signaturschlüssel erstellen

Schlüssel des Cloud Key Management Service werden zum Erstellen der Attestierung verwendet.

1. Erstellen Sie einen neuen Cloud KMS-Schlüsselbund mit dem Namen KEY_RING:

   gcloud kms keyrings create KEY_RING \
      --location global
   

2. Erstellen Sie im Schlüsselbund einen neuen Cloud KMS-Schlüssel mit dem Namen KEY_NAME:

   gcloud kms keys create KEY_NAME \
       --keyring KEY_RING \
       --location global \
       --purpose "asymmetric-signing" \
       --default-algorithm "rsa-sign-pkcs1-2048-sha256"
   

3. Speichern Sie den Digest-Algorithmus und Cloud KMS für eine weitere Vorgehensweise in einer Umgebungsvariable:

   export KMS_DIGEST_ALG=SHA256
   export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1
   

Hinweis: Informationen zu anderen Signaturalgorithmen finden Sie unter Asymmetrische Schlüssel erstellen.

Notizname definieren

Alle Attestierungen auf einen Artefaktanalyse-Hinweis verweisen. Kritis Signer erstellt automatisch eine Notiz für einen bestimmten Namen. Sie können auch vorhandene Notiznamen wiederverwenden.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Attestierungen mit Kritis Signer in einer Cloud Build-Pipeline erstellen

In diesem Abschnitt wird gezeigt, wie Sie mit dem benutzerdefinierten Cloud-Krisis-Signer-Builder Cloud Composer-Attestierungen aufgrund von Scans auf Sicherheitslücken erstellen.

In den folgenden Schritten wird gezeigt, wie Kritis Signer mit den Beispiel-Build-Konfigurationsdateien im Kritis-Signer-Repository funktioniert. Jede Beispielkonfigurationsdatei enthält die folgenden Build-Schritte:

1. docker build-Schritt, der ein Docker-Container-Image erstellt.
2. Ein docker push-Schritt, bei dem das neu erstellte Container-Image per Push in Container Registry übertragen wird.

3. Ein vulnsign-Schritt, mit dem das Container-Image geprüft und signiert wird:

   1. Es wird darauf gewartet, dass Artefaktanalyse Suchergebnisse zu Sicherheitslücken im neu erstellten Container-Image zurückgibt.
   2. Ergebnisse mit den Signaturregeln für Sicherheitslücken in der Richtlinie prüfen.
   3. Erstellen der Attestierung, wenn die Ergebnisse den Richtlinien für Sicherheitslücken entsprechen.

Sie senden alle Beispiel-Builds an Cloud Build. Jeder Build erzeugt ein Sicherheitslückenergebnis:

• Fehlerfall: Das Ergebnis der Sicherheitslücke verstößt gegen die Signaturregeln für Sicherheitslücken. Dieser Build schlägt fehl und es wird keine Attestierung erstellt.
• Erfolgsfall: Das Ergebnis der Sicherheitslücke erfüllt die Signaturregeln für Sicherheitslücken. Dieser Build ist erfolgreich und eine Attestierung wird erstellt.

Beispiel-Build für den Fehlerfall senden

In diesem Abschnitt erstellen Sie ein Container-Image und scannen es auf Sicherheitslücken. Der Build schlägt fehl, da das Container-Image auf einem bestimmten Snapshot von Debian 10 basiert, der eine Reihe von Sicherheitslücken mit dem Schweregrad HIGH enthält. Diese Sicherheitslücken verstoßen gegen die Signatur der Sicherheitslückensignatur. Daher erstellt der Builder keine Attestierung.

1. (Optional) Sehen Sie sich die Richtliniendatei zum Signieren von Sicherheitslücken für den Fehlerfall an.

   cat samples/signer/policy-strict.yaml
   

   Hinweis: Diese Build-Konfigurationsdatei enthält auch benutzerdefinierte Substitutionen. Substitutionen sind Variablen, die in der Build-Pipeline verwendet und über den Befehl gcloud builds submit mit dem Parameter --substitutions übergeben werden.

2. Reichen Sie den Build ein:

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-bad.yaml samples/signer
   

   Die Ausgabe sieht in etwa so aus:

   "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"
   

3. Speichern Sie die Build-ID aus dem letzten Build:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Ergebnis prüfen:

    gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

Beispiel-Build für den Erfolgsfall senden

In diesem Abschnitt erstellen Sie ein Container-Image, das Sicherheitslücken enthält, die nicht gegen die Regeln zum Signieren von Sicherheitslücken verstoßen. In diesem Fall erstellt der benutzerdefinierte Builder von Kritis Signer eine Attestierung.

Wichtig: In diesem Beispiel wird die Attestierung erstellt, da die zugehörige Richtlinie zum Signieren von Sicherheitslücken so konfiguriert ist, dass sie nachsichtig ist und nicht aufgrund des Images frei von erheblichen Sicherheitslücken ist. Dieser Ansatz dient nur zur Veranschaulichung und ist nicht für die Produktion geeignet.

So senden Sie den Beispiel-Build für den Erfolgsfall an Cloud Build:

1. (Optional) Rufen Sie für den Erfolgsfall die Richtliniendatei für das Signieren der Sicherheitslücken auf.

   cat samples/signer/policy-loose.yaml
   

   Hinweis: Diese Build-Konfigurationsdatei enthält auch benutzerdefinierte Substitutionen. Substitutionen sind Variablen, die in der Build-Pipeline verwendet und über den Befehl gcloud builds submit mit dem Parameter --substitutions übergeben werden.

2. Reichen Sie den Build ein:

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-good.yaml samples/signer
   

3. Speichern Sie die Build-ID aus dem letzten Build:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Ergebnis prüfen:

   gcloud builds describe $BUILD_ID | grep status
   

Kritis Signer im Prüfmodus verwenden

In diesem Abschnitt erfahren Sie, wie Sie Kritis Signer im check-only-Modus verwenden. In diesem Modus erstellt Kritis Signer keine Attestierung. Es prüft das Image nur auf Sicherheitslücken, bevor der Build-Schritt gemäß den Signaturregeln für Sicherheitslücken erfolgreich ausgeführt wird oder fehlschlägt.

Beispiel-Build für den Fehlerfall senden

1. (Optional) Sehen Sie sich die Richtliniendatei zum Signieren von Sicherheitslücken für den Fehlerfall an.

   cat samples/policy-check/policy-strict.yaml
   

   Beachten Sie im Build-Schritt von Kritis Signer, dass das Flag mode auf check-only gesetzt ist.

2. Reichen Sie den Build ein:

   gcloud builds submit \
     --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check
   

   Beachten Sie, dass der Build fehlschlägt.

3. Speichern Sie die Build-ID aus dem letzten Build:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Ergebnis prüfen:

    gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

Beispiel-Build für den Erfolgsfall senden

1. (Optional) Rufen Sie für den Erfolgsfall die Richtliniendatei für das Signieren der Sicherheitslücken auf.

   cat samples/policy-check/policy-loose.yaml
   

2. Reichen Sie den Build ein:

   gcloud builds submit \
    --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check
   

3. Speichern Sie die Build-ID aus dem letzten Build:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Ergebnis prüfen:

   gcloud builds describe $BUILD_ID | grep status
   

Attestierer erstellen

Wenn Sie eine Richtlinie erstellen möchten, die die Attestierungen erfordert, die Sie mit der in dieser Anleitung beschriebenen Methode erstellen, müssen Sie zuerst einen Attestierer erstellen.

So erstellen Sie einen Attestierer:

1. Rufen Sie das öffentliche Schlüsselmaterial aus dem Cloud KMS-Schlüssel ab, den Sie zuvor in dieser Anleitung erstellt haben:

   gcloud kms keys versions get-public-key 1 \
   --key KEY_NAME \
   --keyring KEY_RING \
   --location global \
   --output-file OUTPUT_PATH
   

   • KEY_NAME: der Schlüsselname
   • KEY_RING ist der Name des Schlüsselbunds.
   • OUTPUT_PATH: ein Dateipfad, z. B. my-key.pem

2. Erstellen Sie einen Attestierer. Verwenden Sie dazu das Material des öffentlichen Schlüssels in der Datei und den Hinweis, den Sie zuvor in dieser Anleitung erstellt haben. Sie können einen Attestierer über die Google Cloud Console oder die gcloud CLI erstellen.

3. Erstellen Sie eine Richtlinie, die Attestierungen erfordert, und geben Sie den Attestierer an, den Sie in diesem Abschnitt erstellt haben. Sie können eine Richtlinie über die Google Cloud Console oder die gcloud CLI erstellen.

Attestierung erstellen

Informationen zum Erstellen einer Attestierung mit Ihrem Attestierer finden Sie unter Attestierung mit Cloud KMS erstellen.

Bereinigen

Um die in diesem Dokument verwendeten Ressourcen zu bereinigen, können Sie das Projekt löschen:

gcloud projects delete ${PROJECT_ID}

Nächste Schritte

• Kritis Signer-Dokumentation auf GitHub
• Übersicht zur Binärautorisierung
• Erstellen Sie Attestierer über die Google Cloud Console oder das Befehlszeilentool.
• Richtlinie konfigurieren, um Attestierungen über die Google Cloud Console oder das Befehlszeilentool anzufordern
• Attestierungen mit Voucher erstellen
• Artefaktanalyse und Scannen auf Sicherheitslücken
• Cloud Build-Community und benutzerdefinierte Cloud-Builder