Wenn Ihre Organisation mit Policy Controller Richtlinien in ihren Clustern der Google Kubernetes Engine (GKE) Enterprise Edition 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.
Diese Seite richtet sich an IT-Administratoren und -Betreiber, die dafür sorgen möchten, dass alle auf der Cloud-Plattform ausgeführten Ressourcen die Compliance-Anforderungen des Unternehmens erfüllen. Dazu stellen sie Automatisierungsfunktionen zur Prüfung oder Durchsetzung bereit und verwalten den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und ‑Aufgaben.
Richtlinien sind ein wichtiger Bestandteil der Sicherheit und Compliance einer Organisation. Mit Policy Controller kann Ihre Organisation diese Richtlinien zentral und deklarativ für alle Cluster 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.
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: 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. Policy Controller ist in der Google Kubernetes Engine (GKE) Enterprise-Version verfügbar. Sie können für Ihre Implementierung aber auch 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, 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-samples-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:
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-samples-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, 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 Cloudverwendet:
- Cloud Build
- Google Kubernetes Engine (GKE) Enterprise Edition
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.
Hinweise
Wählen Sie ein Google Cloud-Projekt aus oder erstellen Sie eines. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
Öffnen Sie Cloud Shell, um die in dieser Anleitung aufgeführten Befehle auszuführen.
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.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-samples-Repository verfügbar sind.
So validieren Sie die Anwendungskonfigurationen:
Klonen Sie in Cloud Shell das Beispielanwendungs-Repository:
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
Führen Sie die CI-Pipeline mit Cloud Build aus. Logs des Builds werden direkt in Cloud Shell angezeigt.
cd anthos-config-management-samples/ci-app/app-repo gcloud builds submit .
Die ausgeführte Pipeline ist in der folgenden Datei definiert.
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/kpt-fn/gatekeeper
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 Befehlkpt pkg get
nach Bedarf, um sowohl Einschränkungsvorlagen als auch Einschränkungen herunterzuladen.In dieser Anleitung wird
gcr.io/kpt-fn/gatekeeper
mit Cloud Build zum Prüfen von Ressourcen verwendet. Es gibt jedoch zwei weitere Alternativen:- Funktion
gcr.io/kpt-fn/gatekeeper
mitkpt
verwenden:
kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2
gator test -f hydrated-manifests/kpt-manifests.yaml
- Funktion
Nach einigen Minuten sehen Sie, dass die Pipeline mit dem folgenden Fehler fehlschlägt:
[...] Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them. Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner Finished Step #2 - "Validate against policies" 2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished 2022/05/11 18:55:19 status changed to "ERROR" ERROR ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1 2022/05/11 18:55:20 Build finished with ERROR status
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
.Die Einschränkungsvorlage für diese Einschränkung finden Sie auf GitHub unter
requiredlabels.yaml
.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:
Fügen Sie in Cloud Shell den Abschnitt
commonLabels
der Basisdatei von Kustomization hinzu:cat <<EOF >> config/base/kustomization.yaml commonLabels: owner: myself EOF
Erstellen Sie die vollständige Kubernetes-Konfiguration und achten Sie darauf, dass das Label
owner
jetzt vorhanden ist:kubectl kustomize config/prod
Führen Sie die CI-Pipeline mit Cloud Build noch einmal aus:
gcloud builds submit .
Die Pipeline ist jetzt mit der folgenden Ausgabe erfolgreich:
[...] Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0" Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0" [...]
Bereinigen
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Nächste Schritte
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.