Von Policy Controller migrieren

In diesem Dokument wird beschrieben, wie Sie Ihre Zulassungsrichtlinien von Policy Controller migrieren, um das Risiko von Lücken bei der Richtlinienerzwingung zu verringern. Policy Controller wird am 12. November 2026 eingestellt und am 31. Dezember 2027 nicht mehr unterstützt. In Version 1.39 und höher unterstützen Google Kubernetes Engine-Cluster (GKE) Policy Controller nicht.

Sie können die Zulassungsrichtlinien, die Sie mit Policy Controller erzwingen, zu Kubernetes ValidatingAdmissionPolicies oder zu selbstverwaltetem Open Policy Agent (OPA) Gatekeeper migrieren. Die Migration hat keine Auswirkungen auf bereits ausgeführte Arbeitslasten. Policy Controller wertet Anfragen zum Erstellen oder Aktualisieren von Ressourcen aus. Wenn Sie ihn entfernen, werden laufende Arbeitslasten nicht neu gestartet oder geändert.

Dieses Dokument richtet sich an Operatoren und Sicherheitsexperten, die Policy Controller in einer Flotte verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Blockierte Upgrades auf GKE-Version 1.39

Die GKE blockiert Upgrades auf Version 1.39 und höher für Cluster, auf denen Policy Controller installiert ist. Bevor Sie ein Upgrade eines Clusters auf Version 1.39 durchführen, migrieren Sie Ihre Richtlinien und entfernen Sie Policy Controller aus diesem Cluster. Entfernen Sie Policy Controller nicht, nur um das Upgrade vor der Migration Ihrer Richtlinien freizugeben, da der Cluster sonst ohne Richtlinienerzwingung bleibt.

Ersatzfoto(s) auswählen

Bewerten Sie jede Zulassungsrichtlinie in Policy Controller und wählen Sie aus der folgenden Tabelle eine Ersatzoption für diese Richtlinie aus. Sie müssen nicht einen Ersatz für einen gesamten Cluster auswählen. Sie können Optionen im selben Cluster kombinieren, je nachdem, was die einzelnen Richtlinien erfordern:

Vergleich der Ersatzoptionen für Policy Controller
Option Geeignet für Betrieb und Support
ValidatingAdmissionPolicy (empfohlen) Richtlinien, die eine einzelne Ressource prüfen, wenn sie erstellt oder aktualisiert wird. Die meisten Vorlagen in der Policy Controller-Vorlagenbibliothek funktionieren so. ValidatingAdmissionPolicies sind in Kubernetes integriert und in GKE-Version 1.30 und höher ohne zusätzliche Kosten verfügbar. Cloud Customer Care unterstützt ValidatingAdmissionPolicies im Rahmen von GKE.
Pod Security Admission (empfohlen für Pod-Sicherheits-Bundles) Vordefinierte Pod-Sicherheitskontrollen aus dem Bundle pss-baseline-v2022, pss-restricted-v2022 oder psp-v2022. Weitere Informationen finden Sie unter Pod Security Admission für Pod-Sicherheitspakete verwenden. Pod Security Admission ist in Kubernetes integriert und in GKE standardmäßig ohne zusätzliche Kosten aktiviert. Customer Care unterstützt Pod Security Admission als Teil von GKE.
Selbstverwalteter OPA Gatekeeper Richtlinien, die von ValidatingAdmissionPolicies nicht ausgedrückt werden können, z. B. referenzielle Richtlinien, die andere Ressourcen im Cluster lesen, Richtlinien, die Sie in Rego beibehalten möchten, und Audits vorhandener Ressourcen. Sie können Gatekeeper-ConstraintTemplates auch CEL-Regeln (Common Expression Language) hinzufügen, damit Gatekeeper ValidatingAdmissionPolicies für die API-Server-Erzwingung generiert und der Audit-Controller vorhandene Ressourcen prüft. Sie installieren, aktualisieren und betreiben Gatekeeper. Der Kundendienst unterstützt Open-Source-Gatekeeper nicht. Die Gatekeeper-Community bietet Support über GitHub.

Inventarisieren und klassifizieren Sie Ihre Richtlinien

Standardmäßig werden in der Policy Controller-Vorlagenbibliothek alle Vorlagen installiert. Richtlinien-Bundles installieren ihre Einschränkungen mit der Maßnahme dryrun. Daher entsprechen die Vorlagen und Einschränkungen in einem Cluster nicht unbedingt den Richtlinien, die Sie erzwingen. So finden Sie heraus, was Sie erzwingen:

  1. Identifizieren Sie die Cluster in Ihrer Flotte, auf denen Policy Controller ausgeführt wird:

    gcloud container fleet policycontroller describe \
    --project=PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID des Flotten-Hostprojekts.

  2. Listen Sie für jeden identifizierten Cluster die Einschränkungen auf:

    kubectl get constraints \
    -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'

    Die Ausgabe zeigt die Maßnahme für jede Einschränkung, die Anzahl der Verstöße aus der letzten Prüfung und alle Bundles, die sie installiert haben. Für eine Einschränkung, die keinen Wert in der Spalte ACTION hat, wird die Standard-Maßnahme deny verwendet.

  3. Sichern Sie Ihre ConstraintTemplates und Einschränkungen in separaten Dateien:

    kubectl get constrainttemplates -o yaml \
    > policy-controller-templates-backup.yaml
kubectl get constraints -o yaml \
    > policy-controller-constraints-backup.yaml

  4. Optional: Führen Sie die folgenden zusätzlichen Sicherungsvorgänge aus:

    • Wenn Sie referenzielle Regeln in Policy Controller aktiviert haben, sichern Sie Ihre Synchronisierungskonfiguration:

      kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
    > policy-controller-config-backup.yaml

    • Wenn Sie die Mutation im Policy Controller aktiviert haben, sichern Sie Ihre Mutatoren:

      kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
    > policy-controller-mutators-backup.yaml

Bewahren Sie diese Sicherungsdateien an einem sicheren Ort auf. Wenn Sie Policy Controller entfernen, werden alle ConstraintTemplates, Einschränkungen, Synchronisierungskonfigurationen und Mutatoren im Cluster gelöscht, einschließlich der von Ihnen erstellten. Sie benötigen die Sicherungen, um Ihre Richtlinien zu übersetzen oder neu zu erstellen.

Nachdem Sie Ihre Richtlinien gesichert haben, bestimmen Sie den Migrationspfad für jede Einschränkung. Prüfen Sie dazu den Einschränkungstyp in der folgenden Tabelle:

Migrationspfade nach Einschränkungstyp
Einschränkungstyp Migrationspfad
Einschränkung für einzelne Ressourcen Wenn eine Einschränkung Felder nur für die eingehende Ressource auswertet, ohne data.inventory zu lesen oder zu einem Pod-Sicherheits-Bundle zu gehören, verwenden Sie eine ValidatingAdmissionPolicy.
Nicht erzwungene dryrun-Einschränkung Wenn eine Einschränkung die dryrun Maßnahme verwendet und Sie nicht vorhaben, sie zu erzwingen, löschen Sie die Einschränkung.
Einschränkung für Pod-Sicherheits-Bundle Wenn eine Einschränkung aus dem Bundle pss-baseline-v2022, pss-restricted-v2022 oder psp-v2022 stammt, verwenden Sie Pod Security Admission. Verwenden Sie ValidatingAdmissionPolicies für alle Kontrollen, die nicht von Pod Security Admission abgedeckt werden.
Referenzielle Einschränkung Wenn eine Einschränkung eine referenzielle Vorlage verwendet, die andere Ressourcen im Cluster liest, verwenden Sie den selbstverwalteten Gatekeeper. Wenn Sie referenzielle Vorlagen finden möchten, suchen Sie in Ihrer Sicherungsdatei nach der Referenz data.inventory.
Cloud Service Mesh-, Istio- oder Google Cloud-Einschränkung Prüfen Sie die Einschränkung einzeln, um festzustellen, ob ein integriertes GKE-Feature die Richtlinie ersetzt oder ob die ConstraintTemplate in Ihrer Sicherungsdatei data.inventory lautet. Die meisten dieser Vorlagen prüfen nur die eingehende Ressource und funktionieren in ValidatingAdmissionPolicies, mit Ausnahme der referenziellen Vorlagen AsmAuthzPolicyDefaultDeny und AsmPeerAuthnMeshStrictMtls, für die ein selbstverwalteter Gatekeeper erforderlich ist. Aktivieren Sie für integrierte Ersetzungen die Binärautorisierung, anstatt die ConstraintTemplate K8sRequireBinAuthZ zu verwenden, und konfigurieren Sie das Knoten-Image Ihrer Knotenpools, anstatt die ConstraintTemplate K8sRequireCosNodeImage zu verwenden.

Zu ValidatingAdmissionPolicy migrieren

Eine ValidatingAdmissionPolicy enthält die Richtlinienlogik, ähnlich wie ein ConstraintTemplate. Mit einer ValidatingAdmissionPolicyBinding wird die Richtlinie wie eine Einschränkung angewendet. Eine ValidatingAdmissionPolicy verwendet CEL-Ausdrücke anstelle von Rego und der API-Server wertet die Ausdrücke direkt ohne Webhook aus.

Beispiel: Zulässige Image-Repositories

Die folgende Policy Controller-Einschränkung erfordert, dass Pods Images aus einem Artifact Registry-Repository verwenden. Der Namespace kube-system wird ausgeschlossen:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

Mit der folgenden ValidatingAdmissionPolicy und ValidatingAdmissionPolicyBinding wird dieselbe Regel erzwungen. Die ValidatingAdmissionPolicyBinding verwendet die Aktionen Warn und Audit, damit Sie die Ergebnisse vergleichen können, bevor Sie die ValidatingAdmissionPolicy erzwingen:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

In diesem Beispiel enthält die Variable repos den Wert aus dem Feld parameters der Einschränkung. Der Validierungsausdruck gibt für Pods, die der ValidatingAdmissionPolicy entsprechen, den Wert true zurück. Das ist das Gegenteil einer Rego-Verstoßregel. Wenn Sie eine ValidatingAdmissionPolicy für mehrere ValidatingAdmissionPolicyBindings wiederverwenden möchten, die unterschiedliche Werte bereitstellen, verwenden Sie eine Parameterressource anstelle einer Variablen. Weitere Informationen zu Parameterressourcen finden Sie in der Kubernetes-Dokumentation unter Parameterressourcen.

In der folgenden Tabelle sehen Sie, wie Einschränkungsfelder den Feldern „ValidatingAdmissionPolicy“ und „ValidatingAdmissionPolicyBinding“ zugeordnet werden:

Zuordnung von Policy Controller-Einschränkungsfeldern zu ValidatingAdmissionPolicy- und ValidatingAdmissionPolicyBinding-Feldern
Einschränkungsfeld Feld „ValidatingAdmissionPolicy“ oder „ValidatingAdmissionPolicyBinding“
spec.enforcementAction Das Feld validationActions in der ValidatingAdmissionPolicyBinding, das die Aktionen deny, warn und dryrun den Werten ["Deny"], ["Warn"] und ["Audit"] zuordnet
spec.parameters Das Feld variables in der ValidatingAdmissionPolicy oder eine Parameterressource, auf die die ValidatingAdmissionPolicyBinding im Feld paramRef verweist
spec.match.kinds Das Feld matchConstraints.resourceRules in der ValidatingAdmissionPolicy, das API-Gruppen und Ressourcennamen wie die Ressource pods anstelle von Arten verwendet
spec.match.namespaces und spec.match.excludedNamespaces Das Feld matchResources.namespaceSelector in der ValidatingAdmissionPolicyBinding mit dem Operator In oder NotIn für das Label kubernetes.io/metadata.name
spec.match.labelSelector Das Feld matchResources.objectSelector in der ValidatingAdmissionPolicyBinding
spec.match.namespaceSelector Das Feld matchResources.namespaceSelector in der ValidatingAdmissionPolicyBinding
spec.match.scope Das Feld scope jeder Ressourcenregel

Weitere Informationen zum Schreiben von Ausdrücken finden Sie in der Kubernetes-Dokumentation unter CEL in Kubernetes.

Richtlinien mit Policy Controller testen

Wenn Sie eine Einschränkung ohne Lücke bei der Erzwingung ersetzen möchten, führen Sie die ValidatingAdmissionPolicy neben der Einschränkung aus, bevor Sie die ValidatingAdmissionPolicy erzwingen:

  1. Wenden Sie die ValidatingAdmissionPolicy und eine ValidatingAdmissionPolicyBinding mit der Einstellung validationActions: ["Warn", "Audit"] an. Lassen Sie die Policy Controller-Einschränkung unverändert.
  2. Vergleichen Sie die Ergebnisse mithilfe der Audit-Log-Abfrage unter Verstoßberichte ersetzen. Wenn die ValidatingAdmissionPolicy Anfragen kennzeichnet, die Policy Controller zulässt, oder umgekehrt, korrigieren Sie die ValidatingAdmissionPolicy. Verlassen Sie sich bei ValidatingAdmissionPolicies, die mit Pods übereinstimmen, nicht auf Warnungen. Controller erstellen die Pods für Deployments und andere Arbeitslasten, sodass der Controller die Warnung erhält.
  3. Wenn die Ergebnisse übereinstimmen, ändern Sie die ValidatingAdmissionPolicyBinding, um die Einstellung validationActions: ["Deny"] zu verwenden.
  4. Löschen Sie die Policy Controller-Einschränkung.

Verhaltensunterschiede einplanen

ValidatingAdmissionPolicies verhalten sich in folgenden Punkten anders als Policy Controller, was dazu führen kann, dass Anfragen blockiert werden oder Lücken bei der Durchsetzung entstehen:

  • Fehlerrichtlinie: Der Policy Controller-Webhook wird nicht geöffnet. Das bedeutet, dass der API-Server eine Anfrage zulässt, wenn Policy Controller nicht antwortet. Eine ValidatingAdmissionPolicy mit der Einstellung failurePolicy: Fail lehnt eine Anfrage ab, wenn ein Ausdruck einen Fehler zurückgibt oder das CEL-Kostenlimit überschreitet. Die ValidatingAdmissionPolicy lehnt eine Anfrage auch ab, wenn eine referenzierte Parameterressource nicht vorhanden ist und der Wert des Felds paramRef.parameterNotFoundAction in der ValidatingAdmissionPolicyBinding Deny ist. Wenn der Wert Allow ist, überspringt der API-Server eine fehlende Parameterressource unabhängig von der Einstellung failurePolicy. Testen Sie jede ValidatingAdmissionPolicy und wählen Sie Werte für beide Felder aus.
  • Fehlende Felder: Rego behandelt ein fehlendes Feld nicht als Verstoß, CEL gibt jedoch einen Fehler zurück. Bevor Sie ein optionales Feld lesen, prüfen Sie mit dem Makro has(), ob das Feld vorhanden ist.
  • Ausnahmen: Eine ValidatingAdmissionPolicy nimmt standardmäßig keine Namespaces aus und verwendet nicht das Label admission.gatekeeper.sh/ignore. In GKE Standard-Clustern gilt eine ValidatingAdmissionPolicyBinding für jeden Namespace im Cluster, einschließlich System-Namespaces wie dem Namespace kube-system, sofern Sie sie nicht im Feld matchResources.namespaceSelector der ValidatingAdmissionPolicyBinding oder in den Feldern matchConstraints.namespaceSelector oder matchConditions der ValidatingAdmissionPolicy ausschließen. In Autopilot-Clustern schließt GKE verwaltete Namespaces automatisch aus und lehnt ValidatingAdmissionPolicies ab, die mit den Ressourcen nodes, persistentVolumes, certificatesigningrequests oder tokenreviews übereinstimmen. Weitere Informationen finden Sie unter Sicherheitsmaßnahmen in GKE Autopilot.
  • Unterressourcen: Policy Controller prüft Pod-Updates, die sitzungsspezifische Container hinzufügen. Wenn Sie diese Abdeckung beibehalten möchten, fügen Sie die Unterressource pods/ephemeralcontainers in Ihre Ressourcenregeln ein, wie im Beispiel gezeigt.
  • Keine Prüfung vorhandener Ressourcen: Eine ValidatingAdmissionPolicy wertet nur eingehende API-Serveranfragen aus. Vorhandene Ressourcen, die gegen eine ValidatingAdmissionPolicy verstoßen, werden nicht gemeldet.
  • Eine Nachricht pro Anfrage: Eine ValidatingAdmissionPolicy meldet die erste fehlgeschlagene Validierung, nicht jeden Verstoß.

Pod Security Admission für Pod-Sicherheits-Bundles verwenden

Wenn Sie die Bundles pss-baseline-v2022 oder pss-restricted-v2022 verwenden, ersetzen Sie das Bundle durch Pod Security Admission, anstatt jede Einschränkung zu übersetzen. Pod Security Admission verwendet den integrierten Kubernetes-PodSecurity-Admission-Controller, um vordefinierte Regeln aus den Kubernetes-Pod-Sicherheitsstandards basierend auf Namespace-Labels zu erzwingen. Das pss-baseline-v2022-Bundle entspricht der baseline-Ebene und das pss-restricted-v2022-Bundle der restricted-Ebene.

Pod Security Admission deckt nicht alle Steuerelemente im psp-v2022-Bundle ab, z. B. Zulassungslisten für Hostpfade, Nutzer, Funktionen und sysctls. Verwenden Sie für diese Kontrollen ValidatingAdmissionPolicies. Pod Security Admission kann auch keine bestimmten Images ausnehmen, wie z. B. Policy Controller-Einschränkungen, die den Parameter exemptImages verwenden. Die GKE unterstützt die Konfiguration von Ausnahmen für die Pod-Sicherheits-Zulassung nicht. Wenn Sie Ausnahmen benötigen, verwenden Sie ValidatingAdmissionPolicies für die betroffenen Richtlinien.

Weitere Informationen zum Konfigurieren von Pod Security Admission finden Sie unter Vordefinierte Sicherheitsrichtlinien auf Pod-Ebene mit PodSecurity anwenden.

Zu selbstverwaltetem OPA Gatekeeper migrieren

Wählen Sie Gatekeeper für die Richtlinien aus, die ValidatingAdmissionPolicies nicht ausdrücken kann. Policy Controller basiert auf Gatekeeper. Daher verwenden Ihre ConstraintTemplates und Einschränkungen dieselben APIs in Gatekeeper. Alle Vorlagen in der Policy Controller-Vorlagenbibliothek funktionieren in Gatekeeper ohne Änderungen an ihrer Logik. Gatekeeper verwendet jedoch eine neuere Rego-Engine und eine strengere Validierung, die eine benutzerdefinierte ConstraintTemplate ablehnen kann.

Wenn Sie einen selbstverwalteten Gatekeeper verwenden, sind Sie für die Aufgaben verantwortlich, dieGoogle Cloud für Policy Controller ausführt, z. B. die Installation, das Upgrade, die Skalierung und das Monitoring von Gatekeeper in jedem Cluster. Cloud Customer Care unterstützt den Open-Source-Gatekeeper nicht. Hilfe erhalten Sie über den Gatekeeper GitHub Issue Tracker.

Gatekeeper enthält nicht die Policy Controller-Vorlagenbibliothek oder Richtlinien-Bundles. Ihre Sicherungsdateien enthalten die ConstraintTemplates und Einschränkungen aus Ihren Clustern. Für Vorlagen, die aus der Open-Source-Gatekeeper-Bibliothek stammen, können Sie die Vorlagen in der Gatekeeper-Richtlinienbibliothek verwenden. Die Vorlagennamen bleiben gleich, aber Parameter und Nachrichten können sich zwischen den Versionen unterscheiden.

So verschieben Sie Richtlinien zu Gatekeeper:

  1. Optional: Wenn Sie keine Lücke bei der Durchsetzung akzeptieren können, während Sie Policy Controller ersetzen, migrieren Sie zuerst Ihre wichtigsten Richtlinien zu ValidatingAdmissionPolicies. Achten Sie darauf, dass diese ValidatingAdmissionPolicyBindings den Namespace gatekeeper-system ausschließen, damit die Gatekeeper-Installationsjobs nicht blockiert werden. Nachdem Sie Policy Controller entfernt haben, werden Gatekeeper-Richtlinien in Ihrem Cluster erst wieder erzwungen, wenn Sie die entsprechenden Gatekeeper-Einschränkungen anwenden. ValidatingAdmissionPolicies werden weiterhin erzwungen, da sie nicht von Policy Controller oder Gatekeeper abhängen.

  2. Wenn Sie benutzerdefinierte ConstraintTemplates verwenden, testen Sie jedes benutzerdefinierte Vorlagenmanifest mit dem gator-Befehlszeilentool der Gatekeeper-Version, die Sie installieren möchten:

    gator test --filename=TEMPLATE_FILE

    Ersetzen Sie TEMPLATE_FILE durch den Pfad zur Manifestdatei „ConstraintTemplate“. Bevor Sie Policy Controller entfernen, müssen Sie alle benutzerdefinierten ConstraintTemplates korrigieren, die von Gatekeeper abgelehnt werden.

  3. Wenn Sie Einschränkungen mit einem GitOps-Tool aus einem Git-Repository bereitstellen, bereiten Sie die ConstraintTemplates vor, die von Ihren Einschränkungen verwendet werden, und fügen Sie sie dem Repository hinzu, wenn Sie Gatekeeper installieren. Andernfalls können Ihre Einschränkungen nach dem Entfernen von Policy Controller nicht mehr angewendet werden, da die zugehörigen ConstraintTemplates nicht mehr vorhanden sind.

  4. Entfernen Sie Policy Controller, indem Sie die Schritte unter Policy Controller entfernen ausführen. Installieren Sie Gatekeeper nicht auf einem Cluster, auf dem Policy Controller noch ausgeführt wird. Beide verwenden den Namespace gatekeeper-system, dieselben CustomResourceDefinitions und dieselben Webhook-Namen.

  5. Installieren Sie Gatekeeper mit Helm und verwenden Sie die Einstellungen, die Sie in der Tabelle im nächsten Abschnitt Gatekeeper-Einstellungen, die sich von Policy Controller unterscheiden auswählen. Weitere Informationen zur Installation von Gatekeeper finden Sie in der Gatekeeper-Dokumentation unter Installation.

    In Autopilot-Clustern schlägt die Standardinstallation des Helm-Diagramms fehl, da GKE Platzhalterregeln in mutierenden Webhooks ablehnt. Legen Sie den Helm-Wert disableMutation: true fest oder legen Sie den Helm-Wert mutatingWebhookCustomRules fest, um nur die spezifischen Ressourcen aufzulisten, auf die Ihre Mutatoren abzielen. Geben Sie nicht die Ressourcen nodes, persistentvolumes, certificatesigningrequests oder tokenreviews an.

  6. Entfernen Sie in Ihren Sicherungsdateien die folgenden Felder, Labels und Annotationen aus jeder Ressource, die Sie neu anwenden möchten:

    • Das Feld status.
    • Die Felder resourceVersion, uid, creationTimestamp, generation, managedFields und ownerReferences im Abschnitt metadata.
    • Die Annotation kubectl.kubernetes.io/last-applied-configuration.
    • Das Label app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Wenn Policy Controller im Cluster wieder aktiviert wird, z. B. durch eine Standardkonfiguration auf Flottenebene, werden Ressourcen mit diesem Label verwaltet und können geändert oder gelöscht werden.
    • Labels und Annotationen, deren Schlüssel das Präfix policycontroller. haben.

  7. Wenden Sie die ConstraintTemplates an, die von Ihren Einschränkungen verwendet werden, und prüfen Sie dann, ob Gatekeeper für jede Vorlage eine CustomResourceDefinition erstellt hat:

    kubectl get constrainttemplates \
    -o custom-columns='NAME:.metadata.name,CREATED:.status.created'

    Wenn für jede Vorlage in der Spalte CREATED der Wert true angezeigt wird, wenden Sie Ihre Einschränkungen an.

Gatekeeper-Einstellungen, die sich von Policy Controller unterscheiden

Prüfen Sie vor der Installation von Gatekeeper die Einstellungen in der folgenden Tabelle, in der sich die Gatekeeper-Helm-Diagramm-Standardwerte von Policy Controller unterscheiden:

Vergleich der Policy Controller-Standardwerte und der Gatekeeper-Helm-Diagramm-Standardwerte
Einstellung Policy Controller-Standard Gatekeeper-Helm-Diagramm-Standard Empfehlung
Mutation Deaktiviert, sofern Sie die Funktion nicht aktiviert haben An Wenn Sie keine Mutation verwenden, legen Sie den Helm-Wert disableMutation: true fest. In Autopilot-Clustern müssen Sie entweder den Helm-Wert disableMutation: true festlegen oder den Helm-Wert mutatingWebhookCustomRules ohne Platzhalter oder eingeschränkte Ressourcen konfigurieren. Wenn Sie keinen dieser Werte angeben, lehnt die GKE die Installation ab.
Ausgenommene Namespaces Der Namespace gatekeeper-system und die Namespaces in Ihrer exemptableNamespaces-Liste Der Namespace, in dem Gatekeeper installiert ist Fügen Sie Ihre ausgenommenen Namespaces dem Helm-Wert controllerManager.exemptNamespaces hinzu. Gatekeeper lehnt Änderungen an Namespaces mit dem Label admission.gatekeeper.sh/ignore ab, es sei denn, diese Namespaces sind ausgenommen.
Referenzdaten Automatisch synchronisiert für referenzielle Bundles Nicht synchronisiert Erstellen Sie eine Gatekeeper-Konfiguration oder ein SyncSet, in dem die Arten aufgeführt sind, die von Ihren referenziellen Vorlagen gelesen werden. Bis diese Arten mit dem data.inventory-Objekt synchronisiert sind, lassen Konfliktprüfungen verletzende Anfragen zu und Existenzprüfungen wie die ConstraintTemplate K8sRequireNamespaceNetworkPolicies lehnen jede Anfrage mit Übereinstimmung ab, auch wenn die erforderliche Ressource vorhanden ist.
ValidatingAdmissionPolicy-Generierung Nicht verfügbar Aktiviert für Vorlagen, die CEL-Code enthalten Policy Controller-Vorlagen enthalten nur Rego. Gatekeeper generiert ValidatingAdmissionPolicies also nur, wenn Sie Ihren ConstraintTemplates CEL hinzufügen. Wenn Sie die Erzwingung im Webhook beibehalten möchten, legen Sie die Helm-Werte defaultCreateVAPForTemplates: false und defaultCreateVAPBindingForConstraints: false fest. Weitere Informationen finden Sie in der Gatekeeper-Dokumentation unter Integration in die Kubernetes-Validierungsrichtlinie für die Zulassung.
Replikate und Ressourcen Ein Replikat für jede Komponente mit einem Arbeitsspeicherlimit von 1.024 MiB Drei Webhook-Replikate mit unterschiedlichen Ressourcenlimits Konfigurieren Sie die Anzahl der Replikate und die Ressourcenlimits basierend auf Ihrer aktuellen Nutzung.
Bilder Aus einer von Google verwalteten Registry abgerufen Aus Docker Hub abgerufen (die Images openpolicyagent/gatekeeper, openpolicyagent/gatekeeper-crds und curlimages/curl) Spiegeln Sie für private Cluster oder Cluster, die die Binärautorisierung erzwingen, alle drei Images in Artifact Registry und überschreiben Sie ihre Image-Werte im Diagramm. Wenn Sie das Image curlimages/curl nicht spiegeln, deaktivieren Sie den Webhook-Prüfjob.

Standardmäßig stellt Gatekeeper nur Prometheus-Messwerte bereit. Die Messwertnamen unterscheiden sich von den Namen, die Policy Controller an Cloud Monitoring sendet. Aktualisieren Sie alle Dashboards und Benachrichtigungen, die Policy Controller-Messwerte verwenden.

Mutationsrichtlinien migrieren

Wenn Sie die Mutation im Policy Controller aktiviert haben, listen Sie Ihre Mutatoren auf:

kubectl get assign,assignmetadata,assignimage,modifyset

Wählen Sie für jeden Mutator eine der folgenden Optionen aus:

  • MutatingAdmissionPolicy: Sie können eine MutatingAdmissionPolicy in GKE-Version 1.36 und höher verwenden. Wie eine ValidatingAdmissionPolicy verwendet eine MutatingAdmissionPolicy CEL-Ausdrücke und wird ohne Webhook auf dem API-Server ausgeführt. Kubernetes führt alle MutatingAdmissionPolicies vor ValidatingAdmissionPolicies aus. Testen Sie sie daher zusammen, um sicherzustellen, dass eine Mutation nicht dazu führt, dass eine ValidatingAdmissionPolicy ein gültiges Manifest ablehnt. In Autopilot-Clustern schließt die GKE verwaltete Namespaces von MutatingAdmissionPolicies aus. Weitere Informationen zu Mutating Policies finden Sie in der Kubernetes-Dokumentation unter Mutating Admission Policy.
  • Selbstverwalteter Gatekeeper: In Standardclustern funktionieren Ihre Mutatoren ohne Änderungen, da Gatekeeper die Mutation standardmäßig aktiviert. In Autopilot-Clustern müssen Sie den Helm-Wert mutatingWebhookCustomRules im Gatekeeper-Diagramm festlegen, um die spezifischen Ressourcen aufzulisten, auf die Ihre Mutatoren abzielen, anstatt Platzhalterregeln zu verwenden. Weitere Informationen finden Sie unter Sicherheitsmaßnahmen in GKE Autopilot. Nachdem Sie Gatekeeper installiert haben, entfernen Sie die Policy Controller-Metadaten aus der Sicherungsdatei des Mutators und wenden Sie die Mutatoren wie bei Einschränkungen noch einmal an.

Richtlinienprüfungen in Build-Pipelines aktualisieren

Ihre Build-Pipeline kann Manifeste vor der Bereitstellung mit Ihren Policy Controller-Einschränkungen abgleichen. Die Pipeline kann beispielsweise die Funktion gatekeeper in kpt oder das gator-Befehlszeilentool verwenden. Weitere Informationen finden Sie unter Anwendungen anhand von Unternehmensrichtlinien in einer CI-Pipeline validieren.

Wenn Ihre Pipeline Manifeste prüft, aktualisieren Sie sie für den Ersatz:

  • Wenn Sie Gatekeeper verwenden, können Sie Ihre Pipeline beibehalten. Aktualisieren Sie die Datei- oder Verzeichnispfade in Ihrem gator- oder kpt-Befehl, um auf das Repository oder Verzeichnis zu verweisen, das Ihre bereinigten Gatekeeper-ConstraintTemplate- und Constraint-Manifeste enthält.

  • Wenn Sie ValidatingAdmissionPolicies verwenden, werden Ihre Richtlinien von diesen Tools nicht ausgewertet. Führen Sie stattdessen einen serverseitigen Probelauf für einen Testcluster aus, der Ihre ValidatingAdmissionPolicies und ValidatingAdmissionPolicyBindings mit der Aktion Deny enthält:

    kubectl apply --dry-run=server -f MANIFEST_DIRECTORY

    Ersetzen Sie MANIFEST_DIRECTORY durch das Verzeichnis, das Ihre Manifeste enthält. Der Befehl schlägt fehl, wenn eine ValidatingAdmissionPolicy ein Manifest ablehnt.

Berichterstellung zu Verstößen ersetzen

Eine ValidatingAdmissionPolicy enthält kein Dashboard und prüft keine Ressourcen, die bereits in Ihrem Cluster vorhanden sind. Verwenden Sie stattdessen die folgenden Methoden:

  • Warnungen: Wenn eine ValidatingAdmissionPolicyBinding die Aktion Warn verwendet, gibt der API-Server eine Warnung an den Client zurück, der die Anfrage gesendet hat, z. B. das kubectl-Befehlszeilentool. Bei Pods, die von einem Controller erstellt werden, z. B. Pods in einem Deployment, erhält der Controller die Warnung.

  • Audit-Logs: Wenn eine ValidatingAdmissionPolicyBinding die Aktion Audit verwendet, versieht der API-Server den Audit-Logeintrag für jede fehlgeschlagene Validierung mit einer Annotation. GKE schreibt Erstellungs-, Aktualisierungs- und Löschanfragen in Audit-Logs für Administratoraktivitäten in Cloud Logging. Führen Sie die folgende Abfrage im Log-Explorer aus, um fehlgeschlagene Validierungen zu finden:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
labels."validation.policy.admission.k8s.io/validation_failure":*

Wenn Sie Einschränkungen verwenden, die die Maßnahme dryrun als Compliance-Bericht für vorhandene Ressourcen haben, können ValidatingAdmissionPolicies diesen Bericht nicht ersetzen. Behalten Sie diese Richtlinien im selbstverwalteten Gatekeeper bei, dessen Audit-Controller vorhandene Ressourcen nach einem Zeitplan prüft.

Policy Controller entfernen

Führen Sie die folgenden Aufgaben aus, bevor Sie Policy Controller aus einem Cluster entfernen:

  • Prüfen Sie, ob alle Richtlinien, die Sie zu ValidatingAdmissionPolicies oder Pod Security Admission migriert haben, erzwungen werden und ob Sie ein Backup Ihrer ConstraintTemplates, Einschränkungen und Mutatoren haben. Wenn Sie Policy Controller entfernen, werden die zugehörigen CustomResourceDefinitions gelöscht. Dadurch werden alle ConstraintTemplates, Einschränkungen und Mutatoren im Cluster gelöscht, einschließlich der von Ihnen erstellten.
  • Wenn Sie Einschränkungen aus einem Git-Repository mit einem GitOps-Tool wie Config Sync oder Argo CD bereitstellen, entfernen Sie die ersetzten Einschränkungen aus dem Repository. Prüfen Sie, ob die Einschränkungen aus Ihren Clustern entfernt wurden.
  • Optional: Wenn Sie prüfen möchten, ob nichts vom Policy Controller-Webhook abhängt, setzen Sie zuerst Policy Controller aus. Durch das Sperren werden nur die Webhook-Konfigurationen entfernt. Sie können sie wiederherstellen.

So entfernen Sie Policy Controller:

  1. Deinstallieren Sie Policy Controller in Ihren Clustern:

    gcloud container fleet policycontroller disable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • MEMBERSHIP_NAME: Name der Mitgliedschaft des registrierten Clusters, von dem Sie Policy Controller deinstallieren möchten. Wenn Sie Policy Controller von mehreren Clustern deinstallieren möchten, geben Sie eine durch Kommas getrennte Liste von Mitgliedschaftsnamen an oder ersetzen Sie das Flag --memberships=MEMBERSHIP_NAME durch das Flag --all-memberships.
    • PROJECT_ID: die ID Ihres Flotten-Hostprojekts.

  2. Prüfen Sie, ob Policy Controller vollständig von Ihren Clustern deinstalliert wurde:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

    Warten Sie, bis der Wert des übergeordneten policycontroller.state-Felds für jede Mitgliedschaft NOT_INSTALLED und nicht DECOMMISSIONING ist. Einzelne componentStates-Einträge erreichen den Status NOT_INSTALLED, bevor die Bereinigung der CustomResourceDefinition abgeschlossen ist.

    Wenn Sie einen selbstverwalteten Gatekeeper installieren möchten, prüfen Sie, ob der Namespace gatekeeper-system nicht mehr vorhanden ist:

    kubectl get namespace gatekeeper-system

    Warten Sie, bis in der Ausgabe gemeldet wird, dass der Namespace gatekeeper-system nicht gefunden wurde.

  3. Optional: Wenn Sie verhindern möchten, dass Cluster, die Sie später registrieren, Policy Controller erhalten, entfernen Sie die Standardkonfiguration auf Flottenebene:

    gcloud container fleet policycontroller enable \
    --no-fleet-default-member-config \
    --project=PROJECT_ID

    Mit diesem Befehl wird nur die Standardkonfiguration entfernt. Policy Controller wird in keinem Cluster installiert.

Policy Controller aus Clustern außerhalb einer Flotte entfernen

Mit dem Befehl gcloud container fleet policycontroller disable wird Policy Controller nur aus Clustern entfernt, die von der Flotte verwaltet werden. In den folgenden Fällen kann ein Cluster Policy Controller ohne Flottenverwaltung ausführen:

  • Sie haben Policy Controller mit dem ConfigManagement-Operator installiert.
  • Sie haben die Registrierung des Clusters bei seiner Flotte aufgehoben oder den Befehl gcloud container fleet policycontroller detach ausgeführt, bevor die Deinstallation von Policy Controller abgeschlossen war.

Wenn Sie Policy Controller aus diesen Clustern entfernen möchten, müssen Sie den Cluster in die Fleet-Verwaltung aufnehmen und dann Policy Controller deinstallieren:

  1. Sichern Sie Ihre ConstraintTemplates, Einschränkungen, Synchronisierungskonfigurationen und Mutatoren, wie unter Richtlinien inventarisieren und klassifizieren beschrieben. Wenn Sie Metadaten aus Sicherungen einer ConfigManagement-Operator-Installation bereinigen, entfernen Sie zusätzlich zum Feld ownerReferences und den Metadaten policycontroller.* auch die Labels configmanagement.gke.io/* und k8s-app: kubernetes-config-management.

  2. Wenn Sie Policy Controller mit dem ConfigManagement Operator installiert haben, entfernen Sie das Feld policyController aus der benutzerdefinierten ConfigManagement-Ressource im Cluster. Warten Sie, bis der Abgleich abgeschlossen ist. Der Abgleich kann etwa zwei Minuten dauern. Prüfen Sie dann, ob der Namespace gatekeeper-system noch vorhanden ist:

    kubectl get namespace gatekeeper-system

    In ConfigManagement Operator-Version 1.17 und früher wird Policy Controller automatisch deinstalliert, wenn das Feld policyController entfernt wird. Wenn der Namespace gatekeeper-system nicht gefunden wird, überspringen Sie die verbleibenden Schritte in diesem Abschnitt. In ConfigManagement Operator-Version 1.18 und höher verbleibt der Namespace gatekeeper-system im Cluster. Fahren Sie daher mit dem nächsten Schritt fort.

  3. Wenn der Cluster nicht bei einer Flotte registriert ist, registrieren Sie ihn. Weitere Informationen finden Sie unter Cluster auf Google Cloud bei Ihrer Flotte registrieren.

  4. Prüfen Sie, ob die Mutation im Cluster aktiviert ist:

    kubectl get mutatingwebhookconfiguration \
    gatekeeper-mutating-webhook-configuration

  5. Aktivieren Sie Policy Controller für die Mitgliedschaft des Clusters, damit die Flotte die Verwaltung der vorhandenen Installation übernimmt. Wenn der vorherige Befehl die Ressource gatekeeper-mutating-webhook-configuration zurückgegeben hat, fügen Sie das Flag --mutation ein, damit die Flotte clusterbezogene Mutationsressourcen übernimmt und später entfernt:

    gcloud container fleet policycontroller enable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • MEMBERSHIP_NAME: Name der Mitgliedschaft Ihres registrierten Clusters.
    • PROJECT_ID: die ID Ihres Flotten-Hostprojekts.

  6. Warten Sie, bis der Wert des Felds policycontroller.state für die Mitgliedschaft ACTIVE ist:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

  7. Deinstallieren Sie Policy Controller gemäß der Anleitung unter Policy Controller entfernen. Wenn Sie keinen selbstverwalteten Gatekeeper installieren, löschen Sie alle verbleibenden CustomResourceDefinitions für Einschränkungen, nachdem der Namespace gatekeeper-system entfernt wurde:

    kubectl get crd -o name \
    | grep '\.constraints\.gatekeeper\.sh$' \
    | xargs -r kubectl delete

  8. Optional: Wenn Sie den Cluster nur für dieses Verfahren registriert haben, heben Sie die Registrierung auf, nachdem der Befehl describe den Status NOT_INSTALLED für die Mitgliedschaft angezeigt hat. Führen Sie für Cluster, die Sie mit dem Flag --enable-fleet registriert haben, den Befehl gcloud container clusters update mit dem Flag --clear-fleet-project anstelle des Befehls gcloud container fleet memberships unregister aus. Weitere Informationen finden Sie unter Clusterregistrierung aufheben.

Nächste Schritte