Anwendung in einer Continuous Integration-Pipeline anhand von Unternehmensrichtlinien validieren

Wenn Ihre Organisation mit Anthos Config Management und Policy Controller Richtlinien in ihren Anthos-Clustern verwaltet, können Sie die Bereitstellungskonfiguration einer Anwendung in der Continuous Integration (CI) -Pipeline prüfen. In dieser Anleitung wird gezeigt, wie Sie dieses Ergebnis erzielen. Dies ist nützlich, wenn Sie als Entwickler eine CI-Pipeline für eine Anwendung erstellen oder eine Plattformentwickler eine CI-Pipeline-Vorlage für mehrere App-Teams erstellt haben.

Richtlinien sind ein wichtiger Bestandteil der Sicherheit und Compliance einer Organisation. Policy Controller, das Teil von Anthos Config Management ist, ermöglicht Ihrer Organisation, diese Richtlinien zentral und deklarativ für alle Cluster zu verwalten. Als Entwickler können Sie diese Richtlinien zentral und deklarativ nutzen. Sie können diese Eigenschaften verwenden, um Ihre Anwendung so früh wie möglich im Entwicklungsworkflow zu validieren. Das Lernen über Richtlinienverletzungen in Ihrer CI-Pipeline statt im Rahmen der Bereitstellung bietet zwei Hauptvorteile: Sie können bei der Sicherheit nach links fahren und die Feedback-Loop verkürzen und die Zeit und Kosten für die Behebung dieser Verstöße reduzieren.

Wenn Sie für Anthos Config Management und Policy Controller zuständig sind und eine CI-Pipeline für sie (und nicht für eine bestimmte Anwendung) erstellen möchten, finden Sie weitere Informationen unter Policy Controller in einer CI-Pipeline verwenden.

In dieser Anleitung wird Cloud Build als CI-Tool und ein Beispiel für ein GitHub-Repository mit Richtlinien für Demos verwendet.

Ressourcen

In dieser Anleitung werden verschiedene Tools aus dem Kubernetes-.kosystem verwendet. In diesem Abschnitt wird erläutert, was diese Tools sind, wie sie miteinander interagieren und ob Sie sie durch andere Elemente ersetzen können. In dieser Anleitung werden folgende Tools verwendet:

  • Policy Controller: Policy Controller ist ein Google Cloud-Produkt, das zu Anthos Config Management gehört. Es basiert auf dem Open-Source-Projekt Open Policy Agent – Gatekeeper. Policy Controller erzwingt Richtlinien für die Objekte, die in einem Kubernetes-Cluster erstellt werden, z. B. verhindert die Verwendung einer bestimmten Option oder die Verwendung eines bestimmten Labels. Diese Richtlinien werden als Einschränkungen bezeichnet. Einschränkungen werden als benutzerdefinierte Kubernetes-Ressourcen definiert. Mit Config Sync (sowohl als eigenständiges Produkt als auch als Teil von Anthos Config Management) können Sie diese Einschränkungen in einem Git-Repository deklarieren und traditionelle Entwicklungsworkflows in dem Richtlinienverwaltungsprozess anwenden. Sie können für Ihre Implementierung Open Policy Agent – Gatekeeper anstelle von Policy Controller verwenden.

  • GitHub: In dieser Anleitung verwenden wir GitHub zum Hosten der Git-Repositories: eines für eine Beispielanwendung und eines für Anthos Config Management, das die Einschränkungen für den Richtliniencontroller enthält. Der Einfachheit halber sind die beiden Repositories zwei unterschiedliche Ordner in einem Git-Repository. In der Praxis handelt es sich dabei um verschiedene Repositories. Sie können jede beliebige Git-Lösung verwenden.

  • Cloud Build: Cloud Build ist die CI-Lösung von Google Cloud. In dieser Anleitung wird es verwendet, um die Validierungstests auszuführen. Die Details der Implementierung können zwar von einem CI-System zu einem anderen variieren, die in dieser Anleitung beschriebenen Konzepte können jedoch mit jedem beliebigen containerbasierten CI-System verwendet werden.

  • Kustomize: Kustomize ist ein Anpassungstool für Kubernetes-Konfigurationen. Dabei werden "Basiskonfigurationen" verwendet und Anpassungen vorgenommen. Es bietet einen Ansatz "DRY" (Nicht wiederholen) an den Kubernetes-Konfigurationen. Mit Kustomize können Sie Elemente, die für alle Ihre Umgebungen gemeinsam sind, in den Basiskonfigurationen speichern und Anpassungen pro Umgebung erstellen. In dieser Anleitung werden die Kustomize-Konfigurationen im Anwendungs-Repository beibehalten und wir erstellen die Konfigurationen (d. h. die Anpassungen) in der CI-Pipeline. Sie können die in dieser Anleitung beschriebenen Konzepte mit jedem Tool verwenden, das Kubernetes-Konfigurationen erstellt, die auf einen Cluster angewendet werden können (z. B. den Befehl helm template).

  • Kpt: Kpt ist ein Tool zum Erstellen von Workflows für Kubernetes-Konfigurationen. Mit Kpt können Sie Kubernetes-Konfigurationen abrufen, anzeigen, anpassen, aktualisieren, validieren und anwenden. Da es mit Git- und YAML-Dateien funktioniert, ist es mit den meisten vorhandenen Tools des Kubernetes-Ökosystems kompatibel. In dieser Anleitung verwenden wir kpt in der CI-Pipeline, um die Einschränkungen aus dem Anthos Config Management-Repository abzurufen und die Kubernetes-Konfigurationen auf diese Einschränkungen zu validieren.

Pipeline

Die CI-Pipeline, die wir in dieser Anleitung verwenden, ist im folgenden Diagramm dargestellt. Es wird in Cloud Build ausgeführt und die Befehle werden in einem Verzeichnis ausgeführt, das eine Kopie des Repositories der Beispielanwendung enthält. Die Pipeline beginnt mit dem Generieren der endgültigen Kubernetes-Konfigurationen mit kustomize. Als Nächstes werden die Einschränkungen abgerufen, die wir aus dem Anthos Config Management-Repository anhand von kpt validieren möchten. Schließlich wird mit kpt die Kubernetes-Konfigurationen anhand dieser Einschränkungen validiert. Dazu verwenden wir eine bestimmte Konfigurationsfunktion namens gatekeeper-validate, die diese Validierung durchführt. In dieser Anleitung lösen Sie die CI-Pipeline manuell aus. Tatsächlich würden Sie sie jedoch so konfigurieren, dass sie nach einem git push in Ihrem Git-Repository ausgeführt wird.

CI-Pipeline für Policy Controller

Ziele

  • Führen Sie eine CI-Pipeline für eine Beispielanwendung mit Cloud Build aus.
  • Beachten Sie, dass die Pipeline aufgrund eines Richtlinienverstoßes fehlschlägt.
  • Ändern Sie das Repository der Beispielanwendung so, dass es den Richtlinien entspricht.
  • Führen Sie die CI-Pipeline noch einmal aus.

Kosten

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

  • Cloud Build

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 im Abschnitt Bereinigen.

Hinweis

  1. Wählen Sie ein Cloud-Projekt aus oder erstellen Sie eines.

    ZUR SEITE "RESSOURCEN VERWALTEN"

  2. Aktivieren Sie die Abrechnung für Ihr Projekt.

    ABRECHNUNG AKTIVIEREN

  3. Öffnen Sie Cloud Shell, um die in dieser Anleitung aufgeführten Befehle auszuführen.

    ZU CLOUD SHELL

  4. Wenn der Befehl gcloud config get-value project nicht die ID des soeben ausgewählten Projekts zurückgibt, konfigurieren Sie Cloud Shell so, dass Ihr Projekt verwendet wird.

    gcloud config set project PROJECT_ID
    
  5. Aktivieren Sie in Cloud Shell die erforderliche Cloud Build API.

    gcloud services enable cloudbuild.googleapis.com
    

Validieren Sie die Konfigurationen der Beispielanwendungen.

In diesem Abschnitt führen Sie mit Cloud Build eine CI-Pipeline für ein von uns bereitgestelltes Beispielanwendungs-Repository aus. Diese Pipeline validiert die in diesem Beispielanwendungs-Repository verfügbare Kubernetes-Konfiguration anhand von Einschränkungen, die in einem Anthos Config Management-Beispiel-Repository verfügbar sind.

  1. Klonen Sie in Cloud Shell das Beispielanwendungs-Repository.

    git clone https://github.com/GoogleCloudPlatform/csp-config-management.git
    
  2. Führen Sie die CI-Pipeline mit Cloud Build aus. Logs des Builds werden direkt in Cloud Shell angezeigt.

    cd csp-config-management/ci-app/app-repo
    gcloud builds submit .
    

    Die von Ihnen ausgeführte Pipeline ist in der folgenden Datei definiert.

    steps:
    - id: 'Prepare config'
      # This step builds the final manifests for the app
      # using kustomize and the configuration files
      # available in the repository.
      name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
      entrypoint: '/bin/sh'
      args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
    - id: 'Download policies'
      # This step fetches the policies from the Anthos Config Management repository
      # and consolidates every resource in a single file.
      name: 'gcr.io/kpt-dev/kpt'
      entrypoint: '/bin/sh'
      args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/csp-config-management.git/ci-app/acm-repo/cluster@1.0.0 constraints
                      && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
    - id: 'Validate against policies'
      # This step validates that all resources comply with all policies.
      name: 'gcr.io/config-management-release/policy-controller-validate'
      args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']
  3. Nach einigen Minuten sehen Sie, dass die Pipeline mit dem folgenden Fehler fehlschlägt:

    [...]
    Step #2 - "Validate against policies": gcr.io/config-management-release/policy-controller-validate:latest
    Step #2 - "Validate against policies": Error: Found 1 violations:
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": [1] Deployment objects should have an 'owner' label indicating who created them.
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": name: "nginx-deployment"
    Step #2 - "Validate against policies": path: prod.yaml
    [...]
    

    Die Einschränkung, gegen die die Konfiguration verstößt, ist in der folgenden Datei definiert. Dies ist eine benutzerdefinierte Kubernetes-Ressource namens K8sRequiredLabels.

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: deployment-must-have-owner
    spec:
      match:
        kinds:
          - apiGroups: ["apps"]
            kinds: ["Deployment"]
      parameters:
        labels:
          - key: "owner"
        message: "Deployment objects should have an 'owner' label indicating who created them."

    Die Einschränkungsvorlage, die dieser Einschränkung entspricht, finden Sie in dieser Datei auf GitHub.

  4. Erstellen Sie die vollständige Kubernetes-Konfiguration selbst und achten Sie darauf, dass das Label owner tatsächlich fehlt. So erstellen Sie die Konfiguration:

    kubectl kustomize config/prod
    

Korrigieren Sie die Anwendung, damit sie den Unternehmensrichtlinien entspricht.

In diesem Abschnitt beheben Sie den Richtlinienverstoß mithilfe von Kustomize.

  1. Fügen Sie in Cloud Shell den Abschnitt commonLabels der Basis-Kustomisierungsdatei hinzu:

    cat <<EOF >> config/base/kustomization.yaml
    commonLabels:
      owner: myself
    EOF
    
  2. Erstellen Sie die vollständige Kubernetes-Konfiguration und achten Sie darauf, dass das Label owner jetzt vorhanden ist:

    kubectl kustomize config/prod
    
  3. Führen Sie die CI-Pipeline mit Cloud Build noch einmal aus:

    gcloud builds submit .
    

    Die Pipeline ist jetzt mit der folgenden Ausgabe erfolgreich:

    [...]
    Finished Step #2 - "Validate against policies"
    PUSH
    DONE
    [...]
    

Bereinigen

  1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite "Ressourcen verwalten"

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen .
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Nächste Schritte