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.

Bei den Anleitungen 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 sie als benutzerdefinierte Kubernetes-Ressourcen beschrieben werden. Um eine Google Cloud-Ressource zu erstellen, 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 Verwalten Ihrer Google Cloud-Ressourcen mit Config Connector können Sie Policy Controller-Richtlinien auf diese Ressourcen anwenden, während Sie sie in Ihrem GKE Enterprise Edition-Cluster (Google Kubernetes Engine) 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 wird beschrieben, 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.

Lernziele

  • Einen Google Kubernetes Engine (GKE) Enterprise Edition-Cluster erstellen, der das Config Connector-Add-on enthält
  • Policy Controller installieren
  • Eine Richtlinie zur Beschränkung der zulässigen Cloud Storage-Bucket-Standorte erstellen
  • Prüfen, ob die Richtlinie das Erstellen von Cloud Storage-Buckets an nicht zulässigen Standorten verhindert
  • Cloud Storage-Bucketdefinition während der Entwicklung auf Compliance mit den Richtlinien prüfen
  • Vorhandene Cloud Storage-Buckets auf Compliance mit den Richtlinien prüfen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweise

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  4. Legen Sie in Cloud Shell das Google Cloud-Projekt fest, das Sie für diese Anleitung verwenden möchten:

    gcloud config set project PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID Ihres Projekts. Wenn Sie diesen Befehl ausführen, erstellt Cloud Shell eine exportierte Umgebungsvariable namens GOOGLE_CLOUD_PROJECT, die Ihre Projekt-ID enthält. Wenn Sie Cloud Shell nicht verwenden, können Sie mit dem folgenden Befehl die Umgebungsvariable erstellen:

    export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)
    
  5. Aktivieren Sie die GKE API:

    gcloud services enable container.googleapis.com
    
  6. Aktivieren Sie die Policy Controller API:

    gcloud services enable anthospolicycontroller.googleapis.com
    
  7. Erstellen Sie ein Verzeichnis zum Speichern der für diese Anleitung erstellten Dateien:

    mkdir -p ~/cnrm-gatekeeper-tutorial
    
  8. Gehen Sie zum von Ihnen erstellten Verzeichnis:

    cd ~/cnrm-gatekeeper-tutorial
    

GKE-Cluster erstellen

  1. Erstellen Sie in Cloud Shell einen GKE-Cluster mit dem Add-on "Config Connector" und Workload Identity:

    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:

    gsutil 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:

    gsutil 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:

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. If the project that you plan to delete is attached to an organization, expand the Organization list in the Name column.
  3. In the project list, select the project that you want to delete, and then click Delete.
  4. In the dialog, type the project ID, and then click Shut down to delete the project.

Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Google Cloud-Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen.

  1. Löschen Sie in Cloud Shell die Cloud Storage-Bucket-Standorteinschränkung:

    kubectl delete -f tutorial-storagebucket-location-constraint.yaml
    
  2. Fügen Sie die Annotation cnrm.cloud.google.com/force-destroy mit dem Stringwert true zu allen storagebucket-Ressourcen im Namespace hinzu, der von Config Connector verwaltet wird.

    kubectl annotate storagebucket --all --namespace NAMESPACE \
      cnrm.cloud.google.com/force-destroy=true
    

    Diese Annotation ist eine Anweisung, mit der Config Connector einen Cloud Storage-Bucket löschen kann, wenn Sie die entsprechende storagebucket-Ressource im GKE-Cluster löschen, auch wenn der Bucket Objekte enthält.

  3. Löschen Sie die Config Connector-Ressourcen, die die Cloud Storage-Buckets darstellen:

    kubectl delete --namespace NAMESPACE storagebucket --all
    
  4. Löschen Sie den GKE-Cluster:

    gcloud container clusters delete CLUSTER_NAME \
      --zone ZONE --async --quiet
    
  5. Löschen Sie die Workload Identity-Richtlinienbindung in IAM:

    gcloud iam service-accounts remove-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
    
  6. Löschen Sie die Bindung der Cloud Storage-Administratorrolle für das Google-Dienstkonto:

    gcloud projects remove-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
      --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com" \
      --role roles/storage.admin
    
  7. Löschen Sie das Google-Dienstkonto, das Sie für Config Connector erstellt haben:

    gcloud iam service-accounts delete --quiet \
      SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
    

Nächste Schritte