Einschränkungen erstellen

In diesem Thema erfahren Sie, wie Policy Controller-Einschränkungen definiert werden.

Überblick

Mit Policy Controller können Sie Richtlinien für einen Kubernetes-Cluster erzwingen, indem Sie ein oder mehrere Einschränkungsobjekte definieren. Sobald eine Einschränkung installiert ist, werden Anforderungen an den API-Server mit der Einschränkung verglichen und abgelehnt, wenn sie nicht übereinstimmen. 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. Einschränkungsvorlagen können von Google oder Dritten bezogen werden oder Sie können Ihre eigenen schreiben. Weitere Informationen zum Erstellen neuer Vorlagen finden Sie unter Schreiben einer Einschränkungsvorlage.

Hinweis

Einschränkungsvorlagenbibliothek verwenden

Wenn Sie eine Einschränkung definieren, geben Sie die Erweiterungsvorlage an, die sie erweitert. Eine von Google entwickelte Bibliothek mit allgemeinen Einschränkungsvorlagen ist standardmäßig installiert und viele Organisationen müssen keine benutzerdefinierten Einschränkungsvorlagen direkt in Rego erstellen. Von Google bereitgestellte Einschränkungsvorlagen tragen die Bezeichnung configmanagement.gke.io/configmanagement. Verwenden Sie den folgenden Befehl, um sie aufzulisten:

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

So beschreiben Sie eine Einschränkungsvorlage und prüfen die erforderlichen Parameter:

kubectl describe constrainttemplate [CONSTRAINT-TEMPLATE-NAME]

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

Eine Einschränkung definieren

Sie definieren eine Einschränkung mit 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.

  • Das kleingeschriebene kind entspricht dem Namen einer Einschränkungsvorlage.
  • Die metadata.name ist der Name der Einschränkung.
  • Das Feld match definiert, für welche Objekte die Einschränkung gilt. Alle angegebenen Bedingungen müssen übereinstimmen, bevor ein Objekt für eine Einschränkung in den Gültigkeitsbereich fällt. match Bedingungen werden durch die folgenden Unterfelder definiert:
    • kinds sind die Arten von Ressourcen, für die die Einschränkung gilt, bestimmt durch zwei Felder: apiGroups ist eine Liste der übereinstimmenden Kubernetes-API-Gruppen und kinds ist eine Liste der Arten, die übereinstimmen. "*" passt zu allem. Wenn mindestens ein apiGroup und ein kind Eintrag übereinstimmen, ist die Bedingung kinds erfüllt.
    • 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 zu 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 im Namespace, zu dem das Objekt gehört. Wenn der Namespace das Objekt nicht erfüllt, stimmt er nicht überein. Namespace-Ressourcen werden so behandelt, als ob sie zu sich selbst gehören.
  • Das Feld parameters definiert die Argumente für die Einschränkung basierend auf den 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 die Bezeichnung 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"

Wenden Sie die Einschränkung mit kubectl apply -f an, um sie zu erstellen:

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

Eine Einschränkung prüfen

Wenn die Einschränkung richtig konfiguriert und installiert wurde, wird das Feld status.byPod[].enforced auf true gesetzt, unabhängig davon, ob die Einschränkung so konfiguriert ist, dass sie erzwungen oder nur getestet wird.

Einschränkungen werden standardmäßig erzwungen und eine Verletzung einer Einschränkung verhindert eine bestimmte Clusteroperation. 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 zum Auditing finden Sie unter Auditing mit Einschränkungen.

Vorsichtsmaßnahmen beim Synchronisieren von Einschränkungen

Beachten Sie beim Synchronisieren von Einschränkungen die folgenden Vorsichtsmaßnahmen.

Eventual Consistency

Sie können Einschränkungen für das Repository festlegen und deren Auswirkungen mithilfe von ClusterSelectors oder NamespaceSelectors begrenzen. Beachten Sie die folgenden Einschränkungen, da die Synchronisierung letztendlich konsistent ist:

  • Wenn eine Clusteroperation eine Einschränkung auslöst, deren NamespaceSelector auf einen nicht synchronisierten Namespace verweist, wird die Einschränkung erzwungen und die Operation 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 neu gelabelten Namespace auswirken, um sicherzustellen, dass sie wie erwartet funktionieren.

Konfigurieren Sie Policy Controller für referenzielle Einschränkungen

Bevor Sie referenzielle Einschränkungen aktivieren können, müssen Sie eine Konfiguration erstellen, die Policy Controller mitteilt, welche Arten von Objekten beobachtet 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 Ingresses beobachtet werden. Erstellen Sie einen Eintrag mit group, version und kind unter spec.sync.syncOnly mit den Werten für jeden Objekttyp, den Sie beobachten möchten.

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 -Referenzbedingung verweist auf ein anderes Objekt in seiner Definition. 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 die Zeichenfolge data.inventory in ihrem Rego enthält.

Referenzielle Einschränkungen sind in Policy Controller standardmäßig deaktiviert. 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 des Policy Controllers möglicherweise veraltet, was dazu führt, dass eine referenzielle Einschränkung "fehlgeschlagen" ist. Dies bedeutet, dass die Durchsetzungsaktion anscheinend funktioniert, wenn dies nicht der Fall ist. Beispielsweise können Sie Ingresses mit doppelten Hostnamen zu schnell erstellen, damit der Zulassungscontroller die doppelten erkennen kann.

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

Wenn Sie diese Risiken verstehen und dennoch die Unterstützung für referenzielle Einschränkungen aktivieren möchten, setzen Sie policyController.referentialRulesEnabled im Operator-Objekt auf true:

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

Alle Einschränkungen auflisten

Verwenden Sie kubectl, um alle in einem Cluster installierten Einschränkungen aufzulisten.

kubectl get constraint

Eine Einschränkung entfernen

Um alle Einschränkungen mithilfe einer Einschränkungsvorlage zu finden, listen Sie alle Objekte mit demselben kind wie das metadata.name der Einschränkungsvorlage auf:

kubectl get [CONSTRAINT-TEMPLATE-NAME]

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

kubectl delete [CONSTRAINT-TEMPLATE-NAME] [CONSTRAINT-NAME]

Wenn Sie die von der Einschränkung verwendete Einschränkungsvorlage löschen möchten, notieren Sie sich die kind der Einschränkung.

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

Setzen Sie spec.policyController.templateLibraryInstalled auf false. Dies verhindert, dass der Operator die Bibliothek automatisch neu installiert.

So entfernen Sie alle Einschränkungsvorlagen und alle Einschränkungen:

kubectl delete constrainttemplate --all

Einschränkungsvorlagenbibliothek wiederherstellen

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

Nächste Schritte