Integration von Scannen auf Sicherheitslücken in Kritis Signer

In diesem Leitfaden wird erläutert, wie Sie mithilfe von Kritis Signer Binärautorisierungen anhand von Container Analysis-Sicherheitslücken erstellen.

Übersicht über Kritis Signer

Sicherheitslücken in Software sind Schwachstellen, die entweder zu einem versehentlichen Systemausfall führen oder absichtlich ausgenutzt werden können. Das Verhindern von anfälligen Images bei der Bereitstellung ist ein wichtiger Aspekt der Sicherheit der Lieferkette.

Kritis Signer ist ein Open-Source-Befehlszeilentool, das Attestierungen für Binärautorisierung auf der Grundlage von CI/CD-Pipelinediensten wie etwa das Scannen auf Sicherheitslücken erstellen kann. Sie können Kritis Signer als benutzerdefinierten Cloud Build-Builder verwenden, um Ergebnisse des Scans auf Sicherheitslücken in Container Analysis abzurufen und die Ergebnisse mit einer Sicherheitslückenrichtlinie zu vergleichen, die Sie erhalten. konfigurieren.

Wenn alle identifizierten Sicherheitslücken in den Ergebnissen der Sicherheitslücke den Signaturrichtlinien für Sicherheitslücken entsprechen, erstellt Kritis Signer eine Attestierung der Binärautorisierung für das zugehörige Image.

Wenn eine der gefundenen Sicherheitslücken in den Ergebnissen der Sicherheitslücke gegen die Richtlinie zu Sicherheitslücken verstößt, erstellt Kritis Signer keine Attestierung.

Ohne bestätigte Attestierung wird das Deployment durch die Binärautorisierung verweigert.

Ziele

Themen in diesem Leitfaden:

  1. Kritis Signer als benutzerdefinierten Cloud Build-Builder einrichten.
  2. Sehen Sie sich die Richtlinie zur Sicherheitslückensignatur an.
  3. Führen Sie den benutzerdefinierten Builder von Kritis Signer aus, um Attestierungen basierend auf dem Scannen von Sicherheitslücken zu erstellen.

Kosten

In diesem Leitfaden werden die folgenden Google Cloud-Produkte verwendet. Es können Gebühren anfallen.

  • 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

Dabei ist project-id die ID des Google Cloud-Projekts.

  1. 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)")
    
  2. APIs aktivieren:

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

    gcloud --project=$PROJECT_ID services enable \
      cloudbuild.googleapis.com \
      containerregistry.googleapis.com \
      containeranalysis.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. Kritis-Repository klonen

     git clone --branch signer-v1.0.0 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.
    • Ein Beispiel für eine Sicherheitslückensignatur für Richtlinien.
    • Beispiele für Cloud Build-Konfigurationsdateien. Jede Konfigurationsdatei stellt eine Kriti-Signer-basierte Pipeline zum Scannen auf Sicherheitslücken dar.
  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 --project=$PROJECT_ID builds submit . --config deploy/kritis-signer/cloudbuild.yaml
    

Vorhandene Richtlinie zum Signieren von Sicherheitslücken ansehen

In diesem Abschnitt wird ein Beispiel für die Signaturrichtlinien zum Kritis-Signer-Sicherheitslücken dargestellt.

Kritis Signer prüft die von Container Analysis ermittelte Sicherheitslücken anhand dieser Richtlinie.

Sie können diese Richtlinie bearbeiten, um Folgendes zuzulassen:

  • Zulässige Schweregrade, die mit erkannten Sicherheitslücken in Verbindung stehen, wie in der CVSS-Spezifikation beschrieben.
  • Bestimmte Sicherheitslücken (CVEs).

So rufen Sie die Signaturrichtlinie für die Sicherheitslücken auf:

cat samples/signer/policy.yaml

Das sollte so aussehen:

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

Wobei:

  • maximumUnfixableSeverity und maximumFixableSeverity stehen jeweils für einen der folgenden Typen:

    • CRITICAL: Eine Punktzahl von Critical gemäß der CVSS-Spezifikation
    • HIGH: Eine Punktzahl von High gemäß der CVSS-Spezifikation
    • MEDIUM: Eine Punktzahl von Medium gemäß der CVSS-Spezifikation
    • LOW: Eine Punktzahl von Low gemäß der CVSS-Spezifikation
    • BLOCK_ALL: Die Attestierung wird nicht erstellt, wenn eine Sicherheitslücke identifiziert wird.
    • ALLOW_ALL: Die Attestierung wird auch dann erstellt, wenn Sicherheitslücken erkannt werden.
  • allowlistCVEs ist eine Liste von Sicherheitslücken. Jeder Eintrag muss genau mit dem Notizennamen übereinstimmen.

Cloud KMS-Signaturschlüssel erstellen

Schlüssel des Cloud Key Management Service werden verwendet, um den Attestierer und die Attestierung zu erstellen.

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

    gcloud --project=$PROJECT_ID kms keyrings create my-key-ring-1 \
       --location global
    
  2. Erstellen Sie im Schlüsselbund einen neuen Cloud KMS-Schlüssel mit dem Namen my-signing-key-1:

    gcloud --project=$PROJECT_ID kms keys create my-signing-key-1 \
        --keyring my-key-ring-1 \
        --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/my-key-ring-1/cryptoKeys/my-signing-key-1/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 der Signatur der Sicherheitslückensignatur 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 sollte fehlschlagen.
  • Erfolgsfall: Im zweiten Build sollte das Ergebnis der Sicherheitslücke nicht gegen die Signaturprüfung für Sicherheitslücken verstoßen. Dieser Build sollte erfolgreich sein.

Beispiel-Build für den Fehlerfall senden

In diesem Beispiel wird ein Container-Image basierend auf Debian 9 erstellt. Derzeit hat der Container eine Sicherheitslücke, die gemäß der oben beschriebenen Richtlinie zur Sicherheitslückensignatur nicht zulässig ist. 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 --project=$PROJECT_ID 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 sollte in etwa so aussehen:

    "ERROR: (gcloud.builds.submit) build build-id completed with status "FAILURE"
    
  3. Beachten Sie Build ID in der Build-Ausgabe.

    Legen Sie die Umgebungsvariable $BUILD_ID auf build-id fest:

    export BUILD_ID=build-id
    

    Diese Variable wird im nächsten Schritt verwendet.

  4. Alternativ können Sie die Build-ID Ihres letzten Builds durch Ausführen des folgenden Befehls ermitteln:

    gcloud builds list --limit 1
    

    Die Build-ID ist das erste zurückgegebene Feld. Ändern Sie den Wert --limit, um mehr Builds zu sehen, oder entfernen Sie das Flag, um alle Builds zu sehen.

  5. 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 Richtlinie zum Signieren von Sicherheitslücken verstoßen. Der benutzerdefinierte Builder von Kritis Signer sollte eine Attestierung generieren.

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 --project=$PROJECT_ID 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. Notieren Sie sich die Build-ID und speichern Sie sie in der Umgebungsvariable $BUILD_ID:

    export BUILD_ID=build-id
    
  4. Geben Sie schließlich den folgenden Befehl ein, um das Ergebnis zu prüfen:

    gcloud --project=$PROJECT_ID builds describe $BUILD_ID | grep status
    

Nächste Schritte