Deklarative Mehrmandantenfähigkeit mit Projekt-Namespaces

In dieser Anleitung erfahren Sie, wie Sie mit dem Blueprint "Projekt-Namespace" mit Config Controller einen dedizierten Blueprint zum Verwalten von Google Cloud-Ressourcen in einem bestimmten Projekt erstellen. Wenn Sie Infrastrukturadministrator sind und Ihren internen Mandanten die Möglichkeit geben möchten, ihre Projektkonfiguration deklarativ zu verwalten, folgen Sie der Anleitung.

Config Controller ist ein gehosteter Dienst zur Bereitstellung und Orchestrierung von Anthos- und Google Cloud-Ressourcen. Diese Komponente bietet einen API-Endpunkt, der Google Cloud-Ressourcen als Teil von Anthos Config Management bereitstellen, aktivieren und orchestrieren kann.

KRM-Blueprints sind eine Möglichkeit zum Verpacken von Ressourcen, die häufig zusammen verwendet werden, während Best Practices codiert werden, die Sie in Ihrer Organisation einführen können.

Config Controller-Projekt-Namespace
Config Controller-Projekt-Namespace

Der Projekt-Namespace-Blueprint ist ein KRM-Blueprint, der alle Ressourcen enthält, die Sie zum Bereitstellen eines Namespace in Config Controller benötigen, in dem Sie oder ein Mandant Google Cloud-Projektressourcen verwalten können. Sie können den Blueprint mehrmals instanziieren, um mehrere Projekt-Namespaces einzurichten.

Mit dem Entwurf des Projekt-Namespace können Sie einen oder mehrere Namespaces für Projekte einfach verwalten. Wenn Sie aber die manuellen Schritte mit Google Cloud CLI ansehen möchten, lesen Sie Config Connector zum Verwalten von Ressourcen in Namespaces konfigurieren.

Ziele

  • Konfigurieren Sie einen Projekt-Namespace in Config Controller.
  • Wenden Sie die Konfiguration mit kpt live apply an.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Eine vollständige Liste der im Projekt-Namespace-Blueprint enthaltenen Ressourcen finden Sie im Abschnitt „Ressourcen“ des Project Namespace-Blueprint-Paket.

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.

Voraussetzungen

Hinweis

  1. Aktivieren Sie Cloud Shell in der Cloud Console.

    Cloud Shell aktivieren

    Unten in der Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Führen Sie alle Befehle in dieser Anleitung in Cloud Shell aus.

Umgebung einrichten

Führen Sie in Cloud Shell die folgenden Befehle aus:

  1. Installieren Sie kubectl, das Befehlszeilentool für Kubernetes:

    gcloud components install kubectl
    
  2. Installieren Sie kpt, die primäre Befehlszeile für KRM-Blueprints:

    gcloud components install kpt
    
  3. Konfigurieren Sie kubectl und kpt für die Verbindung mit Config Controller:

    gcloud alpha anthos config controller get-credentials INSTANCE_NAME \
        --location COMPUTE_REGION \
        --project ADMIN_PROJECT_ID
    

    Dabei gilt:

    • INSTANCE_NAME: der Name Ihrer Config Controller-Instanz.

    • COMPUTE_REGION: Die Region Ihrer Config Controller-Instanz, z. B. us-central1.

    • ADMIN_PROJECT_ID: die Projekt-ID Ihres Config Controller-Clusters

  4. Aktivieren Sie die Resource Manager API:

    Die Resource Manager API wird von Config Connector verwendet, um die Aktivierung anderer Dienst-APIs zu verwalten.

    gcloud services enable cloudresourcemanager.googleapis.com \
        --project TENANT_PROJECT_ID
    

    Ersetzen Sie TENANT_PROJECT_ID durch die ID Ihres Mandantenprojekts.

  5. Installieren Sie die ResourceGroup-CRD, falls noch nicht geschehen:

    kpt live install-resource-group
    
  6. Prüfen Sie, ob Config Connector im config-control-Namespace konfiguriert und fehlerfrei ist:

    kubectl get ConfigConnectorContext -n config-control \
        -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"
    

    Erwartete Ausgabe:

    NAMESPACE        NAME                                                HEALTHY
    config-control   configconnectorcontext.core.cnrm.cloud.google.com   true
    
  7. Erteilen Sie Config Controller die Berechtigung zum Verwalten von Google Cloud-Ressourcen im Projekt:

    export TENANT_PROJECT_ID=TENANT_PROJECT_ID
    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
        -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    gcloud projects add-iam-policy-binding "${TENANT_PROJECT_ID}" \
        --member "serviceAccount:${SA_EMAIL}" \
        --role "roles/owner" \
        --project "${TENANT_PROJECT_ID}"
    

Projekt-Namespace konfigurieren

Führen Sie die folgenden Befehle aus, um einen Projekt-Namespace zu erstellen, in dem Ressourcen für ein anderes Projekt verwaltet werden.

  1. Rufen Sie den Blueprint des Projekt-Namespace mit kpt aus dem gewünschten Arbeitsverzeichnis ab:

    kpt pkg get \
        https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project/kcc-namespace@main \
        TENANT_PROJECT_ID
    

    Ersetzen Sie TENANT_PROJECT_ID durch die ID Ihres Mandantenprojekts.

    In diesem Entwurf wird auch die Projekt-ID als Name des Projekt-Namespace verwendet.

  2. Wechseln Sie in das Paketverzeichnis:

    cd ./TENANT_PROJECT_ID/
    
  3. Konfigurieren Sie das Paket. Ändern Sie dazu die Datei setters.yaml:

    cat > setters.yaml << EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      project-id: TENANT_PROJECT_ID
      management-project-id: ADMIN_PROJECT_ID
      management-namespace: ADMIN_NAMESPACE
      projects-namespace: PROJECTS_NAMESPACE
      networking-namespace: NETWORKING_NAMESPACE
    EOF
    

    Dabei gilt:

    • ADMIN_PROJECT_ID ist die ID des Projekts, in dem der Config Controller-Cluster enthalten ist.

      Das Administratorprojekt wird zum Bootstrapping von Config Connector Workload Identity verwendet.

    • ADMIN_NAMESPACE: der Namespace, der zum Verwalten von Projekt-Namespaces verwendet werden soll (z. B. config-control).

      Der Administrator-Namespace wird zum Bootstrapping von Config Connector Workload Identity im Administratorprojekt verwendet.

    • PROJECTS_NAMESPACE: der Namespace, der zum Verwalten von Projektberechtigungen verwendet werden soll (z. B. config-control).

      Der Namespace des Projekts wird zum Verwalten von IAM-Richtlinien verwendet, sodass Mandanten mit Zugriff auf den Mandanten-Namespace ihre Berechtigungen nicht eskalieren können.

      Wenn Sie den Landing Zone-Blueprint verwendet haben, sollten Sie bereits einen projects-Namespace zur Verwaltung von Projekten haben. Andernfalls legen Sie config-control fest.

    • NETWORKING_NAMESPACE: der Namespace, der zur Verwaltung freigegebener VPCs verwendet wird (z. B. config-control).

      Dadurch können Sie Namespace-übergreifende Ressourcenreferenzen verwenden, wenn Sie das zu verwendende Netzwerk oder Subnetz auswählen.

      Wenn Sie den Entwurf der Landing Zone verwendet haben, sollten Sie bereits einen networking-Namespace zum Verwalten von freigegebenen VPCs haben. Andernfalls legen Sie config-control fest.

  4. Rendern Sie die Setter-Werte in den vorlagenbasierten Ressourcen:

    kpt fn render
    

    Beispielausgabe:

    Package "example-1234":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
      Results:
        [INFO] set field value to "cnrm-network-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "kcc-namespace-viewer.yaml" in field "metadata.namespace"
        [INFO] set field value to "cnrm-controller-manager-example-1234" in file "kcc-namespace-viewer.yaml" in field "subjects[0].name"
        [INFO] set field value to "cnrm-project-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name"
        ...(20 line(s) truncated, use '--truncate-output=false' to disable)
    
    Successfully executed 1 function(s) in 1 package(s).
    

Mandantenberechtigungen konfigurieren

Damit Mandanten Google Cloud-Projektressourcen in ihrem Mandantenprojekt bereitstellen können, müssen Sie Ihnen die Berechtigung zum Verwenden des Mandantenprojekt-Namespace erteilen. Führen Sie dazu folgende Befehle aus:

  1. Erstellen Sie eine project-admin.yaml-Datei mit folgendem RoleBinding:

    cat > project-admin.yaml << EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: project-admin
      namespace: TENANT_PROJECT_ID
    roleRef:
      kind: ClusterRole
      name: cnrm-admin
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: User
      name: TENANT_EMAIL
      apiGroup: rbac.authorization.k8s.io
    EOF
    

    Ersetzen Sie TENANT_EMAIL durch die E-Mail-Adresse des Google Cloud-Nutzerkontos für Mandanten, z. B. janedoe@example.com.

    Mit der Rolle cnrm-admin kann der Mandant Config Connector-Ressourcen im Projekt-Namespace erstellen.

    Weitere Informationen zum Autorisieren einer Gruppe oder eines Dienstkontos finden Sie unter Rollen mithilfe von RoleBinding- oder ClusterRoleBinding-Objekten zuweisen.

Konfigurationsänderungen anwenden

Lokale Änderungen in den vorherigen Schritten wirken sich erst auf die Cloud aus, wenn sie angewendet werden.

Führen Sie die folgenden Befehle aus, um Ihre Konfigurationsänderungen anzuwenden.

  1. Initialisieren Sie das Arbeitsverzeichnis mit kpt, das eine Ressource erstellt, um Änderungen verfolgen zu können:

    kpt live init --namespace ADMIN_NAMESPACE
    

    Ersetzen Sie ADMIN_NAMESPACE durch den Namespace, der zum Verwalten der Projekt-Namespaces verwendet wird, z. B. config-control.

  2. Sehen Sie sich die erstellen Ressourcen in der Vorschau an:

    kpt live apply --dry-run
    

    Alle Ressourcen sollten mit "Erstellt (Probelauf)" versehen sein.

    Beispielausgabe:

    namespace/example-1234 created (dry-run)
    rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created (dry-run)
    rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created (dry-run)
    rolebinding.rbac.authorization.k8s.io/project-admin created (dry-run)
    configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created (dry-run)
    iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created (dry-run)
    iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created (dry-run)
    iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 created (dry-run)
    8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed (dry-run)
    0 resource(s) pruned, 0 skipped, 0 failed (dry-run)
    
  3. Wenden Sie die Ressourcen mit kpt an:

    kpt live apply
    

    Alle Ressourcen sollten "Erstellt" versehen sein.

    Beispielausgabe:

    namespace/example-1234 created
    rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created
    rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created
    rolebinding.rbac.authorization.k8s.io/project-admin created
    configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created
    iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created
    iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created
    iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 created
    8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed
    0 resource(s) pruned, 0 skipped, 0 failed
    

Ergebnis prüfen

Mit den folgenden Befehlen prüfen Sie, ob die Änderungen angewendet wurden und ob die von ihnen angegebenen Ressourcen bereitgestellt werden:

  1. Warten Sie, bis die Ressourcen bereit sind:

    kpt live status --output table --poll-until current
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Current und die Bedingung Ready oder <None> haben (für Ressourcen, die die Bereitschaftsbedingung nicht unterstützen). Ready ist grün, wenn "Ready=true", und rot, wenn "Ready=false".

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

    Beispielausgabe:

    NAMESPACE   RESOURCE                                  STATUS      CONDITIONS                                AGE     MESSAGE
                Namespace/example-1234                    Current     <None>                                    13s     Resource is current
    config-con  IAMPartialPolicy/example-1234-sa-workloa  Current     Ready                                     11s     Resource is Ready
    config-con  IAMPartialPolicy/kcc-example-1234-owners  Current     Ready                                     11s     Resource is Ready
    config-con  IAMServiceAccount/kcc-example-1234        Current     Ready                                     11s     Resource is Ready
    config-con  RoleBinding/cnrm-network-viewer-example-  Current     <None>                                    13s     Resource is current
    config-con  RoleBinding/cnrm-project-viewer-example-  Current     <None>                                    12s     Resource is current
    example-12  ConfigConnectorContext/configconnectorco  Current     <None>                                    12s     Resource is current
    example-12  RoleBinding/project-admin                 Current     <None>                                    12s     Resource is current
    
  2. Wenn ein Fehler auftritt, verwenden Sie die Standardereignisausgabe, um die vollständigen Fehlermeldungen zu sehen:

    kpt live status
    

Bereinigen

Wenn Sie Config Controller nicht mehr verwenden möchten, sollten Sie zuerst alle mit Config Controller erstellten Ressourcen bereinigen und dann Config Controller selbst löschen.

  1. Löschen Sie die Ressourcen mit kpt aus dem Arbeitsverzeichnis:

    kpt live destroy
    
  2. Warten Sie, bis alle Ressourcen gelöscht wurden:

    until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
    do sleep 1; done
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Deleted haben.

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

Nächste Schritte