Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Dies ist eine unveröffentlichte Dokumentation für Admission Controller 1.34-dev.

Verifikationskonfigurationsformat

Einführung

Sie können das verification-config Format verwenden mit:

policy-server zur Überprüfung der Provenance von Policy-Modulen
verify-image-signatures Richtlinie zur Überprüfung der Provenance von Cluster-Images

Siehe sichere Lieferkette für weitere Informationen.

Format

Die Konfiguration hat 2 Root-Schlüssel:

allOf: Sie sollten alle hier aufgeführten Verifikationsinformationen erfüllen, um Container-Images als signiert zu verifizieren.
anyOf: Sie müssen mindestens anyOf.minimumMatches aller aufgeführten Verifikationsinformationen erfüllen, um ein Container-Image als signiert zu akzeptieren.

Diese beiden Root-Schlüssel akzeptieren ein Array von Schlüsseln des Typs kind. Eine vollständige Liste der akzeptierten Schlüssel basierend auf verschiedenen Anwendungsfällen finden Sie unten:

pubKey: Für Signaturen, die mit traditioneller öffentlicher/privater Schlüssel-Kryptographie durchgeführt werden.
githubAction: Für Signaturen, die mit Sigstore’s schlüssellosem Workflow innerhalb von GitHub Actions durchgeführt werden. Admission Controller überprüft diese Informationen gegen die x509-Zertifikatserweiterung workflow_repository, die durch das OpenID Connect von GitHub erstellt wurde, und nicht nur gegen die issuer und subject. Sie sollten dieses kind verwenden, wenn Sie mit GitHub Actions arbeiten.
genericIssuer: Für Signaturen, die mit Sigstore’s schlüssellosem Workflow durchgeführt werden, bei dem der Benutzer das Zertifikat issuer und subject selbst validieren muss. Es akzeptiert ein subject, das sein kann:
- equal: Der hier übergebene Wert muss genau mit dem subject im Signierungszertifikat übereinstimmen.
- urlPrefix: Der hier übergebene Wert wird mit / nachgestellt, um Tippfehler zu vermeiden, und muss ein Präfix des subject im Signierungszertifikat sein.

Der kind-Schlüssel akzeptiert einen optionalen annotations-Schlüssel mit einer Liste von Schlüssel-Wert-Paaren, die in der Signatur vorhanden sein müssen.

Beispiel

Dies ist ein Beispiel für eine Konfiguration zur Überprüfung von Signaturen mit dem Sigstore-Workflow:

---
apiVersion: v1

allOf:
  - kind: githubAction
    owner: kubewarden   # mandatory
    repo: policy-server # optional
    annotations:  # optional
      env: prod

anyOf: # at least `+anyOf.minimumMatches+` are required to match
  minimumMatches: 2 # default is 1
  signatures:
  - kind: pubKey
    owner: alice # optional
    key: | # mandatory
         -----BEGIN PUBLIC KEY-----
         MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQiTy5S+2JFvVlhUwWPLziM7iTM2j
         byLgh2IjpNQN0Uio/9pZOTP/CsJmXoUNshfpTUHd3OxgHgz/6adtf2nBwQ==
         -----END PUBLIC KEY-----
    annotations:  # optional
      env: prod
  - kind: genericIssuer
    issuer: https://github.com/login/oauth
    subject:
      equal: alice@example.com
  - kind: genericIssuer
    issuer: https://token.actions.githubusercontent.com
    subject:
      equal: https://github.com/bob/app-example/.github/workflows/release.yml@refs/heads/main
    annotations:  # optional
      env: prod
  - kind: genericIssuer
    issuer: https://token.actions.githubusercontent.com
    subject:
      urlPrefix: https://github.com/bob # <- it will be post-fixed with `+/+` for security reasons

Referenz zur Signaturkonfiguration

Sie können die in einer Datei enthaltenen Signaturanforderungen validieren. Klappen Sie auf für ein Beispiel:

Eine Datei mit Signaturanforderungen

apiVersion: v1

allOf:
  - kind: githubAction
    owner: kubewarden   # mandatory
    annotations:
      env: prod

anyOf: # at least `+anyOf.minimumMatches+` are required to match
  minimumMatches: 2 # default is 1
  signatures:
  - kind: pubKey
    owner: flavio # optional
    key: .... # mandatory
    annotations:  # optional
      env: prod
      foo: bar
  - kind: pubKey
    owner: victor # optional
    key: .... # mandatory
  - kind: genericIssuer
    issuer: https://github.com/login/oauth
    subject:
      equal: alice@example.com
  - kind: genericIssuer
    issuer: https://token.actions.githubusercontent.com
    subject:
      equal: https://github.com/flavio/policy-secure-pod-images/.github/workflows/release.yml@refs/heads/main
  - kind: genericIssuer
    issuer: https://token.actions.githubusercontent.com
    subject:
      urlPrefix: https://github.com/flavio/
  - kind: genericIssuer
    issuer: https://token.actions.githubusercontent.com
    subject:
      urlPrefix: https://github.com/kubewarden # <- it will be post-fixed with `+/+` for security reasons
  - kind: githubAction
    owner: flavio   # mandatory
    repo: policy1 # optional
  - kind: pubKey
    owner: alice # optional
    key: .... # mandatory

Signaturvalidierung

Die vorherige Konfiguration enthält die beiden Abschnitte allOf und anyOf:

allOf: Sie vertrauen der Richtlinie nur, wenn alle Signaturanforderungen gültig sind.
anyOf: Sie vertrauen der Richtlinie, wenn das minimumMatches-Kriterium gültig ist.

Im Beispiel ist das minimumMatches-Feld 2. Sie müssen also mindestens zwei der Signaturanforderungen erfüllen. Der Standardwert für das minimumMatches-Feld ist 1.

Für die Signaturvalidierung müssen Sie alle Anforderungen der Signatur aus allOf und der Mindestanzahl aus anyOf erfüllen.

Validierung des öffentlichen Schlüssels

Um zu überprüfen, ob eine Richtlinie die korrekte öffentliche Schlüsselsignatur hat, geben Sie die Schlüsseldaten und den Eigentümer des Schlüssels an. In diesem Beispiel setzen Sie kind auf pubKey und der key hat den öffentlichen Schlüssel. Das Eigentümerfeld ist optional, kann aber nützlich sein, um zu klären, wem der Schlüssel gehört.

  - kind: pubKey
    owner: bob # optional
    key: |
      -----BEGIN PUBLIC KEY-----
      MBFKHFDGHKIJH0CAQYIKoZIzj0DAQcDQgAEX0HFTtCfTtPmkx5p1RbDE6HJSGAVD
      BVDF6SKFSF87AASUspkQsN3FO4iyWodCy5j3o0CdIJD/KJHDJFHDFIu6sA==
      -----END PUBLIC KEY-----

Schlüssellose Signaturvalidierung

Eine im schlüssellosen Modus signierte Richtlinie hat keinen öffentlichen Schlüssel, den Sie überprüfen können. Sie können die Richtlinie weiterhin mit den während des Signierungsprozesses verwendeten OpenID Connect (OIDC)-Daten überprüfen. Dafür ist es notwendig, die Signaturvalidierung als genericIssuer zu definieren.

Es ist möglich, Informationen aus der Signatur zu überprüfen:

issuer(obligatorisch): dies entspricht dem Issuer-Attribut im vom Fulcio generierten Zertifikat. Dies zeigt das OIDC, das zur Unterzeichnung der Richtlinie verwendet wurde.
subject: Feld, das verwendet wird, um das Subject-Attribut im Zertifikat von Fulcio abzugleichen. Das Subject (Fulcio)-Feld enthält den Benutzer, der zur Authentifizierung beim OIDC-Anbieter verwendet wurde. Das Verifizierungsfeld, subject, kann eines von zwei Unterfeldern haben:
- equal: das Subject (Fulcio) aus dem Zertifikat muss gleich dem Wert in der Signaturvalidierung sein;
- urlPrefix: Der Wert des Subject (Fulcio)-Feldes des Zertifikats muss mit dem in der Signaturvalidierung definierten Wert beginnen.

Sowohl das cosign verify als auch das kwctl inspect können Informationen über schlüssellose Signaturen anzeigen.

Zum Beispiel bedeutet diese Konfiguration, dass die Richtlinie eine schlüssellose Signatur von Alice unter Verwendung des GitHub OIDC haben muss:

- kind: genericIssuer
  issuer: https://github.com/login/oauth
  subject:
    equal: alice@example.com

Diese Konfiguration benötigt die Richtlinie, die in GitHub-Aktionen von einem Repository unterzeichnet wurde, das dem GitHub-Benutzer flavio gehört:

- kind: genericIssuer
  issuer: https://token.actions.githubusercontent.com
  subject:
    urlPrefix: https://github.com/flavio

Verifizierung der GitHub-Aktionen-Signatur

Der "Typ", githubAction, dient zur Validierung von in GitHub Actions unterzeichneten Richtlinien. Sie können dies auch mit dem Typ genericIssuer tun. Um den Prozess der Signaturanforderung zu vereinfachen, verwenden Sie zwei zusätzliche Felder für githubAction:

owner (obligatorisch): GitHub-ID des Benutzers oder der Organisation, der vertraut werden soll.
repo: Der Name des Repositories, dem vertraut werden soll.

Zum Beispiel könnte der letzte Ausschnitt, der genericIssuer verwendet, umgeschrieben werden als:

- kind: githubAction
  owner: flavio

Validierung von Signaturannotationen

Alle Signaturtypen können andere optionale Validierungsfelder haben, annotations. Diese Felder sind Schlüssel/Wert-Daten, die während des Signierungsprozesses hinzugefügt werden.

Mit Admission Controller können Sie überprüfen, ob die Signatur der Richtlinie von vertrauenswürdigen Benutzern und spezifische Annotationen hat.

Die nächste Validierung überprüft zwei Bedingungen für die Richtlinie:

dass sie mit einem bestimmten Schlüssel signiert ist
sie eine Annotation für die Produktionsumgebung hat.

- kind: pubKey
  key: |
    -----BEGIN PUBLIC KEY-----
    MBFKHFDGHKIJH0CAQYIKoZIzj0DAQcDQgAEX0HFTtCfTtPmkx5p1RbDE6HJSGAVD
    BVDF6SKFSF87AASUspkQsN3FO4iyWodCy5j3o0CdIJD/KJHDJFHDFIu6sA==
    -----END PUBLIC KEY-----
  annotations:
    environment: production

Verwendung einer Konfigurationsdatei zur Signaturvalidierung, um ein OCI-Artefakt der Richtlinie zu überprüfen

Sie können testen, ob eine Richtlinie die Überprüfung besteht, indem Sie die Konfigurationsdatei für die Überprüfung verwenden. Verwenden Sie das --verification-config-path-Flag des kwctl verify-Befehls.

$ cat signatures_requirements.yaml
apiVersion: v1
allOf:
  - kind: pubKey
    key: |
      -----BEGIN PUBLIC KEY-----
      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE5Q+cN1Jj2S7N05J4AXnqwP2DyzSg
      Mc+raYce2Wthrd30MSgFtoh5ADAkCd/nML2Nx8UD9KBuASRb0gG5jXqgMQ==
      -----END PUBLIC KEY-----

$ kwctl verify --verification-config-path signatures_requirements.yaml ghcr.io/kubewarden/policies/user-group-psp:latest
2022-03-29T17:34:37.847169Z  INFO kwctl::verify: Policy successfully verified

Dieses letzte Beispiel testet, ob eine gegebene Richtlinie von der Admission Controller-Organisation stammt:

$ cat kubewarden_signatures.yaml
apiVersion: v1
allOf:
  - kind: githubAction
    owner: kubewarden

$ kwctl verify --verification-config-path kubewarden_signatures.yaml ghcr.io/kubewarden/policies/user-group-psp:latest
2022-03-29T18:07:39.062292Z  INFO kwctl::verify: Policy successfully verified