Richtlinienkonforme Google Cloud-Ressourcen erstellen

In dieser Anleitung wird gezeigt, wie Plattformadministratoren Policy Controller-Richtlinien verwenden können, um zu steuern, wie Google Cloud -Ressourcen mit Config Connector erstellt werden.

Diese Seite richtet sich an IT-Administratoren und -Betreiber, die dafür sorgen möchten, dass alle auf der Cloud-Plattform ausgeführten Ressourcen die Compliance-Anforderungen des Unternehmens erfüllen. Dazu stellen sie Automatisierungsfunktionen zur Prüfung oder Durchsetzung bereit und verwalten den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur. 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.

In dieser Anleitung wird davon ausgegangen, dass Sie Grundkenntnisse in Kubernetes oder Google Kubernetes Engine (GKE) haben. In dieser Anleitung definieren Sie eine Richtlinie, die zulässige Standorte für Cloud Storage-Buckets einschränkt.

Policy Controller kontrolliert, überprüft und erzwingt die Einhaltung von Richtlinien in Bezug auf Sicherheit, Vorschriften oder Geschäftsregeln durch Ihre Kubernetes-Cluster-Ressourcen. Policy Controller basiert auf dem Open-Source-Projekt OPA Gatekeeper.

Config Connector erstellt und verwaltet den Lebenszyklus von Google Cloud -Ressourcen, indem es sie als benutzerdefinierte Kubernetes-Ressourcen beschreibt. Wenn Sie eine Google Cloud -Ressource erstellen möchten, erstellen Sie eine Kubernetes-Ressource in einem von Config Connector verwalteten Namespace. Das folgende Beispiel zeigt, wie ein Cloud Storage-Bucket mit Config Connector beschrieben wird:

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: us-east1

Durch das Verwalten Ihrer Google Cloud Ressourcen mit Config Connector können Sie Policy Controller-Richtlinien auf diese Ressourcen anwenden, während Sie sie in Ihrem Google Kubernetes Engine-Cluster erstellen. Mit diesen Richtlinien können Sie Aktionen verhindern oder melden, die Ressourcen auf eine Weise erstellen, die gegen Ihre Richtlinien verstößt. Sie können beispielsweise eine Richtlinie erzwingen, die die Standorte von Cloud Storage-Buckets einschränkt.

Dieser Ansatz basiert auf dem Kubernetes-Ressourcenmodell (KRM) und ermöglicht die Verwendung konsistenter Tools und Workflows zum Verwalten von Kubernetes- und Google Cloud -Ressourcen. In dieser Anleitung erfahren Sie, wie Sie die folgenden Aufgaben ausführen:

  • Richtlinien für die Regelung Ihrer Google Cloud Ressourcen definieren.
  • Steuerelemente implementieren, die Entwickler und Administratoren daran hindern, Google Cloud -Ressourcen zu erstellen, die gegen Ihre Richtlinien verstoßen.
  • Steuerelemente implementieren, mit denen Ihre vorhandenen Google Cloud -Ressourcen anhand Ihrer Richtlinien geprüft werden, auch wenn Sie diese Ressourcen außerhalb von Config Connector erstellt haben.
  • Entwicklern und Administratoren beim Erstellen und Aktualisieren von Ressourcendefinitionen schnell Feedback geben können.
  • Google Cloud -Ressourcendefinitionen anhand Ihrer Richtlinien validieren, bevor die Definitionen auf einen Kubernetes-Cluster angewendet werden.

GKE-Cluster erstellen

  1. Erstellen Sie in Cloud Shell einen GKE-Cluster mit dem Add-on "Config Connector" und 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 (CRDs) 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, umGoogle Cloud -Ressourcen im selben Projekt wie Ihren 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. Wenden Sie das Manifest an, um den Cloud Storage-Bucket zu erstellen:

    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 etwa so aus:

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

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

    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 überprü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. Wenden Sie das Manifest an, um den Cloud Storage-Bucket zu erstellen:

    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. Wenden Sie das Manifest an, um den Cloud Storage-Bucket zu erstellen:

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

    Die Ausgabe sieht etwa so aus:

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

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

  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.

Einschränkungen prüfen

Der Audit-Controller in Policy Controller wertet Ressourcen regelmäßig anhand ihrer Einschränkungen aus. 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 prüfen

Sie können Google Cloud -Ressourcen, die außerhalb von Config Connector erstellt wurden, prüfen, 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 in 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 richtig 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: