Einschränkungsvorlagenbibliothek verwenden

Auf dieser Seite erfahren Sie, wie Sie Policy Controller-Einschränkungen mithilfe der bereits von Google bereitgestellten Einschränkungsvorlagen definieren.

Mit Policy Controller können Sie durch Definieren eines oder mehrerer Einschränkungsobjekte Richtlinien für einen Kubernetes-Cluster erzwingen. Nachdem eine Einschränkung installiert wurde, werden Anfragen an den API-Server auf diese Einschränkung geprüft und abgelehnt, wenn sie nicht entsprechen. Bereits vorhandene nicht konforme Ressourcen werden zum Prüfzeitpunkt gemeldet.

Jede Einschränkung wird durch eine Einschränkungsvorlage unterstützt, die das Schema und die Logik der Einschränkung definiert. Sie können Einschränkungsvorlagen von Google und Drittanbietern beziehen oder eigene erstellen. Weitere Informationen zum Erstellen neuer Vorlagen finden Sie unter Einschränkungsvorlage schreiben.

Hinweise

Einschränkungsvorlagenbibliothek untersuchen

Wenn Sie eine Einschränkung definieren, geben Sie die Einschränkungsvorlage an, die erweitert wird. Eine von Google entwickelte Bibliothek mit allgemeinen Einschränkungsvorlagen wird standardmäßig installiert. Viele Organisationen müssen benutzerdefinierte Einschränkungsvorlagen nicht direkt in Rego erstellen. Von Google bereitgestellte Einschränkungsvorlagen tragen das Label configmanagement.gke.io/configmanagement.

Verwenden Sie den folgenden Befehl, um Einschränkungen aufzulisten:

kubectl get constrainttemplates \
    -l="configmanagement.gke.io/configmanagement=config-management"

Verwenden Sie den folgenden Befehl, um eine Einschränkungsvorlage zu beschreiben und die erforderlichen Parameter zu prüfen:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Sie können auch alle Einschränkungsvorlagen in der Bibliothek ansehen.

Einschränkung definieren

Sie definieren eine Einschränkung mithilfe von YAML und müssen Rego nicht verstehen oder schreiben. Stattdessen ruft eine Einschränkung eine Einschränkungsvorlage auf und stellt ihr spezifische Parameter für die Einschränkung zur Verfügung.

Wenn Sie ein strukturiertes Repository verwenden, empfehlen wir, die Einschränkungen im Verzeichnis cluster/ zu erstellen.

Einschränkungen haben die folgenden Felder:

  • Das kleingeschriebene kind entspricht dem Namen einer Einschränkungsvorlage.
  • Der metadata.name ist der Name der Einschränkung.
  • Das Feld match definiert, für welche Objekte die Einschränkung gilt. Erst wenn für alle angegebenen Bedingungen eine Übereinstimmung vorliegt, fällt ein Objekt in den Gültigkeitsbereich einer Einschränkung. match-Bedingungen werden durch die folgenden untergeordneten Felder definiert:
    • kinds sind die Arten von Ressourcen, für die die Einschränkung gilt. Sie werden durch zwei Felder bestimmt: apiGroups ist eine Liste von Kubernetes API-Gruppen, die übereinstimmen, und kinds ist eine Liste von Arten, die übereinstimmen. "*" führt zu einer Übereinstimmung mit allem. Wenn mindestens ein apiGroup- und ein kind-Eintrag übereinstimmen, ist die Bedingung kinds erfüllt.
    • scope akzeptiert *, Cluster oder Namespaced. Damit wird bestimmt, ob cluster- oder Namespace-bezogene Ressourcen ausgewählt werden (standardmäßig *).
    • namespaces ist eine Liste von Namespace-Namen, zu denen das Objekt gehören kann. Das Objekt muss zu mindestens einem dieser Namespaces gehören. Namespace-Ressourcen werden so behandelt, als ob sie sich selbst gehören.
    • excludedNamespaces ist eine Liste von Namespaces, zu denen das Objekt nicht gehören kann.
    • labelSelector ist eine Kubernetes-Labelauswahl, die das Objekt erfüllen muss.
    • namespaceSelector ist eine Labelauswahl für den Namespace, zu dem das Objekt gehört. Wenn der Namespace die Anforderungen des -Objekts nicht erfüllt, wird keine Übereinstimmung gefunden. Namespace-Ressourcen werden so behandelt, als ob sie sich selbst gehören.
  • Das Feld parameters definiert die Argumente für die Einschränkung auf Basis der Erwartungen der Einschränkungsvorlage.

Die folgende Einschränkung mit dem Namen ns-must-have-geo ruft eine Einschränkungsvorlage mit dem Namen K8sRequiredLabels auf, die in der von Google bereitgestellten Einschränkungsvorlagenbibliothek enthalten ist. Die Einschränkung definiert Parameter, mit denen die Einschränkungsvorlage bewertet, ob für Namespaces das Label geo auf einen bestimmten Wert festgelegt ist.

# ns-must-have-geo.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-geo
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "geo"

Verwenden Sie zum Erstellen der Einschränkung kubectl apply -f:

kubectl apply -f ns-must-have-geo.yaml

Einschränkung prüfen

Wenn die Einschränkung richtig konfiguriert und installiert ist, ist ihr Feld status.byPod[].enforced auf den Wert true gesetzt. Dies gilt unabhängig davon, ob die Einschränkung dafür konfiguriert ist, die Einschränkung zu erzwingen oder sie nur zu testen.

Einschränkungen werden standardmäßig erzwungen und ein Verstoß gegen eine Einschränkung verhindert einen bestimmten Clustervorgang. Sie können die spec.enforcementAction einer Einschränkung auf dryrun setzen, um Verstöße im Feld status.violations zu melden, ohne den Vorgang zu verhindern.

Weitere Informationen zur Prüfung finden Sie unter Audit mit Einschränkungen.

Einschränkungen beim Synchronisieren von Einschränkungen

Wenn Sie Ihre Einschränkungen mit Config Sync oder einem anderen GitOps-ähnlichen Tool mit einer Source of Truth synchronisieren, sollten Sie beim Synchronisieren von Einschränkungen die folgenden Vorbehalte beachten.

Eventual Consistency

Sie können Einschränkungen einer „Source of Truth“ wie einem Git-Repository zuweisen und ihre Auswirkungen mithilfe von ClusterSelectors oder NamespaceSelectors begrenzen. Beachten Sie die folgenden Einschränkungen, da die Synchronisierung letztendlich konsistent ist:

  • Wenn ein Clustervorgang eine Einschränkung auslöst, deren NamespaceSelector auf einen nicht synchronisierten Namespace verweist, wird die Einschränkung erzwungen und der Vorgang verhindert. Mit anderen Worten, ein fehlender Namespace "schlägt geschlossen fehl".
  • Wenn Sie die Labels eines Namespace ändern, enthält der Cache möglicherweise für kurze Zeit veraltete Daten.

Minimieren Sie die Notwendigkeit, einen Namespace umzubenennen oder seine Labels zu ändern, und testen Sie Einschränkungen, die sich auf einen umbenannten oder mit neuen Labels versehenen Namespace auswirken, um sicherzustellen, dass sie wie erwartet funktionieren.

Policy Controller für referenzielle Einschränkungen konfigurieren

Bevor Sie referenzielle Einschränkungen aktivieren können, müssen Sie eine Konfiguration erstellen, die Policy Controller mitteilt, welche Arten von Objekten überwacht werden sollen, z. B. Namespaces.

Speichern Sie das folgende YAML-Manifest in einer Datei und wenden Sie es mit kubectl an. Das Manifest konfiguriert Policy Controller so, dass Namespaces und Ingress-Instanzen im Blick behalten werden. Erstellen Sie unter spec.sync.syncOnly mit den Werten für jeden Objekttyp, den Sie im Blick behalten möchten, einen Eintrag mit group, version und kind.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "extensions"
        version: "v1beta1"
        kind: "Ingress"

Referenzielle Einschränkungen aktivieren

Eine referenzielle Einschränkung verweist in ihrer Definition auf ein anderes Objekt. Sie können beispielsweise eine Einschränkung erstellen, für die Ingress-Objekte in einem Cluster eindeutige Hostnamen haben müssen. Die Einschränkung ist referenziell, wenn ihre Einschränkungsvorlage in ihrem Rego den String data.inventory enthält.

Referenzielle Einschränkungen sind standardmäßig aktiviert, wenn Sie Policy Controller über die Google Cloud Console installieren. Wenn Sie Policy Controller über die Google Cloud CLI installieren, können Sie beim Installieren von Policy Controller auswählen, ob referenzielle Einschränkungen aktiviert werden sollen. Es wird nur garantiert, dass referenzielle Einschränkungen letztendlich konsistent sind, und dies birgt Risiken:

  • Auf einem überlasteten API-Server ist der Inhalt des Caches von Policy Controller möglicherweise schnell veraltet, was dazu führt, dass eine referenzielle Einschränkung "offen fehlschlägt". Dies bedeutet, dass die Erzwingungsaktion anscheinend funktioniert, wenn dies in Wahrheit nicht der Fall ist. Beispielsweise können Sie so schnell mehrere Ingress-Instanzen mit dem gleichen Hostnamen erstellen, dass der Admission-Controller die Duplikate nicht erkennen kann.

  • Die Reihenfolge, in der Einschränkungen installiert werden, und die Reihenfolge, in der der Cache aktualisiert wird, sind beide zufällig.

Sie können einen vorhandenen Cluster aktualisieren, um referenzielle Einschränkungen zuzulassen.

Console

Führen Sie die folgenden Schritte aus, um referenzielle Einschränkungen zu deaktivieren:

  1. Rufen Sie in der Google Cloud Console im Abschnitt Posture Management (Verwaltung des Sicherheitsstatus) die Seite GKE Enterprise-Richtlinie auf.

    Zur Richtlinie

  2. Wählen Sie in der Clustertabelle auf dem Tab Einstellungen in der Spalte Konfiguration bearbeiten die Option Bearbeiten aus.
  3. Maximieren Sie das Menü Policy Controller-Konfiguration bearbeiten.
  4. Klicken Sie das Kästchen Einschränkungsvorlagen aktivieren, die auf andere Objekte als das derzeit evaluierte verweisen an.
  5. Wählen Sie Änderungen speichern aus.

gcloud Policy Controller

Führen Sie den folgenden Befehl aus, um die Unterstützung für referenzielle Einschränkungen zu aktivieren:

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --referential-rules

Ersetzen Sie MEMBERSHIP_NAME durch den Mitgliedschaftsnamen des registrierten Clusters, für den referenzielle Regeln aktiviert werden sollen. Du kannst mehrere Mitgliedschaften angeben, die durch ein Komma getrennt sind.

gcloud ConfigManagement

Damit referenzielle Einschränkungen unterstützt werden, legen Sie policyController.referentialRulesEnabled in der Datei config-management.yaml auf true fest:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: true

Referenzielle Einschränkungen deaktivieren

Wenn Sie referenzielle Einschränkungen deaktivieren, werden alle Vorlagen, die referenzielle Einschränkungen verwenden, zusammen mit allen Einschränkungen, die diese Vorlagen verwenden, aus dem Cluster entfernt.

Console

Referenzielle Einschränkungen sind standardmäßig aktiviert, wenn Sie Policy Controller mit der Google Cloud Console installieren. Führen Sie die folgenden Schritte aus, um referenzielle Einschränkungen zu deaktivieren:

  1. Rufen Sie in der Google Cloud Console im Abschnitt Posture Management (Verwaltung des Sicherheitsstatus) die Seite GKE Enterprise-Richtlinie auf.

    Zur Richtlinie

  2. Wählen Sie in der Clustertabelle auf dem Tab Einstellungen in der Spalte Konfiguration bearbeiten die Option Bearbeiten aus.
  3. Maximieren Sie das Menü Policy Controller-Konfiguration bearbeiten.
  4. Entfernen Sie das Häkchen aus dem Kästchen Einschränkungsvorlagen aktivieren, die auf andere Objekte als das derzeit evaluierte verweisen.
  5. Wählen Sie Änderungen speichern aus.

gcloud Policy Controller

Führen Sie den folgenden Befehl aus, um die Unterstützung für referenzielle Einschränkungen zu deaktivieren:

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --no-referential-rules

Ersetzen Sie MEMBERSHIP_NAME durch den Mitgliedschaftsnamen des registrierten Clusters, für den referenzielle Regeln aktiviert werden sollen. Du kannst mehrere Mitgliedschaften angeben, die durch ein Komma getrennt sind.

gcloud ConfigManagement

Zum Deaktivieren referenzieller Einschränkungen für einen Cluster setzen Sie policyController.referentialRulesEnabled in der Datei config-management.yaml auf false:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: false

Alle Einschränkungen auflisten

Mit dem folgenden Befehl können Sie alle Einschränkungen auflisten, die für einen Cluster installiert sind:

kubectl get constraint

Sie können sich auch eine Übersicht der angewendeten Einschränkungen in der Google Cloud Console ansehen. Weitere Informationen finden Sie unter Policy Controller-Messwerte.

Einschränkung entfernen

Um alle Einschränkungen zu finden, die eine Einschränkungsvorlage verwenden, listen Sie mit folgendem Befehl alle Objekte mit derselben kind wie der metadata.name der Einschränkungsvorlage auf:

kubectl get CONSTRAINT_TEMPLATE_NAME

Geben Sie zum Entfernen einer Einschränkung deren kind und name an:

kubectl delete CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Wenn Sie eine Einschränkung entfernen, wird sie nicht mehr erzwungen, sobald der API-Server die Einschränkung als gelöscht markiert.

Alle Einschränkungsvorlagen entfernen

Console

Führen Sie die folgenden Schritte aus, um die Einschränkungsvorlagenbibliothek zu deaktivieren:

  1. Rufen Sie in der Google Cloud Console im Abschnitt Posture Management (Verwaltung des Sicherheitsstatus) die Seite GKE Enterprise-Richtlinie auf.

    Zur Richtlinie

  2. Wählen Sie in der Clustertabelle auf dem Tab Einstellungen in der Spalte Konfiguration bearbeiten die Option Bearbeiten aus.
  3. Deaktivieren Sie im Menü Richtlinien-Bundles hinzufügen/bearbeiten die Vorlagenbibliothek und alle Richtlinien-Bundles auf .
  4. Wählen Sie Änderungen speichern aus.

gcloud Policy Controller

Führen Sie den folgenden Befehl aus, um die Einschränkungsvorlagenbibliothek zu deaktivieren:

gcloud container fleet policycontroller content templates disable \
    --memberships=MEMBERSHIP_NAME

Ersetzen Sie MEMBERSHIP_NAME durch den Mitgliedschaftsnamen des registrierten Clusters, um die Einschränkungsvorlagenbibliothek zu deaktivieren. Sie können mehrere Mitgliedschaften angeben, die durch ein Komma getrennt sind.

gcloud ConfigManagement

Setzen Sie spec.policyController.templateLibraryInstalled auf false. Dadurch wird verhindert, dass Policy Controller, Config Sync und Config Controller die Bibliothek automatisch neu installieren.

Entfernen Sie alle Einschränkungsvorlagen und alle Einschränkungen mit dem folgenden Befehl:

kubectl delete constrainttemplate --all

Einschränkungsvorlagenbibliothek wiederherstellen

Console

Führen Sie die folgenden Schritte aus, um die Einschränkungsvorlagenbibliothek zu aktivieren:

  1. Rufen Sie in der Google Cloud Console im Abschnitt Posture Management (Verwaltung des Sicherheitsstatus) die Seite GKE Enterprise-Richtlinie auf.

    Zur Richtlinie

  2. Wählen Sie in der Clustertabelle auf dem Tab Einstellungen in der Spalte Konfiguration bearbeiten die Option Bearbeiten aus.
  3. Aktivieren Sie im Menü Richtlinien-Bundles hinzufügen/bearbeiten die Vorlagenbibliothek . Sie können auch einige oder alle Richtlinien-Bundles aktivieren.
  4. Wählen Sie Änderungen speichern aus.

gcloud Policy Controller

Führen Sie den folgenden Befehl aus, um die Einschränkungsvorlagenbibliothek wiederherzustellen:

gcloud container fleet policycontroller content templates enable \
    --memberships=MEMBERSHIP_NAME

Ersetzen Sie MEMBERSHIP_NAME durch den Mitgliedschaftsnamen des registrierten Clusters, für den die Einschränkungsvorlagenbibliothek aktiviert werden soll. Sie können mehrere Mitgliedschaften angeben, die durch ein Komma getrennt sind.

gcloud ConfigManagement

Wenn Sie die Einschränkungsvorlagenbibliothek deaktiviert oder alle Einschränkungsvorlagen deinstalliert haben, können Sie sie wiederherstellen, indem Sie spec.policyController.templateLibraryInstalled in der Policy Controller-, Config Sync- und Config Controller-Konfiguration auf true setzen.

Verwenden Sie den folgenden Befehl, um den Operator-Pod neu zu starten:

kubectl delete pod -n config-management-system -l k8s-app=config-management-operator

Nächste Schritte