Deklarative Mehrmandantenfähigkeit mit Projekt-Namespaces

In dieser Anleitung erfahren Sie, wie Sie mithilfe des Blueprints für einen Projekt-Namespace mit Config Controller einen dedizierten Namespace zum Verwalten von Google Cloud-Ressourcen in einem bestimmten Projekt erstellen. Wenn Sie ein Infrastrukturadministrator sind und zulassen möchten, dass Ihre internen Mandanten ihre Projektkonfiguration deklarativ 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.

Mit KRM-Blueprints können Sie Ressourcen, die häufig gemeinsam verwendet werden, verpacken und gleichzeitig Best Practices festlegen, die Sie in Ihrer gesamten 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 Blueprint von Projekt-Namespace können Sie einen oder mehrere Namespaces für Projekte einfach verwalten. Wenn Sie sich die manuellen Schritte mit gcloud command-line tool ansehen möchten, lesen Sie unter Config Connector für die Verwaltung von Ressourcen in Ihren Namespaces konfigurieren.

Ziele

  • Projekt-Namespace in Config Controller konfigurieren.
  • 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 Cloud SDK einschließlich des gcloud-Befehlszeilentools vorinstalliert ist. Die Werte sind bereits für Ihr aktuelles Projekt festgelegt. 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 Entwurf 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 Blueprint wird die Projekt-ID auch als Name des Projekt-Namespace verwendet.

  2. Wechseln Sie zum 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
    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, das Ihren Config Controller-Cluster enthält.

      Das Administratorprojekt wird zum Bootstrap von Workload Identity für Config Connector verwendet.

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

      Der Administrator-Namespace wird für das Bootstrapping der Config Connector-Arbeitslastidentität im Admin-Projekt 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 Elementen wie IAM-Richtlinien verwendet, sodass Mandanten mit Zugriff auf den Mandanten-Namespace ihre Berechtigungen nicht eskalieren können.

      Wenn Sie den Blueprint der Landingpage verwendet haben, sollten Sie bereits einen Namespace projects zum Verwalten von Projekten haben. Ist dies nicht der Fall, legen Sie für dieses Feld 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 Landing Zone-Blueprint verwendet haben, sollten Sie bereits einen Namespace networking zur Verwaltung freigegebener VPCs haben. Ist dies nicht der Fall, legen Sie für dieses Feld 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 ein Mandant Google Cloud-Projektressourcen in seinem Mandantenprojekt bereitstellen kann, erteilen Sie ihm die Berechtigung, den Mandantenprojekt-Namespace mit den folgenden Befehlen zu verwenden.

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