Anwendungen anhand von Unternehmensrichtlinien in einer CI-Pipeline 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-Pipeline (CI) prüfen. In dieser Anleitung wird gezeigt, wie Sie dieses Ergebnis erzielen. Die Validierung Ihrer Anwendung ist nützlich, wenn Sie als Entwickler eine CI-Pipeline für eine Anwendung erstellen oder als Plattformentwickler eine CI-Pipelinevorlage für mehrere Anwendungsteams erstellen.

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 Arbeitsablauf bei der Entwicklung zu validieren. Es hat zwei Hauptvorteile, wenn Sie über Richtlinienverstöße in Ihrer CI-Pipeline statt während der Bereitstellung informiert werden: Sie können sich in Sicherheitsfragen nach links bewegen und die Feedback-Schleife wird verkürzt, was den Zeit- und Kostenaufwand für die Behebung dieser Verstöße verringert.

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 mehrere Kubernetes-Tools 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.

Folgende Tools werden in dieser Anleitung verwendet:

  • Policy Controller: Policy Controller ist ein Google Cloud-Produkt, das Teil von Anthos Config Management ist. Es basiert auf dem Open-Source-Projekt Open Policy Agent – Gatekeeper. Der Policy Controller erzwingt Richtlinien für die Objekte, die in einem Kubernetes-Cluster erstellt werden. So wird z. B. die Verwendung einer bestimmten Option oder eines bestimmten Labels verhindert. Diese Richtlinien werden als Einschränkungen bezeichnet. Einschränkungen werden als benutzerdefinierte Kubernetes-Ressourcen definiert. Mit Config Sync können Sie diese Einschränkungen in einem Git-Repository deklarieren und traditionelle Entwicklungs-Workflows auf die Verwaltung Ihrer Richtlinien anwenden. Config Sync ist sowohl als eigenständiges Produkt als auch als Teil von Anthos Config Management verfügbar. 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 Policy Controller 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 sie verwendet, um die Validierungstests auszuführen. Die Details der Implementierung können zwar von einem CI-System zum nächsten 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 „DRY“-Ansatz (Nicht wiederholen) für Kubernetes-Konfigurationen. Mit Kustomize können Sie Elemente, die alle Ihre Umgebungen gemeinsam haben, 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 in der CI-Pipeline, z. B. um die Anpassungen anzuwenden. 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, wird im folgenden Diagramm dargestellt:

CI-Pipeline für Policy Controller

Die Pipeline 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 werden mit kpt die Kubernetes-Konfigurationen anhand dieser Einschränkungen validiert. Dazu verwenden wir eine bestimmte Konfigurationsfunktion mit dem Namen 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.

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.

Wenn Sie diese Anleitung abgeschlossen haben, können Sie laufende Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie im Abschnitt Bereinigen.

Vorbereitung

  1. Wählen Sie ein Google Cloud-Projekt aus oder erstellen Sie eines. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

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

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

    Zu Cloud Shell

  4. Führen Sie in Cloud Shell gcloud config get-value project aus:

    Wenn der Befehl 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
    

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  5. Aktivieren Sie in Cloud Shell die erforderliche Cloud Build API:

    gcloud services enable cloudbuild.googleapis.com
    

Beispielkonfigurationen für Anwendungen prüfen

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.

So validieren Sie die Anwendungskonfigurationen:

  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 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']

    Im Policy Controller sind Einschränkungen Instanziierungen von Einschränkungsvorlagen. Einschränkungsvorlagen enthalten den tatsächlichen Rego-Code, mit dem die Einschränkung implementiert wird. Die Funktion gcr.io/config-management-release/policy-controller-validate benötigt sowohl die Einschränkungsvorlage als auch die Einschränkungsdefinitionen. Das Beispielrichtlinien-Repository enthält beide, kann jedoch an unterschiedlichen Orten gespeichert werden. Verwenden Sie den Befehl kpt pkg get nach Bedarf, um sowohl Einschränkungsvorlagen als auch Einschränkungen herunterzuladen.

  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. Es handelt sich um 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 für diese Einschränkung finden Sie auf GitHub unter requiredlabels.yaml.

  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 Basisdatei von Kustomization 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 Shut down (Beenden), um das Projekt zu löschen.

Weitere Informationen