Policy Controller in einer CI-Pipeline verwenden

Auf dieser Seite wird beschrieben, wie Sie Policy Controller in Cloud Build integrieren, indem Sie eine CI-Pipeline (Continuous Integration) erstellen, die die mit einem Git-Repository synchronisierten Richtlinienüberprüfungen überprüft.

Wenn Sie Entwickler sind und Ihre Anwendung mit den Unternehmensrichtlinien validieren möchten, lesen Sie stattdessen Anwendungsrichtlinien in einer CI-Pipeline validieren.

Einführung

Durch Erstellen einer CI-Pipeline mit Policy Controller können Sie:

  • Erzwingen Sie definierte Richtlinienkonfigurationen und geben Sie Entwicklern so schnell wie möglich Feedback. Mithilfe von Richtlinien können Plattformadministratoren den Zugriff sperren. Entwicklungsteams müssen diese Richtlinien dann einhalten, anstatt sie zu entfernen oder zu umgehen.

  • Legen Sie Standardfelder für Ihre Kubernetes-Objekte fest, die immer vorhanden sein sollen. Beispielsweise können Sie automatisch Etiketten für Eigentümer oder Kostenstellen hinzufügen.

Dieses Dokument konzentriert sich auf eine Cloud Build CI-Pipeline, die ein GitHub-Konfigurationsrepository verwendet. Sie können dasselbe Muster verwenden, um andere CI-Tools oder Versionskontrollsysteme einzurichten, die von Anthos Config Management unterstützt werden.

Diese Pipeline wird mit KPT-Funktionen erstellt. Mit KPT-Funktionen können Sie clientseitige Container-Images entwickeln, um Kubernetes-Konfigurationen zu validieren, zu transformieren oder zu generieren.

In diesem Thema werden vorgefertigte KPT-Funktionen aus dem KPT-Funktionskatalog verwendet. Eine Teilmenge der Funktionen im Katalog wurde in eine von Google unterstützte Containerregistrierung gespiegelt und steht allen Projekten zur Verfügung.

Hinweis

  • Sie benötigen eine Anthos-Berechtigung, um Policy Controller mithilfe von Anthos Config Management zu installieren.

  • Sie benötigen einen Cluster, in dem Anthos Config Management bereits installiert ist.

  • Richten Sie Policy Controller ein.

  • Haben Sie die Berechtigung serviceusage.services.enable für Ihr Google Cloud-Projekt und die Berechtigung servicemanagement.services.bind für die Cloud Build-API. Diese Berechtigungen sind erforderlich, um das Cloud Build-Dienstkonto zu aktivieren. Weitere Informationen finden Sie unter Aktivieren von APIs.

  • Aktivieren Sie Cloud Build in Ihrem Projekt. Dies ist über die Google Cloud Console möglich.

Unstrukturiertes Repository verwenden

Dieses Tutorial enthält die Option, ein unstrukturiertes -Repository zu verwenden. Unstrukturierte Repositorys erfordern nicht die Standardverzeichnisstruktur von Anthos Config Management .

Cloud Build konfigurieren

Sie müssen dem Cloud Build-Dienstkonto in jedem Projekt, in dem Sie die Pipeline konfigurieren, die Rolle "Kubernetes Engine Developer" zuweisen.

  1. Zur Seite mit den Cloud Build-Einstellungen

    Die Seite Dienstkontoberechtigungen wird angezeigt.

  2. Suchen Sie die Zeile mit Kubernetes Engine und setzen Sie den Status auf Aktiviert.

Weitere Informationen finden Sie unter Festlegen der Berechtigungen für Dienstkonten.

Umgebung einrichten

Informationen zum Konfigurieren von Policy Controller für die Verwendung mit Cloud Build finden Sie im Beispiel Git-Repo.

Klonen Sie das Repository mit git.

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

Wenn Sie ein hierarchisches Repository verwenden, müssen Sie die Konfigurationsdateien in diesem Repository nach dem Einrichten von Cloud Build bearbeiten.

Verzeichnisstruktur

Im Repository csp-config-management gibt es zwei Verzeichnisse, die Konfigurationen für ein hierarchisches Repository (ci-pipeline/) und ein unstrukturiertes Repository (ci-pipeline-unstructured/) enthalten. Wählen Sie das entsprechende Verzeichnis für Ihren Clustertyp.

Die Verzeichnisse ci-pipeline/ und ci-pipeline-unstructured/ im Repository verwenden die folgende Hierarchie:

  • config-root/ ist die Wurzel des Repositorys und enthält alle Konfigurationen für dieses Beispiel.

  • config-root/.../*-constraint.yaml und *-template.yaml definieren Policy Controller-Einschränkungen und -Vorlagen, die alle Konfigurationen in config-root/ erfüllen müssen.

    Beispiel:

    • Die Datei ci-pipeline/config-root/cluster/required-labels-constraint.yaml erfordert, dass jeder Namespace eine cost-center Bezeichnung hat.

    • Die Datei ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml erzwingt, dass keine ConfigMap-Objekte ein Feld mit dem Namen private-key enthalten.

    Weitere Informationen finden Sie unter Erstellen von Einschränkungen.

  • cloudbuild.yaml ist die Cloud Build-Konfigurationsdatei, die Buildschritte definiert. Diese Build-Schritte werden durch ein Commit für das Repository ausgelöst.

    Mithilfe eines hierarchischen Repositorys erstellt die Pipeline den Inhalt Ihres Repositorys mit nomos hydrate, verkettet sie und validiert sie mit Policy Controller.

    In einem unstrukturierten Repository erstellt Policy Controller Ihre Konfiguration, ohne nomos zu verwenden oder eine Verbindung zu Ihrem Cluster herzustellen.

    Weitere Informationen zum Inhalt einer Konfigurationsdatei finden Sie unter Erstellen einer Grundkonfiguration.

Cloud Build konfigurieren

In diesem Abschnitt verbinden Sie Cloud Build mit Ihrem Quell-Repository, damit Cloud Build den Code in diesem Repository erstellen kann.

Build-Trigger erstellen

Cloud Build führt Build-Trigger aus, wenn ein Commit an den Zweig gesendet wird. Führen Sie die folgenden Schritte aus, um einen Build-Trigger in der Google Cloud Console zu konfigurieren.

  1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

    Zur Seite "Trigger"

  2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

  3. Klicken Sie auf Öffnen.

  4. Klicken Sie auf Trigger erstellen.

  5. Erstellen Sie einen Namen für Ihren Trigger.

  6. Wählen Sie für Ereignis Push to a branch.

  7. Wählen Sie Ihr Repository aus. Wenn Sie Ihr Repository nicht verbunden haben, führen Sie die folgenden Schritte aus:

    1. Klicken Sie auf Repository verbinden.

    2. Wählen Sie das Repository aus, in dem Sie den Quellcode gespeichert haben.

      Wenn Sie GitHub (gespiegelt) oder Bitbucket (gespiegelt) als Quell-Repository auswählen, spiegelt Cloud Build Ihr Repository in Cloud-Quell-Repositorys und verwendet das gespiegelte Repository.

    3. Klicken Sie auf Weiter.

    4. Authentifizieren Sie sich mit Ihrem Nutzernamen und Passwort in Ihrem Quell-Repository.

    5. Wählen Sie aus der Liste der verfügbaren Repositorys das gewünschte Repository aus und klicken Sie auf Repository verbinden.

  8. Wählen Sie aus der Liste der verfügbaren Repositorys das Repository csp-config-management aus.

  9. Wählen Sie Ihren Zweig, master.

  10. Legen Sie unter Build-Konfiguration Ihre Cloud-Build-Konfigurationsdatei als ci-pipeline/cloudbuild.yaml oder ci-pipeline-unstructured/cloudbuild.yaml fest.

  11. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

Sie können Build-Trigger auch mit gcloud erstellen. Weitere Informationen finden Sie unter Erstellen und Verwalten von Build-Triggern.

Konfigurieren Sie Ihr Repository

Nachdem Cloud Build für die Verbindung mit Ihrem Repository konfiguriert wurde, schließen Sie Ihre Konfiguration für Anthos Config Management ab.

  1. Bearbeiten Sie die Datei csp-config-management/CODEOWNERS und ersetzen Sie @OWNER durch Ihren GitHub-Nutzernamen oder den E-Mail-Alias des Plattformadministratoren-Teams. Weitere Informationen zur CODEOWNERS-Syntax finden Sie unter Informationen zu Codebesitzern.

Wählen Sie unten aus, ob Sie ein hierarchisches (Standard) oder ein unstrukturiertes Repository verwenden.

  1. Konfigurationsdatei bearbeiten

    Hierarchisch

    Bearbeiten Sie die Datei csp-config-management/ci-pipeline/cloudbuild.yaml.

    Ersetzen Sie CLUSTER_NAME und ZONE durch den Clusternamen und die Zone eines GKE-Clusters mit installiertem Anthos Config Management und Policy Controller.

    Unstrukturierte

    In diesem Beispiel ist bei einem unstrukturierten Repository keine Konfigurationsänderung erforderlich. Anthos Config Management und Policy Controller validieren Ihr Repository, ohne eine Verbindung zu Ihrem Cluster herzustellen.

  2. Fügen Sie Ihre Änderungen hinzu und übernehmen Sie sie für das Repository.

    Hierarchisch

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Unstrukturierte

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Nach dem Festschreiben führt Cloud Build eine Richtlinienüberprüfung für das Repository durch.

  3. Öffnen Sie Ihren Cloud Build-Verlauf und klicken Sie auf den neuesten Build.

    Die Seite Build Details wird angezeigt.

  4. Das Beispiel im csp-config-management Repository enthält einen Fehler

    Wählen Sie den neuesten Build oben in der Liste aus, der das Symbol enthält.

  5. Der letzte Schritt, den Cloud Build ausführt, wird mit einem Fehler beendet. Der Fehler folgt.

    Hierarchisch

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    Unstrukturierte

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. Beheben Sie als Nächstes den Fehler, indem Sie eine Datei in Ihrem Repository bearbeiten.

    Hierarchisch

    Bearbeiten Sie die Datei /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml und legen Sie einen Wert für metadata.labels.cost-center fest. Ihr namespace.yaml sollte so aussehen:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    Unstrukturierte

    Bearbeiten Sie die Datei /ci-pipeline-unstructured/config-root/configmap.yaml. Ändern Sie das Feld data.private_key in data.public_key. Ihre bearbeitete YAML sieht folgendermaßen aus.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    Übernehmen Sie als Nächstes Ihre Änderungen und übertragen Sie sie.

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. Öffnen Sie Ihren Cloud Build-Verlauf und klicken Sie auf den neuesten Build.

    Die Seite Build Details wird angezeigt.

  8. Ihr neuer Build sollte Erfolgreich sein.

Fehlerbehebung

Problem: Mein Cloud Build-Build schlägt fehl und der Verlauf enthält den folgenden Fehler.

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

Lösung: Bestätigen Sie Ihre Installation von Policy Controller.

Nächste Schritte