Aktionen für GKE-Ressourcen mithilfe benutzerdefinierter Organisationsrichtlinien einschränken

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie bestimmte Vorgänge für GKE-Ressourcen (Google Kubernetes Engine) in Ihrer Organisation mithilfe von benutzerdefinierten Einschränkungen im Google Cloud-Organisationsrichtliniendienst einschränken. Weitere Informationen zu Organisationsrichtlinien finden Sie unter Benutzerdefinierte Organisationsrichtlinien.

Informationen zu Organisationsrichtlinien und Einschränkungen

Mit der Google Cloud-Organisationsrichtlinie können Sie die Ressourcen Ihrer Organisation zentral und programmatisch steuern. Als Administrator für Organisationsrichtlinien können Sie Folgendes definieren: Organisationsrichtlinie, wobei es sich um eine Reihe von Einschränkungen handelt, die für Google Cloud-Ressourcen und untergeordnete Elemente dieser Ressourcen in der Google Cloud-Ressourcenhierarchie gelten. Sie können Organisationsrichtlinien auf Organisations-, Ordner- oder Projektebene erzwingen.

Die Organisationsrichtlinie bietet vordefinierte Einschränkungen für verschiedene Google Cloud-Dienste. Wenn Sie jedoch eine detailliertere, anpassbare Steuerung der spezifischen Felder wünschen, die in Ihren Organisationsrichtlinien eingeschränkt werden, können Sie auch benutzerdefinierte Einschränkungen erstellen und diese benutzerdefinierten Einschränkungen in einer benutzerdefinierten Organisationsrichtlinie verwenden.

Unterstützte Ressourcen in GKE

Für GKE können Sie benutzerdefinierte Einschränkungen für die Methoden CREATE oder UPDATE für jedes Feld in der Ressource Cluster oder NodePool der Google Kubernetes Engine API v1 außer für reine Ausgabefelder und die folgenden Felder erstellen:

projects.locations.clusters.masterAuth.clientKey
projects.locations.clusters.masterAuth.password

Übernahme von Richtlinien

Standardmäßig werden Richtlinien von den Nachfolgerelementen der Ressourcen übernommen, für die Sie die Richtlinie erzwingen. Wenn Sie beispielsweise eine Richtlinie für einen Ordner erzwingen, erzwingt Google Cloud die Richtlinie für alle Projekte in dem Ordner. Weitere Informationen zu diesem Verhalten und zu dessen Änderung finden Sie unter Regeln für die Evaluierung der Hierarchie.

Preise

Organisationsrichtlinien und Einschränkungen werden kostenlos angeboten.

Hinweis

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Organization Policy Administrator (roles/orgpolicy.policyAdmin) in Ihrer Google Cloud-Organisation zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Einschränkungen und zum Erzwingen von Organisationsrichtlinien benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.
Sie müssen Ihre Organisations-ID kennen.

Benutzerdefinierte Einschränkung erstellen

Zum Erstellen einer neuen benutzerdefinierten Einschränkung definieren Sie die Einschränkung in einer YAML-Datei und wenden die benutzerdefinierte Einschränkung in Ihrer Organisation mithilfe der Google Cloud CLI an.

Erstellen Sie eine YAML-Datei für die benutzerdefinierte Einschränkung:
```
name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_NAME
resourceTypes:
- container.googleapis.com/RESOURCE_NAME
methodTypes:
- METHOD1
- METHOD2
condition: "resource.OBJECT_NAME.FIELD_NAME == VALUE"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION
```
Dabei gilt:
- ORGANIZATION_ID: Ihre Organisations-ID, z. B. 123456789.
- CONSTRAINT_NAME: Name, den Sie für Ihre neue benutzerdefinierte Einschränkung verwenden möchten. Eine benutzerdefinierte Einschränkung muss mit custom. beginnen und darf nur Großbuchstaben, Kleinbuchstaben oder Ziffern enthalten, z. B. custom.enableGkeAutopilot. Die maximale Länge dieses Feldes beträgt 70 Zeichen, das Präfix wird nicht gezählt (z. B. organizations/123456789/customConstraints/custom.).
- RESOURCE_NAME: Name (nicht der URI) der REST API-Ressource in GKE, die das Objekt und das Feld enthält, das Sie einschränken möchten Beispiel: Clusteroder NodePool
- METHOD1,METHOD2,...: Liste der RESTful-Methoden, für die die Einschränkung erzwungen werden soll Kann CREATE oder CREATE und UPDATE sein
- condition: Die Bedingung zur Validierung der Anfrage in Common Expression Language (CEL) Dieses Feld hat eine maximale Länge von 1000 Zeichen. Der Ausdruck muss die folgenden Felder enthalten und unterstützt logische Operatoren wie && und ||:
  - OBJECT_NAME: Name des GKE API-Objekts, das Sie einschränken möchten, in pascalCase-Formatierung. Beispiel: privateClusterConfig
  - FIELD_NAME: Name des GKE API-Felds, das Sie einschränken möchten, in pascalCase-Formatierung. Beispiel: enablePrivateNodes
  - VALUE: Wert des Felds. Verwenden Sie für boolesche Felder true oder false. Verwenden Sie für Stringfelder "STRING".
- ACTION: Aktion, die ausgeführt werden soll, wenn condition erfüllt ist. Dies kann entweder ALLOW oder DENY sein.
- DISPLAY_NAME: Ein nutzerfreundlicher Name für die Einschränkung. Dieses Feld hat eine maximale Länge von 200 Zeichen.
- DESCRIPTION: Eine nutzerfreundliche Beschreibung der Einschränkung, die als Fehlermeldung angezeigt werden soll, wenn die Richtlinie verletzt wird Dieses Feld hat eine maximale Länge von 2000 Zeichen.
Wenden Sie die benutzerdefinierte Einschränkung an:
```
gcloud org-policies set-custom-constraint PATH_TO_FILE
```
Ersetzen Sie PATH_TO_FILE durch den Dateipfad der Definition der benutzerdefinierten Einschränkung.

Prüfen Sie, ob die benutzerdefinierte Einschränkung vorhanden ist:

gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

Die Ausgabe sieht etwa so aus:

CONSTRAINT                     LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot      -              SET               COCsm5QGENiXi2E=
...

Benutzerdefinierte Einschränkung erzwingen

Um die neue benutzerdefinierte Einschränkung zu erzwingen, erstellen Sie eine Organisationsrichtlinie, die auf die Einschränkung verweist, und wenden Sie die Organisationsrichtlinie an.

Erstellen Sie eine YAML-Datei für die Organisationsrichtlinie:
```
name: RESOURCE_HIERARCHY/policies/POLICY_NAME
spec:
  rules:
  - enforce: true
```
Dabei gilt:
- RESOURCE_HIERARCHY: Speicherort der neuen Richtlinie, der sich auf den Erzwingungsbereich auswirkt. Verwenden Sie die Google Cloud-Ressourcenhierarchie als Orientierungshilfe. Wenn Sie die Richtlinie beispielsweise in einem bestimmten Projekt erzwingen möchten, verwenden Sie projects/PROJECT_ID. Verwenden Sie organizations/ORGANIZATION_ID, um die Richtlinie in einer bestimmten Organisation zu erzwingen.
- POLICY_NAME: Name der neuen Richtlinie.
Erzwingen Sie die Richtlinie:
```
gcloud org-policies set-policy PATH_TO_POLICY
```
Ersetzen Sie PATH_TO_POLICY durch den Pfad zu Ihrer Richtliniendefinitionsdatei.

Prüfen Sie, ob die Richtlinie vorhanden ist:

gcloud org-policies list \
    --RESOURCE_FLAG=RESOURCE_ID

Dabei gilt:

RESOURCE_FLAG: Google Cloud-Ressource, für die Sie die Richtlinie erzwungen haben. Beispiel: projectoder folder
RESOURCE_ID: ID der Ressource, in der Sie die Richtlinie erzwungen haben. Beispiel: Ihre Google Cloud-Ordner-ID.

Eine Liste der Argumente finden Sie unter gcloud org-policies list.

Die Ausgabe sieht etwa so aus:

CONSTRAINT                                    LIST_POLICY    BOOLEAN_POLICY    ETAG
iam.disableWorkloadIdentityClusterCreation    -              SET               CO3UkJAGEOj1qsQB
custom.enableGkeAutopilot                     -              SET               COCsm5QGENiXi2E=
custom.enableBinAuth                          -              SET               CJfKiZUGEJju7LUD

Beispiel: Benutzerdefinierte Einschränkung erstellen und Richtlinie erzwingen

Im folgenden Beispiel werden eine benutzerdefinierte Einschränkung und eine Richtlinie erstellt, bei der alle neuen Cluster in einem bestimmten Projekt Autopilot-Cluster sein müssen.

Bevor Sie beginnen, sollten Sie Folgendes kennen:

Ihre Organisations-ID.
Eine Projekt-ID.

Einschränkung erstellen

Speichern Sie die folgende Datei als constraint-enable-autopilot.yaml:

name: organizations/ORGANIZATION_ID/customConstraints/custom.enableGkeAutopilot
resourceTypes:
- container.googleapis.com/Cluster
methodTypes:
- CREATE
condition: "resource.autopilot.enabled == false"
actionType: DENY
displayName: Enable GKE Autopilot
description: All new clusters must be Autopilot clusters.

Dies definiert eine Einschränkung, bei der für jeden neuen Cluster der Vorgang abgelehnt wird, wenn der Clustermodus nicht Autopilot ist.

Wenden Sie die Einschränkung an:

gcloud org-policies set-custom-constraint ~/constraint-enable-autopilot.yaml

Prüfen Sie, ob die Einschränkung vorhanden ist:

gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

Die Ausgabe sieht in etwa so aus:

CUSTOM_CONSTRAINT                       ACTION_TYPE  METHOD_TYPES   RESOURCE_TYPES                     DISPLAY_NAME
custom.enableGkeAutopilot               DENY         CREATE         container.googleapis.com/Cluster   Enable GKE Autopilot
...

Richtlinie erstellen

Speichern Sie die folgende Datei als policy-enable-autopilot.yaml:
```
name: projects/PROJECT_ID/policies/custom.enableGkeAutopilot
spec:
  rules:
  - enforce: true
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Wenden Sie die Richtlinie an:

gcloud org-policies set-policy ~/policy-enable-autopilot.yaml

Prüfen Sie, ob die Richtlinie vorhanden ist:

gcloud org-policies list --project=PROJECT_ID

Die Ausgabe sieht in etwa so aus:

CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=

Warten Sie nach dem Anwenden der Richtlinie etwa zwei Minuten, bis Google Cloud die Richtlinie durchgesetzt hat.

Richtlinie testen

Versuchen Sie, im Projekt einen GKE Standard-Cluster zu erstellen:

gcloud container clusters create org-policy-test \
    --project=PROJECT_ID \
    --zone=COMPUTE_ZONE \
    --num-nodes=1

Die Ausgabe sieht so aus:

Operation denied by custom org policies: ["customConstraints/custom.enableGkeAutopilot": "All new clusters must be Autopilot clusters."]

Beispiele für benutzerdefinierte Einschränkungen für häufige Anwendungsfälle

Die folgenden Abschnitte enthalten die Syntax einiger benutzerdefinierter Einschränkungen, die für Sie nützlich sein könnten:

Beschreibung	Einschränkungssyntax
Clustererstellung nur zulassen, wenn die Binärautorisierung aktiviert ist	name: organizations/`ORGANIZATION_ID`/customConstraints/custom.gkeBinaryAuthorization resourceTypes: - container.googleapis.com/Cluster methodTypes: - CREATE condition: "condition:resource.binaryAuthorization.enabled == true \|\| resource.binaryAuthorization.evaluationMode=='PROJECT_SINGLETON_POLICY_ENFORCE'" action: ALLOW displayName: Enable GKE Binary Authorization description: All new clusters must enable Binary Authorization.
Automatische Knotenupgrades für neue Knotenpools nicht deaktivieren	name: organizations/`ORGANIZATION_ID`/customConstraints/custom.enableAutoUpgrade resourceTypes: - container.googleapis.com/NodePool methodTypes: - CREATE condition: "resource.management.autoUpgrade == true" actionType: ALLOW displayName: Enable node auto-upgrade description: All node pools must have node auto-upgrade enabled.
Workload Identity-Föderation für GKE für neue Cluster aktivieren	name: organizations/`ORGANIZATION_ID`/customConstraints/custom.enableWorkloadIdentity resourceTypes: - container.googleapis.com/Cluster methodTypes: - CREATE condition: "has(resource.workloadIdentityConfig.workloadPool) \|\| resource.workloadIdentityConfig.workloadPool.size() > 0" actionType: ALLOW displayName: Enable Workload Identity on new clusters description: All new clusters must use Workload Identity.
Cloud Logging auf vorhandenen Clustern nicht deaktivieren	name: organizations/`ORGANIZATION_ID`/customConstraints/custom.enableLogging resourceTypes: - container.googleapis.com/Cluster methodTypes: - UPDATE condition: "resource.loggingService == 'none'" actionType: DENY displayName: Do not disable Cloud Logging description: You cannot disable Cloud Logging on existing GKE cluster.
Erstellen oder Aktualisieren von Standardknotenpools nur zulassen, wenn Legacy-Metadatenendpunkte deaktiviert sind	name: organizations/`ORGANIZATION_ID`/customConstraints/custom.nodeConfigMetadata resourceTypes: - container.googleapis.com/NodePool methodTypes: - CREATE - UPDATE condition: "'disable-legacy-endpoints' in resource.config.metadata && resource.config.metadata['disable-legacy-endpoints'] == 'true'" actionType: ALLOW displayName: Disable legacy metadata endpoints description: You can only create or update node pools if you disable legacy metadata endpoints. Dieses Beispiel für die Einschränkung zeigt Ihnen, wie Sie eine benutzerdefinierte Einschränkung für einen Kartenwert festlegen. Das Feld `condition` verwendet den Indexoperator für den Zuordnungsschlüssel `disable-legacy-endpoints`. Wenn Sie wie in den vorherigen Beispielen stattdessen die reguläre Syntax für die Feldauswahl verwenden, wird der Fehler `INVALID_CUSTOM_CONSTRAINT_CONDITION` angezeigt.