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.

Sichere Lieferkette

Eine Infrastruktur für eine sichere Lieferkette kann die Gültigkeit ihrer Bestandteile beziehungsweise Glieder überprüfen. Es ermöglicht Benutzern und Entwicklern, die Besitzkette ihrer Softwarekomponenten oder Artefakte nachzuweisen. Es ist ein aktiver Ansatz zur Minderung von Sicherheitsproblemen.

Das Sigstore-Projekt bietet Werkzeuge und Infrastruktur dafür. Es dient der Validierung der Integrität der Lieferkette von Artefakten.

Admission Controller verwendet cosign zusammen mit der fulcio und rekor Infrastruktur, die vom Sigstore-Projekt angeboten wird.

Clusterbetreiber können SUSE Security Admission Controller so konfigurieren, dass nur Richtlinien ausgeführt werden, die von vertrauenswürdigen Stellen signiert sind. Richtlinienentwickler können ihre Richtlinien signieren und in einem Register veröffentlichen.

Voraussetzungen

In den folgenden Abschnitten müssen Sie einige Werkzeuge installieren. Diese sind erforderlich, damit Benutzer OCI-Artefaktsignaturen signieren und überprüfen können. Die Beispiele zeigen die Verwendung von cosign und kwctl Dienstprogrammen zum Signieren und Überprüfen von Richtlinien.

Um GitHub zum Signieren von Richtlinien zu verwenden, müssen Sie GitHub Actions installieren.

Keyless Signing verwendet die Standardinstanzen fulcio und rekor, die vom Sigstore-Projekt bereitgestellt werden. Überprüfen Sie die Sigstore-Dokumentation für Details zur Verwendung Ihrer eigenen Infrastruktur dafür, falls erforderlich.

Richtlinien signieren

Admission Controller empfiehlt die Verwendung des cosign Dienstprogramms von Sigstore zum Signieren von Richtlinien. Dieser Abschnitt zeigt eine schlüsselbasierte Methode zum Signieren von Richtlinien. Sie müssen ein Paar aus privatem und öffentlichem Schlüssel generieren. Die generierten Schlüssel helfen zu überprüfen, ob die signierten Artefakte vom erwarteten Benutzer stammen. Um dieses Schlüsselpaar zu generieren, verwenden Sie diesen cosign generate-key-pair Befehl:

cosign generate-key-pair

Was zu einer Eingabeaufforderung führt, um ein Passwort einzugeben und zu bestätigen:

Enter password for private key: ●●●●●●●●
Enter password for private key again: ●●●●●●●●
Private key written to cosign.key
Public key written to cosign.pub

Jetzt können Sie diesen Schlüssel verwenden, um Richtlinien zu signieren.

Teilen Sie die private Schlüsseldatei nicht, cosign.key. Dies ist eine geheime Datei, die nur vom Schlüsselinhaber zum Signieren von Richtlinien verwendet werden darf.

Um eine Richtlinie zu signieren, können Sie cosign sign verwenden und das --key Befehlszeilenargument mit Ihrer privaten Schlüsseldatei mitgeben:

cosign sign --key cosign.key ghcr.io/kubewarden/policies/user-group-psp:latest

Was zu einer Eingabeaufforderung für das Passwort für den angegebenen privaten Schlüssel führt:

an error occurred: no provider found for that key reference, will try to load key from disk...
Enter password for private key: ●●●●●●●●
Pushing signature to: ghcr.io/kubewarden/policies/user-group-psp

Dieser Befehl signiert die Richtlinie, indem er ein neues Signaturobjekt erstellt. Das Signaturobjekt wird dann zusammen mit der Richtlinie in das Registry hochgeladen. Jetzt ist die Richtlinie bereit zur Verwendung in einer Admission Controller-Installation mit Signaturüberprüfung.

Die gleiche Richtlinie kann mehrfach von demselben Benutzer oder von verschiedenen Benutzern signiert werden. Diese Signaturen werden zusammen mit der ursprünglichen Signatur dem Signaturobjekt hinzugefügt.

Für weitere Informationen darüber, wie der Signierungsprozess funktioniert, schauen Sie sich die Dokumentation des Sigstore-Projekts an.

Schlüsselloses Signieren

Oft werden Richtlinien automatisch mit CI/CD-Pipelines erstellt. Dies kompliziert den Prozess der Schlüsselgenerierung. Dieser schlüssellose Workflow von Sigstore ist für diese Situationen. Anstelle von langfristig gültigen Signierschlüsseln verwendet der schlüssellose Workflow Zertifizierungsstellen (CAs) und Zertifikatketten.

Sie verknüpfen den generierten, kurzfristigen Zertifikatschlüssel in eine Vertrauenskette. Dies geschieht durch eine Identitätsherausforderung, um die Identität des Unterzeichners zu bestätigen. Die Lebensdauer des Zertifikatschlüssels ist lang genug, damit die Unterzeichnung erfolgen kann. Die Identitätsherausforderung erfolgt durch Authentifizierung bei einem OpenID Connect (OIDC) Anbieter. Die öffentliche Infrastruktur von Sigstore, Fulcio, stellt die Vertrauenskette bereit.

Die Unterzeichnung erfolgt mit dem Dienstprogramm cosign von Sigstore.

$ cosign sign ghcr.io/kubewarden/policies/user-group-psp:latest
cosign-Ausgabe 
Generating ephemeral keys...
Retrieving signed certificate...
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=<REDACTED>&code_challenge_method=S256&nonce=<REDACTED>&redirect_uri=http%3A%2F%2Flocalhost%3A34021%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=<REDACTED>
client.go:196: root pinning is not supported in Spec 1.0.19
Successfully verified SCT...
tlog entry created with index: 1819248
Pushing signature to: ghcr.io/kubewarden/policies/user-group-psp

Dies unterzeichnet die Richtlinie und schiebt sie in das Repository. Es werden keine Schlüssel als Nebenprodukt generiert.

Wie man Artefakte in GitHub-Workflows signiert

Bei der Verwendung der schlüssellosen Unterzeichnung benötigt cosign in einer GitHub-Aktion nicht, dass der Benutzer sich bei einem OIDC-Anbieter anmeldet. Ein GitHub-Token ist während der Ausführung des GitHub-Workflows verfügbar. Es wird verwendet, um den Benutzer zu authentifizieren und die temporären Schlüssel zu generieren. Der Unterzeichnungsprozess ist derselbe, der im schlüssellosen Modus verwendet wird. Dies ist ein Beispiel dafür, wie das Admission Controller Projekt seine Richtlinien signiert:

YAML, das die Signierung der Admission Controller-Richtlinie beschreibt. 
# ... beginning of the workflow file ...
jobs:
  build:
    name: Build container image
    runs-on: ubuntu-latest
    steps:
      # ... other steps building the container image ...
      -
      name: Login to GitHub Container Registry
      uses: docker/login-action@v1
      with:
        registry: ghcr.io
        username: ${{ github.repository_owner }}
        password: ${{ inputs.GITHUB_TOKEN }}
      -
      name: Publish Wasm policy artifact to OCI registry with the 'latest' tag
      shell: bash
      if: ${{ startsWith(github.ref, 'refs/heads/') }}
      env:
        COSIGN_EXPERIMENTAL: 1
      run: |
        set -ex
        echo Pushing policy to OCI container registry
        IMMUTABLE_REF=$(kwctl push -o json ${{ PATH_TO_BUILT_WASM_FILE }} ghcr.io/myorg/policies/my-great-policy:latest | jq -r .immutable_ref)
        echo Keyless signing of policy using cosign
        cosign sign ${IMMUTABLE_REF}
      # ... other build steps ...

# ... remainder of the workflow file ...

Richtlinienentwickler können die Admission Controller Richtlinienvorlagen verwenden. Sie haben GitHub-Aktionen, um Richtlinien zu erstellen, zu testen, zu signieren und zu veröffentlichen.

Auflistung der Richtlinienunterschriften

Sie können die Signatur in einer veröffentlichten Richtlinie mit kwctl inspect überprüfen. Dies zeigt die Informationen über die Richtlinie und ihre Signaturen wie unten dargestellt:

kwctl inspect registry://ghcr.io/kubewarden/policies/us…​. 
$ kwctl inspect registry://ghcr.io/kubewarden/policies/user-group-psp:v0.2.0
Details
title:              psp-user-group
description:        Short description
author:             José Guilherme Vanz <jguilhermevanz@suse.com>
url:                https://github.com/kubewarden/user-group-psp-policy
source:             https://github.com/kubewarden/user-group-psp-policy
license:            Apache-2.0
mutating:           true
context aware:      false
execution mode:     kubewarden-wapc
protocol version:   1

Annotations
io.kubewarden.kwctl 0.2.5-rc2

Rules
────────────────────
---
- apiGroups:
    - ""
  apiVersions:
    - v1
  resources:
    - pods
  operations:
    - CREATE
────────────────────

Usage
This policy enforce the user and group used in the container.

Sigstore signatures

Digest:                            sha256:026af67682a85d424e7d95db460171635f5c3957d67b53499bece912cc0413cc
Media type:                        application/vnd.dev.cosign.simplesigning.v1+json
Size:                              258
Annotations
dev.sigstore.cosign/certificate    -----BEGIN CERTIFICATE-----
                                   MIIDRzCCAsygAwIBAgITbPUZlUFkkAHtbzc3rzC/3zXj1DAKBggqhkjOPQQDAzAq
                                   MRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxETAPBgNVBAMTCHNpZ3N0b3JlMB4XDTIy
                                   MDIyNTE2MzAwMloXDTIyMDIyNTE2NDAwMVowEzERMA8GA1UEChMIc2lnc3RvcmUw
                                   WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR/O5c6ZI5BzBweoEIam4uWu5fqzHx0
                                   3PTCgfXyyvIjorz9wX08bsndkHdWfFObU+PztbxX78An43Yw9/fHtO93o4IB5jCC
                                   AeIwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMDMAwGA1UdEwEB
                                   /wQCMAAwHQYDVR0OBBYEFCP/v7NEJQglbDmyC5VMgnvhiuBUMB8GA1UdIwQYMBaA
                                   FFjAHl+RRaVmqXrMkKGTItAqxcX6MHgGA1UdEQRxMG+GbWh0dHBzOi8vZ2l0aHVi
                                   LmNvbS9rdWJld2FyZGVuL2dpdGh1Yi1hY3Rpb25zLy5naXRodWIvd29ya2Zsb3dz
                                   L3JldXNhYmxlLXJlbGVhc2UtcG9saWN5LXJ1c3QueW1sQHJlZnMvaGVhZHMvdjEw
                                   NgYKKwYBBAGDvzABAwQoMmJiMGQ4NjZjMzFmOGMyZTQ3NDMxMDI4M2ExNmFkMWFi
                                   NjBlZjA1YjAuBgorBgEEAYO/MAEFBCBrdWJld2FyZGVuL3VzZXItZ3JvdXAtcHNw
                                   LXBvbGljeTAcBgorBgEEAYO/MAEEBA5SZWxlYXNlIHBvbGljeTASBgorBgEEAYO/
                                   MAECBARwdXNoMDkGCisGAQQBg78wAQEEK2h0dHBzOi8vdG9rZW4uYWN0aW9ucy5n
                                   aXRodWJ1c2VyY29udGVudC5jb20wHgYKKwYBBAGDvzABBgQQcmVmcy90YWdzL3Yw
                                   LjIuMDAKBggqhkjOPQQDAwNpADBmAjEAyGQbNCkOifStO7yCCfF8yXyc144ANn2x
                                   Ty92WYC0pTaVhviOED47fgD6TncKf+92AjEAjBfjLmCG/Mwrh8t+gfHJEAWWEc9Q
                                   +j9NR4wF66uABS/TTh5CYlrnIuqSD+GBHGwV
                                   -----END CERTIFICATE-----
dev.sigstore.cosign/timestamp      {"signatures":[{"keyid":"b6710623a30c010738e64c5209d367df1c0a18cf90e6ab5292fb01680f83453d","sig":"3046022100f666a7f4b3d85d8003f2c166e27827dfa0c4ab9282e9dab19485f4e702c61700022100dfe826e0edab5f80a40f08cc87b87777a4db30775d85684fe4950e797f2f565c"}],"signed":{"_type":"timestamp","spec_version":"1.0","version":15,"expires":"2022-03-08T19:14:05Z","meta":{"snapshot.json":{"length":1655,"hashes":{"sha256":"36cf063d0717f6dc03e23027721adcd69b684d293956d3a1a7db7b0848f711d7","sha512":"f90946d0a2dc58dae4505cfb91517a40299adf9e8719f52af187e2025aad69fcdeaeded271ec25db24869841c16fbe24f3fc56f56af8fdbb8808dccec4636b64"},"version":15}}}}
dev.sigstore.cosign/bundle         {"SignedEntryTimestamp":"MEUCIEfu4qR+HsexSDk5h2QXMduvoRCX10J+4CLQWtYw5VD6AiEAyYCEjvJdv2Sr5tZ4LApnddH/4v+CoV1QkuvbCQ3iIUM=","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiIwMjZhZjY3NjgyYTg1ZDQyNGU3ZDk1ZGI0NjAxNzE2MzVmNWMzOTU3ZDY3YjUzNDk5YmVjZTkxMmNjMDQxM2NjIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FWUNJUUNXNWZRZ1BUUTdaTlNuRkhzbHJOTlFrS2dTSVFpOGNSMTU5UEExc0s4VGlRSWhBSndMOWJPcUJKbVduN1lLZG9Tem80c2xPZ2s4SkJCanFYZHNydDNyeVF0QiIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVUlNla05EUVhONVowRjNTVUpCWjBsVVlsQlZXbXhWUm10clFVaDBZbnBqTTNKNlF5OHplbGhxTVVSQlMwSm5aM0ZvYTJwUFVGRlJSRUY2UVhFS1RWSlZkMFYzV1VSV1VWRkxSWGQ0ZW1GWFpIcGtSemw1V2xNMWExcFlXWGhGVkVGUVFtZE9Wa0pCVFZSRFNFNXdXak5PTUdJelNteE5RalJZUkZSSmVRcE5SRWw1VGxSRk1rMTZRWGROYkc5WVJGUkplVTFFU1hsT1ZFVXlUa1JCZDAxV2IzZEZla1ZTVFVFNFIwRXhWVVZEYUUxSll6SnNibU16VW5aamJWVjNDbGRVUVZSQ1oyTnhhR3RxVDFCUlNVSkNaMmR4YUd0cVQxQlJUVUpDZDA1RFFVRlNMMDgxWXpaYVNUVkNla0ozWlc5RlNXRnROSFZYZFRWbWNYcEllREFLTTFCVVEyZG1XSGw1ZGtscWIzSjZPWGRZTURoaWMyNWthMGhrVjJaR1QySlZLMUI2ZEdKNFdEYzRRVzQwTTFsM09TOW1TSFJQT1ROdk5FbENOV3BEUXdwQlpVbDNSR2RaUkZaU01GQkJVVWd2UWtGUlJFRm5aVUZOUWsxSFFURlZaRXBSVVUxTlFXOUhRME56UjBGUlZVWkNkMDFFVFVGM1IwRXhWV1JGZDBWQ0NpOTNVVU5OUVVGM1NGRlpSRlpTTUU5Q1FsbEZSa05RTDNZM1RrVktVV2RzWWtSdGVVTTFWazFuYm5ab2FYVkNWVTFDT0VkQk1WVmtTWGRSV1UxQ1lVRUtSa1pxUVVoc0sxSlNZVlp0Y1ZoeVRXdExSMVJKZEVGeGVHTllOazFJWjBkQk1WVmtSVkZTZUUxSEswZGlWMmd3WkVoQ2VrOXBPSFphTW13d1lVaFdhUXBNYlU1MllsTTVjbVJYU214a01rWjVXa2RXZFV3eVpIQmtSMmd4V1dreGFGa3pVbkJpTWpWNlRIazFibUZZVW05a1YwbDJaREk1ZVdFeVduTmlNMlI2Q2t3elNteGtXRTVvV1cxNGJFeFlTbXhpUjFab1l6SlZkR05IT1hOaFYwNDFURmhLTVdNelVYVmxWekZ6VVVoS2JGcHVUWFpoUjFab1draE5kbVJxUlhjS1RtZFpTMHQzV1VKQ1FVZEVkbnBCUWtGM1VXOU5iVXBwVFVkUk5FNXFXbXBOZWtadFQwZE5lVnBVVVROT1JFMTRUVVJKTkUweVJYaE9iVVpyVFZkR2FRcE9ha0pzV21wQk1WbHFRWFZDWjI5eVFtZEZSVUZaVHk5TlFVVkdRa05DY21SWFNteGtNa1o1V2tkV2RVd3pWbnBhV0VsMFdqTktkbVJZUVhSalNFNTNDa3hZUW5aaVIyeHFaVlJCWTBKbmIzSkNaMFZGUVZsUEwwMUJSVVZDUVRWVFdsZDRiRmxZVG14SlNFSjJZa2RzYW1WVVFWTkNaMjl5UW1kRlJVRlpUeThLVFVGRlEwSkJVbmRrV0U1dlRVUnJSME5wYzBkQlVWRkNaemM0ZDBGUlJVVkxNbWd3WkVoQ2VrOXBPSFprUnpseVdsYzBkVmxYVGpCaFZ6bDFZM2sxYmdwaFdGSnZaRmRLTVdNeVZubFpNamwxWkVkV2RXUkROV3BpTWpCM1NHZFpTMHQzV1VKQ1FVZEVkbnBCUWtKblVWRmpiVlp0WTNrNU1GbFhaSHBNTTFsM0NreHFTWFZOUkVGTFFtZG5jV2hyYWs5UVVWRkVRWGRPY0VGRVFtMUJha1ZCZVVkUllrNURhMDlwWmxOMFR6ZDVRME5tUmpoNVdIbGpNVFEwUVU1dU1uZ0tWSGs1TWxkWlF6QndWR0ZXYUhacFQwVkVORGRtWjBRMlZHNWpTMllyT1RKQmFrVkJha0ptYWt4dFEwY3ZUWGR5YURoMEsyZG1TRXBGUVZkWFJXTTVVUW9yYWpsT1VqUjNSalkyZFVGQ1V5OVVWR2cxUTFsc2NtNUpkWEZUUkN0SFFraEhkMVlLTFMwdExTMUZUa1FnUTBWU1ZFbEdTVU5CVkVVdExTMHRMUW89In19fX0=","integratedTime":1645806604,"logIndex":1506651,"logID":"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"}}
dev.sigstore.cosign/chain          -----BEGIN CERTIFICATE-----
                                   MIIB9zCCAXygAwIBAgIUALZNAPFdxHPwjeDloDwyYChAO/4wCgYIKoZIzj0EAwMw
                                   KjEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MREwDwYDVQQDEwhzaWdzdG9yZTAeFw0y
                                   MTEwMDcxMzU2NTlaFw0zMTEwMDUxMzU2NThaMCoxFTATBgNVBAoTDHNpZ3N0b3Jl
                                   LmRldjERMA8GA1UEAxMIc2lnc3RvcmUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAT7
                                   XeFT4rb3PQGwS4IajtLk3/OlnpgangaBclYpsYBr5i+4ynB07ceb3LP0OIOZdxex
                                   X69c5iVuyJRQ+Hz05yi+UF3uBWAlHpiS5sh0+H2GHE7SXrk1EC5m1Tr19L9gg92j
                                   YzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRY
                                   wB5fkUWlZql6zJChkyLQKsXF+jAfBgNVHSMEGDAWgBRYwB5fkUWlZql6zJChkyLQ
                                   KsXF+jAKBggqhkjOPQQDAwNpADBmAjEAj1nHeXZp+13NWBNa+EDsDP8G1WWg1tCM
                                   WP/WHPqpaVo0jhsweNFZgSs0eE7wYI4qAjEA2WB9ot98sIkoF3vZYdd3/VtWB5b9
                                   TNMea7Ix/stJ5TfcLLeABLE4BNJOsQ4vnBHJ
                                   -----END CERTIFICATE-----
dev.cosignproject.cosign/signature MEYCIQCW5fQgPTQ7ZNSnFHslrNNQkKgSIQi8cR159PA1sK8TiQIhAJwL9bOqBJmWn7YKdoSzo4slOgk8JBBjqXdsrt3ryQtB

Richtlinien überprüfen

Sie können überprüfen, ob eine Richtlinie korrekt signiert ist mit cosign oder kwctl. Sie haben ähnliche Befehlszeilenoptionen zum Überprüfen von Richtliniensignaturen. Um die Signatur-Binärdatei mit einem Schlüssel zu überprüfen, verwenden Sie kwctl wie folgt:

$ kwctl verify -k cosign.pub ghcr.io/kubewarden/policies/user-group-psp:latest
2022-03-29T14:49:31.878180Z  INFO kwctl::verify: Policy successfully verified

Oder cosign :

$ cosign verify --key cosign.pub ghcr.io/kubewarden/policies/user-group-psp:latest

Verification for ghcr.io/kubewarden/policies/user-group-psp:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"ghcr.io/kubewarden/policies/user-group-psp"},"image":{"docker-manifest-digest":"sha256:af520a8ccee03811d426c48634b7007f1220c121cc23e14962bb64510585ce97"},"type":"cosign container image signature"},"optional":null}]

Konfigurieren des Richtliniendienstes zur Überprüfung von Richtliniensignaturen

Sie können Admission Controller mit einem ConfigMap konfigurieren, um nur vertrauenswürdige Richtlinien auszuführen. Die ConfigMap Struktur wird in Signatur-Konfigurationsreferenz beschrieben. Es wird verwendet, um eine Richtlinie mit kwctl zu überprüfen. Die ConfigMap sollte zulässige Konfigurationen im verification-config-Feld definieren.

Zum Beispiel möchten Sie Richtlinien ausführen, die von der Admission Controller GitHub-Organisation signiert sind. Ein Beispiel für ConfigMap in diesem Szenario wäre:

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

# note that the data is stored under verification-config field
$ kubectl  create configmap my-signatures-configuration --from-file=verification-config=kubewarden_signatures.yaml

$ kubectl get configmap -o yaml my-signatures-configuration
apiVersion: v1
data:
  verification-config: |
    apiVersion: v1
    allOf:
      - kind: githubAction
        owner: kubewarden
kind: ConfigMap
metadata:
  creationTimestamp: "2022-03-29T18:27:20Z"
  name: my-signatures-configuration
  namespace: default
  resourceVersion: "10279"
  uid: d53e1c56-1fee-45de-92f5-9bd73b8cead4

Sie können kwctl scaffold verification-config verwenden, um eine Standard-Konfigurationsdatei zur Überprüfung für die ConfigMap zu generieren:

$ kwctl scaffold verification-config > verification_config.yaml
$ cat verification_config.yaml 
$ kwctl scaffold verification-config > verification_config.yaml
$ cat verification_config.yaml
# Default Admission Controller verification config
#
# With this config, the only valid policies are those signed by Admission Controller
# infrastructure.
#
# This config can be saved to its default location (for this OS) with:
#   kwctl scaffold verification-config > /home/kubewarden/.config/kubewarden/verification-config.yml
#
# Providing a config in the default location enables Sigstore verification.
# See https://docs.kubewarden.io for more Sigstore verification options.
---
apiVersion: v1
allOf:
  - kind: githubAction
    owner: kubewarden
    repo: ~
    annotations: ~
anyOf: ~

Sie können dieses verification_config.yml verwenden, um die ConfigMap zu erstellen.

$ kubectl create configmap my-signatures-configuration --from-file==verification_config.yaml
configmap/my-signatures-configuration created

Dann können wir mit get configmap überprüfen.

kubectl get configmap 
$ kubectl get configmap -o yaml my-signatures-configuration
apiVersion: v1
data:
  verification-config: |+
    # Default Admission Controller verification config
    #
    # With this config, the only valid policies are those signed by Admission Controller
    # infrastructure.
    #
    # This config can be saved to its default location (for this OS) with:
    #   kwctl scaffold verification-config > /home/kubewarden/.config/kubewarden/verification-config.yml
    #
    # Providing a config in the default location enables Sigstore verification.
    # See https://docs.kubewarden.io for more Sigstore verification options.
    ---
    apiVersion: v1
    allOf:
      - kind: githubAction
        owner: kubewarden
        repo: ~
        annotations: ~
    anyOf: ~

kind: ConfigMap
metadata:
  creationTimestamp: "2022-04-07T11:54:27Z"
  name: my-signatures-configuration
  namespace: default
  resourceVersion: "1317"
  uid: 74dec846-7fcd-4b4b-8184-700c816f685a

Nachdem Sie die ConfigMap zur Speicherung der Signaturanforderungen erstellt haben, können Sie einen Policy Server konfigurieren. Um die Signaturen der Richtlinien zu validieren, setzen Sie den ConfigMap-Namen im Feld verificationConfig (markiert ➀).

apiVersion: policies.kubewarden.io/v1alpha2
kind: PolicyServer
metadata:
  name: default
  finalizers:
    - kubewarden
spec:
  image: ghcr.io/kubewarden/policy-server:v0.2.7
  serviceAccountName: policy-server
  replicas: 1
//highlight-next-l
  # name of the confimap with the signatures requirements
  verificationConfig: your_configmap (1)
  env:
    - name: KUBEWARDEN_ENABLE_METRICS
      value: "1"
    - name: KUBEWARDEN_LOG_FMT
      value: otlp
    - name: "KUBEWARDEN_LOG_LEVEL"
      value: "info"
1 verificationConfig

Wenn Sie den Standard-Policy Server mit dem kubewarden-defaults Helm-Chart bereitstellen, konfigurieren Sie dieses Feld, indem Sie den ConfigMap-Namen im policyServer.verificationConfig-Wert setzen.

Jetzt lehnt der PolicyServer nicht vertrauenswürdige AdmissionPolicies und ClusterAdmissionPolicies ab, indem er sich weigert zu starten. Sie müssen die nicht vertrauenswürdige Richtlinie entfernen oder die Anforderungen an die Signaturen für einen laufenden PolicyServer ändern.

Referenz zur Signaturkonfiguration

Sie können die in einer Datei enthaltenen Signaturanforderungen validieren. Hier ist ein Beispiel:

Eine Datei mit Signaturanforderungen 
apiVersion: v1

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

anyOf: # at least `+anyOf.minimumMatches+` are required to match (2)
  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
1 allOf
2 anyOf

Signaturvalidierung

Die obige Konfiguration enthält die beiden hervorgehobenen Abschnitte, allOf und anyOf:

  • allOf: die Richtlinie ist nur vertrauenswürdig, wenn alle hier angegebenen Signaturanforderungen gültig sind.

  • anyOf: die Richtlinie ist vertrauenswürdig, wenn das minimumMatches Kriterium erfüllt ist.

Oben ist im minimumMatches Feld 2. Daher müssen mindestens zwei der Signaturanforderungen erfüllt sein. Der Standardwert für das minimumMatches Feld ist 1.

Alle Signaturanforderungen aus allOf und die Mindestanzahl aus anyOf müssen erfüllt sein.

Validierung des öffentlichen Schlüssels

Um zu überprüfen, ob eine Richtlinie mit dem richtigen öffentlichen Schlüssel signiert ist, 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 Feld des Eigentümers ist optional, kann aber nützlich sein, um zu klären, wer den Schlüssel besitzt.

  - 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 zur Verifizierung. Sie können die Richtlinie dennoch mit den OIDC-Daten verifizieren, die während des Signierungsprozesses verwendet wurden. Dafür ist es notwendig, die Signaturvalidierung als genericIssuer zu definieren.

Es ist möglich, Informationen aus der Signatur zu verifizieren:

  • issuer(obligatorisch): Dies entspricht dem Issuer Attribut im Zertifikat, das von Fulcio generiert wurde. Dies zeigt das OIDC, das zur Signierung 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 gegen den 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 vorangestellt werden.

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 erfordert, dass die Richtlinie in GitHub-Aktionen signiert wird, von einem Repository, das dem GitHub-Benutzer flavio gehört:

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

GitHub-Aktionen Signaturverifizierung

Die Art githubAction dient zur Validierung von in GitHub Actions signierten Richtlinien. Das können Sie auch mit der genericIssuer Art 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, denen vertraut werden soll

  • repo: der Name des Repositories, dem vertraut werden soll

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

- kind: githubAction
  owner: flavio

Validierung der 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 Richtliniensignatur von vertrauenswürdigen Benutzern und stammt, die spezifische Annotationen haben.

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

  • dass sie mit einem bestimmten Schlüssel signiert ist

  • dass 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 Überprüfung einer Richtlinie als OCI-Artefakt.

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