Richtlinienkonforme Google Cloud-Ressourcen erstellen

In dieser Anleitung erfahren Sie, wie Plattformadministratoren mit Richtlinien für Policy Controller steuern können, wie Google Cloud-Ressourcen mit Config Connector erstellt werden.

In der 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. Beschreibt diese als benutzerdefinierte Kubernetes-Ressourcen. 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

Wenn Sie Ihre Google Cloud-Ressourcen mit Config Connector verwalten, können Sie Policy Controller-Richtlinien auf diese Ressourcen anwenden, während Sie sie in Ihrem GKE-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 wird gezeigt, 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 GKE-Cluster erstellen, der das Add-on "Config Connector" 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.

Hinweis

  1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist

  3. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

  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 mit dem Namen 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. Erstellen Sie ein Verzeichnis zum Speichern der für diese Anleitung erstellten Dateien:

    mkdir -p ~/cnrm-gatekeeper-tutorial

  7. 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

    Dabei gilt:

    • 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 in Ihrer eigenen Umgebung einen privaten Cluster verwenden, fügen Sie eine Firewallregel hinzu, mit der die Steuerungsebene des GKE-Cluster 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

    Dabei gilt:

    • 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 Config Connector Controller-Pod 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:

    gsutil ls | grep tutorial

    Die Ausgabe sieht in etwa so aus:

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

    Diese Ausgabe enthält PROJECT_ID, 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. Wenn Sie die Zonen beschränken möchten, in denen Buckets vorhanden sein können, wenden Sie die Einschränkung an:

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

Richtlinie bestätigen

  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 in Cloud-Audit-Logs einen Datensatz zur Ablehnung der Anfrage aufrufen. 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 in etwa so aus:

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

    Diese Ausgabe enthält PROJECT_ID, 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 wertet regelmäßig Ressourcen anhand seiner 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, das Kubernetes-Ressourcen modifizieren oder validieren kann, die im lokalen Dateisystem als YAML-Dateien gespeichert sind. 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 Container 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 in etwa so aus und enthält Verstöße für die exportierten Ressourcen:

    [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 Ausführung dieser Anleitung erstellt haben, und deren Speicherort 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, verwenden Sie in Cloud Shell den folgenden Befehl, um die Logs des Config Connector-Controller-Managers anzusehen:

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 Richtlinien nicht korrekt durchsetzt, können Sie mit dem folgenden Befehl die Logs des Controller-Managers ansehen:

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

Wenn Policy Controller keine Verstöße im Feld status der Einschränkungsobjekte meldet, rufen Sie mit dem folgenden Befehl die Logs des Audit-Controllers 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. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wenn das Projekt, das Sie löschen möchten, an eine Organisation geknüpft ist, maximieren Sie in der Spalte Name die Liste Organisation.
  3. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  4. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

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 repräsentieren:

    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