Referenz zu YAML-Richtlinien

Diese Seite enthält Referenzinformationen zu Richtlinien für die Binärautorisierung im YAML-Format. Wenn Sie eine Richtlinie über die Befehlszeile konfigurieren möchten, bearbeiten Sie dafür eine YAML-formatierte Datei, die dieser Spezifikation entspricht. Beispiele für Richtlinien im YAML-Format finden Sie unter Beispielrichtlinien.

YAML-Richtliniendateien haben folgendes Format:

name: projects/<PROJECT_ID>/policy
admissionWhitelistPatterns:
- namePattern: <MATCHING_PATTERN>
- ...
globalPolicyEvaluationMode: <GLOBAL_EVAL_MODE>
defaultAdmissionRule:
  <ADMISSION_RULE>
clusterAdmissionRules:
  <CLUSTER_SPECIFIER>:
    <ADMISSION_RULE>
  ...

Knoten

Das YAML-Format hat die folgenden Knoten auf der obersten Ebene:

Knoten Beschreibung Erforderlich
name Name der Richtlinie. Ja
admissionWhitelistPatterns Gibt Container-Images an, die immer bereitgestellt werden dürfen. Nein
globalPolicyEvaluationMode Legt fest, ob eine Systemrichtlinie angewendet wird, mit der Systemimages von Google ausgenommen werden. Nein
defaultAdmissionRule Die Regel, die verwendet werden soll, wenn keine bestimmte Regel zutrifft. Ja
clusterAdmissionRules Gibt Regeln an, die für bestimmte Cluster gelten. Nein

name

Der Knoten name enthält den Namen der Richtlinie im folgenden Format:

name: projects/PROJECT_ID/policy

Dabei ist PROJECT_ID der Name Ihres Google Cloud-Projekts, in dem Ihre Richtlinie definiert ist.

Beispiel:

name: projects/example-project/policy

admissionWhitelistPatterns

admissionWhitelistPatterns gibt eine Zulassungsliste der Container-Images an, die von der Richtliniendurchsetzung ausgenommen sind. Sie legen den Pfad zu den Images in Container Registry und Artifact Registry, in einer anderen Registry oder in einer lokalen Referenz im Unterknoten namePattern fest:

admissionWhitelistPatterns:
  - namePattern: MATCHING_PATTERN
  - ...

Ersetzen Sie MATCHING_PATTERN entweder durch einen Pfad zu einem einzelnen Image oder ein Übereinstimmungsmuster mit einem der Platzhaltersymbole (*, **).

Beachten Sie, dass Platzhalter nur am Ende des Musters gültig sind. Beispiel: gcr.io/my-project/nginx* ist ein gültiges Muster, gcr.io/my-project/n*x jedoch nicht. Der Platzhalter * entspricht nur Images im angegebenen Verzeichnis. Beispiel: gcr.io/my-project/nginx* stimmt mit gcr.io/my-project/nginx:latest überein, aber nicht mit gcr.io/my-project/nginx-images/nginx. Der Platzhalter ** gleicht Images in Unterverzeichnissen ab. Der Pfad gcr.io/my-project/nginx** stimmt beispielsweise mit gcr.io/my-project/nginx-1.14.2/image:latest überein.

Das folgende Beispiel fügt Registries mit häufig verwendeten GKE-Images (Google Kubernetes Engine), ein Image unter gcr.io/example-project/helloworld und einen lokalen Verweis auf ein Image zur Liste der ausgenommenen Images für die Richtlinie hinzu:

admissionWhitelistPatterns:
  - namePattern: gcr.io/google-containers/*
  - namePattern: k8s.gcr.io/*
  - namePattern: gke.gcr.io/*
  - namePattern: gcr.io/stackdriver-agents/*
  - namePattern: gcr.io/example-project/helloworld
  - namePattern: loc-ref

Zulassungslistenmuster

So lassen Sie alle Container-Images zu, deren Registry-Speicherort mit dem angegebenen Pfad übereinstimmt:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/*

So lassen Sie ein bestimmtes Image zu:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld

So lassen Sie eine derzeit getaggte Version zu:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld:latest
  - namePattern: gcr.io/example-project/helloworld:my-tag
  - namePattern: gcr.io/example-project/helloworld:v1.*

So lassen Sie eine bestimmte Image-Version anhand ihres Digests zu:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

So lassen Sie Images in Unterverzeichnissen eines bestimmten Pfads zu:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/**

globalPolicyEvaluationMode

Der Auswertungsmodus für Systemrichtlinien ist eine Richtlinieneinstellung, bei der die Binärautorisierung erst eine Systemrichtlinie auswertet, bevor die von Ihnen konfigurierte Richtlinie ausgewertet wird. Die Systemrichtlinie wird von Google bereitgestellt und schließt eine Liste der von Google verwalteten Systemimages von der weiteren Richtlinienauswertung aus. Ist diese Einstellung aktiviert, werden für GKE erforderliche Images durch die Richtlinienerzwingung nicht blockiert. Die Auswertung der Systemrichtlinie erfolgt vor der Auswertung der Nutzerrichtlinien und ergänzend, einschließlich admissionWhitelistPatterns.

Um alle von Google verwalteten Systemimages zuzulassen, legen Sie für das Attribut globalPolicyEvaluationMode den Wert ENABLE fest:

globalPolicyEvaluationMode: ENABLE

So deaktivieren Sie den Auswertungsmodus für Systemrichtlinien:

globalPolicyEvaluationMode: DISABLE

defaultAdmissionRule

defaultAdmissionRule legt die Standardregel für die Richtlinie fest. Die Standardregel definiert die Einschränkungen, die für alle nicht ausgenommenen Container-Images gelten, außer für diejenigen, die eine eigene clusterspezifische Regel haben. Die Standardregel legen Sie mit der Sammlung ADMISSION_RULE fest:

defaultAdmissionRule:
  ADMISSION_RULE

Das folgende Beispiel zeigt eine Standardregel, mit der nur diejenigen Container-Images bereitgestellt werden können, die vom angegebenen Attestierer autorisiert wurden. Für den Fall, dass nicht alle erforderlichen Attestierer das Image autorisiert haben, blockiert die Binärautorisierung das Deployment und schreibt in das Audit-Log.

defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
  - projects/example-project/attestors/secure-build

clusterAdmissionRules

clusterAdmissionRules deklariert clusterspezifische Regeln für die Richtlinie. Die Einschränkungen in diesen Regeln gelten nur für den angegebenen Cluster. Wenn die Binärautorisierung eine clusterspezifische Regel auf ein Deployment anwendet, wird die Standardregel nicht berücksichtigt. Wie bei Standardregeln geben Sie clusterspezifische Regeln mithilfe der Sammlung ADMISSION_RULE an:

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    ADMISSION_RULE

Dabei ist CLUSTER_SPECIFIER die Ressourcen-ID des Clusters, auf den die Regel im Format location.name angewendet wird (z. B. us-east1-a.prod-cluster).

Die folgenden Beispiele zeigen eine clusterspezifische Regel, die nur das Deployment von Container-Images zulässt, die von den angegebenen Attestierern autorisiert wurden:

clusterAdmissionRules:
  us-east1-a.prod-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/example-project/attestors/secure-build
    - projects/example-project/attestors/prod-qualified

Knotensammlungen

ADMISSION_RULE

ADMISSION_RULE ist eine Sammlung von Knoten, die die Einschränkungen für die Regel im folgenden Format angeben:

evaluationMode: EVAL_MODE
enforcementMode: ENFORCEMENT_MODE
requireAttestationsBy:
- ATTESTOR
- ...

Sowohl defaultAdmissionRule als auch clusterAdmissionRule verweisen auf diese Sammlung.

evaluationMode

evaluationMode legt den Vorgang fest, der von der Binärautorisierung ausgeführt wird, um zu ermitteln, ob ein Container-Image bereitgestellt werden soll. Die möglichen Werte sind:

  • ALWAYS_ALLOW: Das Deployment von Images, die von dieser Regel ausgewertet werden, wird immer zugelassen.
  • ALWAYS_DENY: Die Deployment von Images, die von dieser Regel ausgewertet werden, wird immer abgelehnt.
  • REQUIRE_ATTESTATION: Mindestens ein Attestierer ist erforderlich, um den Release vor dem Deployment zu autorisieren.

Wenn für evaluationMode der Wert REQUIRE_ATTESTATION festgelegt ist, müssen Sie in requireAttestationsBy einen Verweis auf die erforderlichen Attestierer angeben.

enforcementMode

enforcementMode legt die Aktion fest, die von der Binärautorisierung ausgeführt wird, wenn ein Container-Image nicht den in der Regel definierten Einschränkungen entspricht. Die möglichen Werte sind:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: Blockiert das Deployment und schreibt in das Audit-Log.
  • DRYRUN_AUDIT_LOG_ONLY: Ermöglicht das Deployment nicht konformer Images und schreibt Details zum Verstoß in das Audit-Log.

Die meisten Produktionsregeln verwenden den Erzwingungsmodus ENFORCED_BLOCK_AND_AUDIT_LOG. Der Modus DRYRUN_AUDIT_LOG_ONLY wird hauptsächlich zum Testen einer Richtlinie in der Umgebung verwendet, bevor sie in Kraft tritt.

requireAttestationsBy

requireAttestationsBy gibt einen oder mehrere Attestierer an, die den Release autorisieren müssen, bevor ein Container-Image bereitgestellt werden kann. Dies ist nur für REQUIRE_ATTESTATION-Regeln erforderlich. Das Format für diesen Knoten lautet:

requireAttestationsBy:
  - projects/PROJECT_ID/attestors/ATTESTOR_NAME
  - ...

Dabei ist PROJECT_ID der Name des Projekts, in dem die Attestierer definiert sind, und ATTESTOR_NAME der Name eines Attestierers, der zum Signieren des Release erforderlich ist.

Das folgende Beispiel zeigt, wie Attestierer angegeben werden:

requireAttestationsBy:
- projects/example-project/attestors/secure-build
- projects/example-project/attestors/prod-qualified