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.

Überblick

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 Container Analysis 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 Container Analysis 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
  • Container Analysis
  • 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.

    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 Container Analysis-Hinweisen hinzu, um den Attestierer zu verwalten
  • containeranalysis.notes.occurrences.viewer: fügt die Rolle Container Analysis-Vorkommen für Hinweise hinzu, um sowohl Sicherheitslücken als auch Attestierungen zu verwalten
  • roles/containeranalysis.occurrences.editor: fügt die Rolle Bearbeiter von Container Analysis-Vorkommen hinzu, um Attestierungen in Container 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:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.occurrences.viewer
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.occurrences.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --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 Container Analysis 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.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
    - projects/goog-vulnz/notes/CVE-2020-10543
    - projects/goog-vulnz/notes/CVE-2020-10878
    - projects/goog-vulnz/notes/CVE-2020-14155
    - projects/goog-vulnz/notes/CVE-2019-25013
    - projects/goog-vulnz/notes/CVE-2021-33574
    - projects/goog-vulnz/notes/CVE-2021-3520

Wobei:

  • 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 Container Analysis-Hinweis für die CVE-Ressource übereinstimmen. Weitere Informationen zu Container Analysis-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 kritis-signer-key-ring:

    gcloud kms keyrings create kritis-signer-key-ring \
       --location global
    
  2. Erstellen Sie im Schlüsselbund einen neuen Cloud KMS-Schlüssel mit dem Namen kritis-signer-key:

    gcloud kms keys create kritis-signer-key \
        --keyring kritis-signer-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/kritis-signer-key-ring/cryptoKeys/kritis-signer-key/cryptoKeyVersions/1
    

Notizname definieren

Alle Attestierungen auf einen Container Analysis-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 Container Analysis 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: Im ersten Build verstößt das Sicherheitslückenergebnis gegen die Richtlinie zur Sicherheitslückensignatur. Dieser Build schlägt fehl.
  • Erfolgsfall: Im zweiten Build erfüllt das Sicherheitslückenergebnis die Signaturregeln für Sicherheitslücken. Dieser Build ist erfolgreich.

Beispiel-Build für den Fehlerfall senden

In diesem Beispiel wird ein Container-Image basierend auf Debian 9 erstellt. Derzeit enthält das Image eine Sicherheitslücke, die gegen die Regeln zur Signatur der Sicherheitslücken verstößt. Der benutzerdefinierte Builder von Kritis Signer erzeugt keine Attestierung.

  1. (Optional) Rufen Sie die Build-Konfigurationsdatei für den Fehlerfall auf.

    cat samples/signer/cloudbuild-bad.yaml
    
  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:

     gsutil 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 Beispiel wird ein Container-Image erstellt, das Sicherheitslücken enthält, die nicht gegen die Regeln zum Signieren von Sicherheitslücken verstoßen. Der benutzerdefinierte Builder von Kritis Signer erstellt eine Attestierung.

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

  1. (Optional) Build-Konfigurationsdatei für den Erfolgsfall ansehen

    cat samples/signer/cloudbuild-good.yaml
    
  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) Rufen Sie die Build-Konfigurationsdatei für den Fehlerfall auf.

    cat samples/policy-check/cloudbuild-bad.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:

     gsutil 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 die Build-Konfigurationsdatei für den Fehlerfall auf.

    cat samples/policy-check/cloudbuild-good.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
    

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