Richtlinienkonforme Google Cloud-Ressourcen erstellen

GKE-Cluster erstellen

1. Erstellen Sie in Cloud Shell einen GKE-Cluster mit dem Add-on „Config Connector“ und der Workload Identity-Föderation für GKE:

   gcloud container clusters create CLUSTER_NAME \
     --addons ConfigConnector \
     --enable-ip-alias \
     --num-nodes 4 \
     --release-channel regular \
     --scopes cloud-platform \
     --workload-pool $GOOGLE_CLOUD_PROJECT.svc.id.goog \
     --zone ZONE
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name des Clusters, den Sie für dieses Projekt verwenden möchten, z. B. cnrm-gatekeeper-tutorial.
   • ZONE: Eine Compute Engine-Zone in der Nähe Ihres Standorts, z. B. asia-southeast1-b.

   Mit dem Add-on "Config Connector" werden benutzerdefinierte Ressourcendefinitionen für Google Cloud-Ressourcen in Ihrem GKE-Cluster installiert.

2. (Optional) Wenn Sie einen privaten Cluster in Ihrer eigenen Umgebung verwenden, fügen Sie eine Firewallregel hinzu, mit der die Steuerungsebene des GKE-Clusters eine Verbindung zum Policy Controller-Webhook herstellen kann:

   gcloud compute firewall-rules create allow-cluster-control-plane-tcp-8443 \
     --allow tcp:8443 \
     --network default \
     --source-ranges CONTROL_PLANE_CIDR \
     --target-tags NODE_TAG
   

   Ersetzen Sie Folgendes:

   • CONTROL_PLANE_CIDR: Der IP-Bereich für die GKE-Cluster-Steuerungsebene, z. B. 172.16.0.16/28.
   • NODE_TAG: Ein Tag, das auf alle Knoten in Ihrem GKE-Cluster angewendet wird.

   Diese optionale Firewallregel ist erforderlich, damit der Policy Controller-Webhook funktioniert, wenn Ihr Cluster private Knoten verwendet.

Config Connector einrichten

Das Google Cloud-Projekt, in dem Sie Config Connector installieren, wird als Hostprojekt bezeichnet. Die Projekte, in denen Sie mit Config Connector Ressourcen verwalten, werden als verwaltete Projekte bezeichnet. In dieser Anleitung verwenden Sie Config Connector, um Google Cloud-Ressourcen im selben Projekt wie Ihr GKE-Cluster zu erstellen, sodass das Hostprojekt und das verwaltete Projekt dasselbe Projekt sind.

1. Erstellen Sie in Cloud Shell ein Google-Dienstkonto für Config Connector:

   gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
     --display-name "Config Connector Gatekeeper tutorial"
   

   Ersetzen Sie SERVICE_ACCOUNT_NAME durch den Namen, den Sie für dieses Dienstkonto verwenden möchten, z. B. cnrm-gatekeeper-tutorial. Config Connector verwendet dieses Google-Dienstkonto, um Ressourcen in Ihrem verwalteten Projekt zu erstellen.

2. Weisen Sie dem Google-Dienstkonto die Rolle "Storage-Administrator" zu:

   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
     --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com" \
     --role roles/storage.admin
   

   In dieser Anleitung verwenden Sie die Rolle "Storage-Administrator", da Sie mit Cloud Storage Connector Cloud Storage-Buckets erstellen. Gewähren Sie in Ihrer eigenen Umgebung die Rollen, die zum Verwalten der Google Cloud-Ressourcen erforderlich sind, die Sie für Config Connector erstellen möchten. Weitere Informationen zu vordefinierten Rollen finden Sie in der IAM-Dokumentation unter Informationen zu Rollen.

3. Erstellen Sie einen Kubernetes-Namespace für die Config Connector-Ressourcen, die Sie in dieser Anleitung erstellen:

   kubectl create namespace NAMESPACE
   

   Ersetzen Sie NAMESPACE durch den Kubernetes-Namespace, den Sie in der Anleitung verwenden möchten, z. B. tutorial.

4. Annotieren Sie den Namespace, um festzulegen, welches Projekt Config Connector zum Erstellen von Google Cloud-Ressourcen (das verwaltete Projekt) verwenden soll:

   kubectl annotate namespace NAMESPACE \
       cnrm.cloud.google.com/project-id=$GOOGLE_CLOUD_PROJECT
   

5. Erstellen Sie eine ConfigConnectorContext-Ressource, die Config Connector für den Kubernetes-Namespace aktiviert und mit dem von Ihnen erstellten Google-Dienstkonto verknüpft:

   cat << EOF | kubectl apply -f -
   apiVersion: core.cnrm.cloud.google.com/v1beta1
   kind: ConfigConnectorContext
   metadata:
     name: configconnectorcontext.core.cnrm.cloud.google.com
     namespace: NAMESPACE
   spec:
     googleServiceAccount: SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
   EOF
   

   Wenn Sie die Ressource ConfigConnectorContext erstellen, erstellt Config Connector ein Kubernetes-Dienstkonto und ein StatefulSet im Namespace cnrm-system, um die Config Connector-Ressourcen in Ihrem Namespace zu verwalten.

6. Warten Sie auf den Namespace des Config Connector-Controller-Pods für Ihren Namespace:

   kubectl wait --namespace cnrm-system --for=condition=Ready pod \
     -l cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE
   

   Wenn der Pod bereit ist, wird die Cloud Shell-Eingabeaufforderung angezeigt. Wenn Sie die Meldung error: no matching resources found erhalten, warten Sie eine Minute und versuchen Sie es dann noch einmal.

7. Binden Sie das Kubernetes-Dienstkonto von Config Connector an Ihr Google-Dienstkonto. Erstellen Sie dazu eine IAM-Richtlinienbindung:

   gcloud iam service-accounts add-iam-policy-binding \
     SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
     --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
     --role roles/iam.workloadIdentityUser
   

   Durch diese Bindung kann das Kubernetes-Dienstkonto cnrm-controller-manager-NAMESPACE im Namespace cnrm-system als von Ihnen erstelltes Google-Dienstkonto fungieren.

Policy Controller installieren

Installieren Sie Policy Controller gemäß der Installationsanleitung.

Verwenden Sie ein Prüfintervall von 60 Sekunden.

Google Cloud-Ressource mit Config Connector erstellen

1. Erstellen Sie in Cloud Shell ein Config Connector-Manifest, das einen Cloud Storage-Bucket in der Region us-central1 darstellt:

   cat << EOF > tutorial-storagebucket-us-central1.yaml
   apiVersion: storage.cnrm.cloud.google.com/v1beta1
   kind: StorageBucket
   metadata:
     name: tutorial-us-central1-$GOOGLE_CLOUD_PROJECT
     namespace: NAMESPACE
   spec:
     location: us-central1
     uniformBucketLevelAccess: true
   EOF
   

2. Zum Erstellen des Cloud Storage-Buckets wenden Sie das Manifest an:

   kubectl apply -f tutorial-storagebucket-us-central1.yaml
   

3. Überprüfen Sie, ob der Config Connector den Cloud Storage-Bucket erstellt hat:

   gcloud storage ls | grep tutorial
   

   Die Ausgabe sieht in etwa so aus:

   gs://tutorial-us-central1-PROJECT_ID/
   

   Diese Ausgabe enthält PROJECT_ID. Dies ist Ihre Google Cloud-Projekt-ID.

   Wenn diese Ausgabe nicht angezeigt wird, warten Sie eine Minute und führen diesen Schritt noch einmal aus.

Richtlinie erstellen

Eine Richtlinie in Policy Controller besteht aus einer Einschränkungsvorlage und einer Einschränkung. Die Einschränkungsvorlage enthält die Richtlinienlogik. Die Einschränkung gibt an, wo die Richtlinie angewendet wird, und die Eingabeparameter für die Richtlinienlogik.

1. Erstellen Sie in Cloud Shell eine Einschränkungsvorlage, die Cloud Storage-Bucket-Standorte einschränkt:

   cat << EOF > tutorial-storagebucket-location-template.yaml
   apiVersion: templates.gatekeeper.sh/v1beta1
   kind: ConstraintTemplate
   metadata:
     name: gcpstoragelocationconstraintv1
   spec:
     crd:
       spec:
         names:
           kind: GCPStorageLocationConstraintV1
         validation:
           openAPIV3Schema:
             properties:
               locations:
                 type: array
                 items:
                   type: string
               exemptions:
                 type: array
                 items:
                   type: string
     targets:
     - target: admission.k8s.gatekeeper.sh
       rego: |
         package gcpstoragelocationconstraintv1
   
         allowedLocation(reviewLocation) {
             locations := input.parameters.locations
             satisfied := [ good | location = locations[_]
                                   good = lower(location) == lower(reviewLocation)]
             any(satisfied)
         }
   
         exempt(reviewName) {
             input.parameters.exemptions[_] == reviewName
         }
   
         violation[{"msg": msg}] {
             bucketName := input.review.object.metadata.name
             bucketLocation := input.review.object.spec.location
             not allowedLocation(bucketLocation)
             not exempt(bucketName)
             msg := sprintf("Cloud Storage bucket <%v> uses a disallowed location <%v>, allowed locations are %v", [bucketName, bucketLocation, input.parameters.locations])
         }
   
         violation[{"msg": msg}] {
             not input.parameters.locations
             bucketName := input.review.object.metadata.name
             msg := sprintf("No permitted locations provided in constraint for Cloud Storage bucket <%v>", [bucketName])
         }
   EOF
   

2. Wenden Sie die Vorlage an, um den Cloud Storage-Bucket zu erstellen:

   kubectl apply -f tutorial-storagebucket-location-template.yaml
   

3. Erstellen Sie eine Einschränkung, die nur Buckets in den Regionen Singapur und Jakarta zulässt (asia-southeast1 und asia-southeast2). Die Einschränkung gilt für den zuvor erstellten Namespace. Der standardmäßige Cloud Storage-Bucket für Cloud Build ist dabei ausgenommen.

   cat << EOF > tutorial-storagebucket-location-constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: GCPStorageLocationConstraintV1
   metadata:
     name: singapore-and-jakarta-only
   spec:
     enforcementAction: deny
     match:
       kinds:
       - apiGroups:
         - storage.cnrm.cloud.google.com
         kinds:
         - StorageBucket
       namespaces:
       - NAMESPACE
     parameters:
       locations:
       - asia-southeast1
       - asia-southeast2
       exemptions:
       - ${GOOGLE_CLOUD_PROJECT}_cloudbuild
   EOF
   

4. Wenden Sie die Einschränkung an, um die Zonen einzuschränken, in denen Buckets vorhanden sein können:

   kubectl apply -f tutorial-storagebucket-location-constraint.yaml
   

Richtlinie prüfen

1. Erstellen Sie ein Manifest, das einen Cloud Storage-Bucket an einem nicht zulässigen Standort darstellt (us-west1):

   cat << EOF > tutorial-storagebucket-us-west1.yaml
   apiVersion: storage.cnrm.cloud.google.com/v1beta1
   kind: StorageBucket
   metadata:
     name: tutorial-us-west1-$GOOGLE_CLOUD_PROJECT
     namespace: NAMESPACE
   spec:
     location: us-west1
     uniformBucketLevelAccess: true
   EOF
   

2. Zum Erstellen des Cloud Storage-Buckets wenden Sie das Manifest an:

   kubectl apply -f tutorial-storagebucket-us-west1.yaml
   

   Die Ausgabe sieht in etwa so aus:

   Error from server ([singapore-and-jakarta-only] Cloud Storage bucket
   <tutorial-us-west1-PROJECT_ID> uses a disallowed location
   <us-west1>, allowed locations are ["asia-southeast1",
   "asia-southeast2"]): error when creating
   "tutorial-storagebucket-us-west1.yaml": admission webhook
   "validation.gatekeeper.sh" denied the request: [singapore-and-jakarta-only]
   Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a
   disallowed location <us-west1>, allowed locations are
   ["asia-southeast1", "asia-southeast2"]
   

3. Optional: Sie können einen Datensatz zur Entscheidung aufrufen, um die Anfrage in Cloud-Audit-Logs abzulehnen. Fragen Sie die Administratoraktivitätslogs für Ihr Projekt ab:

   gcloud logging read --limit=1 \
       "logName=\"projects/$GOOGLE_CLOUD_PROJECT/logs/cloudaudit.googleapis.com%2Factivity\""'
       resource.type="k8s_cluster"
       resource.labels.cluster_name="CLUSTER_NAME"
       resource.labels.location="ZONE"
       protoPayload.authenticationInfo.principalEmail!~"system:serviceaccount:cnrm-system:.*"
       protoPayload.methodName:"com.google.cloud.cnrm."
       protoPayload.status.code=7'
   

   Die Ausgabe sieht in etwa so aus:

   insertId: 3c6940bb-de14-4d18-ac4d-9a6becc70828
   labels:
     authorization.k8s.io/decision: allow
     authorization.k8s.io/reason: ''
     mutation.webhook.admission.k8s.io/round_0_index_0: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"container-annotation-handler.cnrm.cloud.google.com","mutated":true}'
     mutation.webhook.admission.k8s.io/round_0_index_1: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"management-conflict-annotation-defaulter.cnrm.cloud.google.com","mutated":true}'
   logName: projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   operation:
     first: true
     id: 3c6940bb-de14-4d18-ac4d-9a6becc70828
     last: true
     producer: k8s.io
   protoPayload:
     '@type': type.googleapis.com/google.cloud.audit.AuditLog
     authenticationInfo:
       principalEmail: user@example.com
     authorizationInfo:
     - permission: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
       resource: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
     methodName: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
     requestMetadata:
       callerIp: 203.0.113.1
       callerSuppliedUserAgent: kubectl/v1.21.1 (linux/amd64) kubernetes/5e58841
     resourceName: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
     serviceName: k8s.io
     status:
       code: 7
       message: Forbidden
   receiveTimestamp: '2021-05-21T06:56:24.940264678Z'
   resource:
     labels:
       cluster_name: CLUSTER_NAME
       location: CLUSTER_ZONE
       project_id: PROJECT_ID
     type: k8s_cluster
   timestamp: '2021-05-21T06:56:09.060635Z'

   Im Feld methodName wird der versuchte Vorgang angezeigt. resourceName zeigt den vollständigen Name der Config Connector-Ressource. Im Abschnitt status wird angezeigt, dass die Anfrage fehlgeschlagen ist, und zwar mit Fehlercode 7 und der Nachricht Forbidden

4. Erstellen Sie ein Manifest, das einen Cloud Storage-Bucket an einem zulässigen Standort darstellt (asia-southeast1):

   cat << EOF > tutorial-storagebucket-asia-southeast1.yaml
   apiVersion: storage.cnrm.cloud.google.com/v1beta1
   kind: StorageBucket
   metadata:
     name: tutorial-asia-southeast1-$GOOGLE_CLOUD_PROJECT
     namespace: NAMESPACE
   spec:
     location: asia-southeast1
     uniformBucketLevelAccess: true
   EOF
   

5. Zum Erstellen des Cloud Storage-Buckets wenden Sie das Manifest an:

   kubectl apply -f tutorial-storagebucket-asia-southeast1.yaml
   

   Die Ausgabe sieht in etwa so aus:

   storagebucket.storage.cnrm.cloud.google.com/tutorial-asia-southeast1-PROJECT_ID created
   

   Diese Ausgabe enthält PROJECT_ID. Dies ist Ihre Google Cloud-Projekt-ID.

6. Prüfen Sie, ob Config Connector den Cloud Storage-Bucket erstellt hat:

   gcloud storage ls | grep tutorial
   

   Die Ausgabe sieht in etwa so aus:

   gs://tutorial-asia-southeast1-PROJECT_ID/
   gs://tutorial-us-central1-PROJECT_ID/
   

   Wenn diese Ausgabe nicht angezeigt wird, warten Sie eine Minute und führen diesen Schritt noch einmal aus.

Audit-Einschränkungen

Der Audit-Controller in Policy Controller bewertet Ressourcen regelmäßig anhand ihrer Einschränkungen. Der Controller erkennt Richtlinienverstöße für Ressourcen, die vor der Einschränkung erstellt wurden, und für Ressourcen, die außerhalb von Config Connector erstellt wurden.

1. Sehen Sie sich in Cloud Shell die Verstöße für alle Einschränkungen an, die die Einschränkungsvorlage GCPStorageLocationConstraintV1 verwenden:

   kubectl get gcpstoragelocationconstraintv1 -o json \
     | jq '.items[].status.violations'
   

   Die Ausgabe sieht in etwa so aus:

   [
     {
       "enforcementAction": "deny",
       "kind": "StorageBucket",
       "message": "Cloud Storage bucket <tutorial-us-central1-PROJECT_ID>
       uses a disallowed location <us-central1>, allowed locations are
       \"asia-southeast1\", \"asia-southeast2\"",
       "name": "tutorial-us-central1-PROJECT_ID",
       "namespace": "NAMESPACE"
     }
   ]
   

   Sie sehen den Cloud Storage-Bucket, den Sie in us-central1 erstellt haben, bevor Sie die Einschränkung erstellt haben.

Ressourcen während der Entwicklung validieren

Während der Entwicklung und dem Aufbau von Continuous Integration sollten Sie Ressourcen mit Einschränkungen abgleichen, bevor Sie sie auf den GKE-Cluster anwenden. Die Validierung ermöglicht schnelles Feedback und die frühzeitige Erkennung von Problemen in Bezug auf Ressourcen und Einschränkungen. In diesen Schritten wird die Validierung von Ressourcen mit kpt beschrieben. Mit dem kpt-Befehlszeilentool können Sie Kubernetes-Ressourcenmanifeste verwalten und anwenden.

1. Führen Sie in Cloud Shell die KRM-Funktion gatekeeper mit kpt aus:

   kpt fn eval . --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false
   

   Eine KRM-Funktion ist ein Programm, mit dem sich im lokalen Dateisystem gespeicherte Kubernetes-Ressourcen als YAML-Dateien mutieren oder validieren lassen. Die KRM-Funktion gatekeeper validiert die Cloud Storage-Bucket-Ressourcen von Config Connector anhand der Gatekeeper-Richtlinie. Die KRM-Funktion gatekeeper ist als Container-Image verpackt, das in Artifact Registry verfügbar ist.

   Die Funktion meldet, dass die Manifestdateien für Cloud Storage-Buckets in den Regionen us-central1 und us-west1 gegen die Einschränkung verstoßen.

   Die Ausgabe sieht in etwa so aus:

   [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
   [FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
     Results:
       [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-central1.yaml"
       [ERROR] Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a disallowed location <us-west1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-west1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-west1.yaml"
     Stderr:
       "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
       "violatedConstraint: singapore-and-jakarta-only"
       ""
       "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-west1-PROJECT_IDT : Cloud Storage bucket <tutorial-us-west1-PROJECT_IDgt; uses a disallowed location <us-west1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
       "violatedConstraint: singapore-and-jakarta-only"
       ""
     Exit code: 1
   

Außerhalb von Config Connector erstellte Ressourcen validieren

Sie können Google Cloud-Ressourcen prüfen, die außerhalb von Config Connector erstellt wurden, indem Sie die Ressourcen exportieren. Verwenden Sie eine der folgenden Optionen, nachdem Sie die Ressourcen exportiert haben, um Ihre Policy Controller-Richtlinien für die exportierten Ressourcen zu prüfen:

• Validieren Sie die Ressourcen mit der KRM-Funktion gatekeeper.

• Importieren Sie die Ressourcen in Config Connector.

Verwenden Sie Cloud Asset Inventory, um die Ressourcen zu exportieren.

1. Aktivieren Sie die Cloud Asset API in Cloud Shell:

   gcloud services enable cloudasset.googleapis.com
   

2. Löschen Sie die Kubernetes-Ressourcenmanifestdateien für die Cloud Storage-Buckets in us-central1 und us-west1:

   rm tutorial-storagebucket-us-*.yaml
   

3. Exportieren Sie alle Cloud Storage-Ressourcen in Ihrem aktuellen Projekt und speichern Sie die Ausgabe in einer Datei mit dem Namen export.yaml:

   gcloud beta resource-config bulk-export \
     --project $GOOGLE_CLOUD_PROJECT \
     --resource-format krm \
     --resource-types StorageBucket > export.yaml
   

   Die Ausgabe sieht in etwa so aus:

   Exporting resource configurations to stdout...
   
   Export complete.
   

4. Erstellen Sie eine kpt-Pipeline, indem Sie KRM-Funktionen verketten. Diese Pipeline validiert die Ressourcen im aktuellen Verzeichnis anhand der Richtlinie für den Cloud Storage-Bucket-Speicherort:

   kpt fn source . \
     | kpt fn eval - --image=gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=NAMESPACE \
     | kpt fn eval - --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false
   

   Die exportierten Ressourcen haben keinen Wert für das Attribut namespace. Diese Pipeline verwendet eine KRM-Funktion mit dem Namen set-namespace, um den namespace-Wert aller Ressourcen festzulegen.

   Die Ausgabe sieht etwa so aus und zeigt Verstöße für die exportierten Ressourcen an:

   [RUNNING] "gcr.io/kpt-fn/set-namespace:v0.1"
   [PASS] "gcr.io/kpt-fn/set-namespace:v0.1"
   [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
   [FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
     Results:
       [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "export.yaml"
     Stderr:
       "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
       "violatedConstraint: singapore-and-jakarta-only"
       ""
     Exit code: 1
   

   Wenn Ihr Google Cloud-Projekt Cloud Storage-Buckets enthält, die Sie vor der Durcharbeitung dieser Anleitung erstellt haben und deren Standort gegen die Einschränkung verstößt, werden die zuvor erstellten Buckets in der Ausgabe angezeigt.

Sie haben erfolgreich eine Richtlinie eingerichtet, die den zugelassenen Standort von Cloud Storage-Buckets regelt. Die Anleitung ist abgeschlossen. Sie können jetzt Ihre eigenen Richtlinien für andere Google Cloud-Ressourcen hinzufügen.

Fehlerbehebung

Wenn Config Connector nicht die erwarteten Google Cloud-Ressourcen erstellt, rufen Sie mit dem folgenden Befehl in Cloud Shell die Logs des Config Connector-Controller-Managers auf:

kubectl logs --namespace cnrm-system --container manager \
  --selector cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE

Wenn Policy Controller die Richtlinien nicht ordnungsgemäß erzwingt, rufen Sie mit dem folgenden Befehl die Logs des Controller-Managers auf:

kubectl logs deployment/gatekeeper-controller-manager \
  --namespace gatekeeper-system

Wenn Policy Controller keine Verstöße im Feld status der Einschränkungsobjekte meldet, rufen Sie die Logs des Audit-Controllers mit folgendem Befehl auf:

kubectl logs deployment/gatekeeper-audit --namespace gatekeeper-system

Wenn Sie Probleme mit dieser Anleitung haben, empfehlen wir Ihnen, die folgenden Dokumente zu lesen:

• Fehlerbehebung für Config Connector
• Referenz für Config Connector-Ressourcen
• Fehlerbehebung für GKE
• Fehlerbehebung für Kubernetes-Cluster