GitOps Policy-as-Code: Kubernetes mit Argo CD und Kyverno sichern

Mit der Weiterentwicklung von Kubernetes-Umgebungen hat sich GitOps mit Argo CD zum Standard für deklarative, selbstheilende Infrastrukturen entwickelt. Ohne Schutzvorkehrungen für Ihre Bereitstellungen können jedoch fehlerhaft konfigurierte, unsichere oder nicht konforme Ressourcen leicht in die Produktion gelangen.

Dieser Blogbeitrag beschreibt, wie Sie Kyverno zusammen mit Argo CD bereitstellen, indem Sie Baseline-Richtlinien aus dem offiziellen Kyverno Policies Helm-Chart verwenden und zeigen, wie Sie Ihre eigenen benutzerdefinierten Richtlinien hinzufügen können.

Was ist Kyverno?

Kyverno ist ein von der CNCF abgeschlossenes Projekt, das als Policy-Engine für Kubernetes fungiert. Damit können Sie Regeln dafür definieren, was in Ihrem Cluster erlaubt ist und was nicht, und zwar in Form von Standard-Kubernetes-YAML. Kyverno arbeitet auf der Ebene des Admission Controllers, d. h. es fängt Ressourcenanfragen ab, bevor sie den Cluster erreichen, und reagiert darauf entsprechend Ihren Richtlinien. 

Sie können sich Kyverno wie einen Kontrollpunkt vorstellen, bevor Manifeste erstellt werden. Diese müssen einer Reihe von Richtlinien entsprechen, die Sie in Ihrem Cluster festgelegt haben möchten.

Es werden vier Arten von Richtlinien unterstützt:

• Validieren: Ressourcen blockieren oder prüfen, die nicht Ihren Regeln entsprechen
  • Block: Wenn die Ressource nicht konform ist, wird sie nicht erstellt.
  • Prüfung: Wenn die Ressource nicht konform ist, wird sie dennoch erstellt, aber es wird protokolliert, dass die Ressource aufgrund der Richtlinie nicht konform ist.
• Mutieren: Anstatt eine Ressource abzulehnen, ändert Kyverno sie automatisch so, dass sie Ihren Regeln entspricht, bevor sie erstellt wird.
• Generieren: Definierte Ressourcen automatisch in Richtlinien erstellen
• Bereinigung/Löschen: Entfernen Sie veraltete oder unerwünschte Ressourcen nach einem Zeitplan.

Es deckt den gesamten Lebenszyklus einer Ressource in Ihrem Cluster ab.

Warum Kyverno mit Argo CD?

Wenn Sie Argo CD verwenden, befindet sich Ihr Cluster-Status bereits in Git. Kyverno erweitert diese Struktur auch auf die Durchsetzung von Richtlinien. Zusammen ermöglichen sie einen vollständig GitOps-gesteuerten Ansatz für Sicherheit und Governance.

Hier ist der Grund, warum die beiden so gut zusammenpassen:

Richtlinie als Code:

Kyverno-Richtlinien werden unter Verwendung von Standard-Kubernetes-YAML definiert und folgen dabei derselben Struktur wie Kubernetes-Manifeste (`apiVersion`, `kind` und `spec`). Dadurch können Richtlinien mithilfe vertrauter Git-Workflows versioniert, überprüft und in verschiedenen Umgebungen implementiert werden.

Konsequente Durchsetzung:

Sobald Richtlinien in Git festgeschrieben sind, synchronisiert Argo CD sie automatisch mit dem Cluster. Kyverno setzt diese Richtlinien zum Zeitpunkt der Zulassung durch und stellt so sicher, dass alle Ressourcen Ihren Regeln entsprechen, unabhängig davon, wie sie erstellt wurden.

Sichere Rollouts mit Audit- und Durchsetzungsmodi:

Kyverno-Richtlinien können im Audit-Modus ausgeführt werden, um Verstöße zu melden, ohne etwas zu blockieren, oder im Enforce-Modus, um Ressourcen zu blockieren, die nicht der Richtlinie entsprechen. Mit Argo CD ist das Verschieben einer Richtlinie vom Audit- zum Enforce-Modus nur eine Git-Änderung.

Konfiguration und Einrichtung: Kyverno mit Argo CD

Die in diesem Tutorial gezeigte Konfiguration basiert auf der Struktur, die in der ITGix ADP (Application Development Platform) verwendet wird, die von unserem Team bei ITGix (https://www.itgix.com) entwickelt wurde. Sie bietet ein vorgefertigtes App-of-Apps-Muster für die Verwaltung der Cluster-Infrastruktur mit Argo CD. Auf der ADP ist die Aktivierung von Kyverno so einfach wie die Einstellung „enabled: true” in der umgebungsspezifischen Konfiguration Ihrer Plattform – den Rest übernimmt die Plattform.

Allerdings benötigen Sie kein ADP, um mitzumachen. Das Setup verwendet ein Standard-App-of-Apps-Muster, das mit jeder Argo CD-Installation funktioniert. Die Idee ist einfach: Eine Root-Argo-CD-Anwendung verweist auf ein Verzeichnis in Ihrem Git-Repo, das individuelle Anwendungsmanifeste für jeden Dienst enthält. Wenn die Root-App synchronisiert wird, erstellt sie alle untergeordneten Apps, und jede untergeordnete App verwaltet ihr eigenes Helm-Chart. Alles wird von Git aus gesteuert, sodass nach dem ersten Bootstrap kein manuelles kubectl apply erforderlich ist.

Am Ende sieht die Repo-Struktur wie folgt aus:

global-infra/
  infra-services/  #contains Application manifests for Kyverno + policies
    kyverno.yaml
    kyverno-policies.yaml
  kyverno/              # kyverno child app points here
    Chart.yaml
    values.yaml
  kyverno-policies/     # kyverno-policies child app points here
    Chart.yaml
    values.yaml
    templates/          # your custom policy YAMLs live here

Wir gehen davon aus, dass Sie Argo CD bereits installiert haben und dass eine Root-App Ihr Verzeichnis „infra-services/“ überwacht. Sie müssen lediglich die folgenden Anwendungsmanifeste in dieses Verzeichnis kopieren, den Rest erledigt Argo CD.

Schritt 1: Kyverno als Argo CD-Anwendung hinzufügen

Dadurch wird das vollständige Kyverno-Paket in Ihrem Cluster (dem Gehirn von Kyverno) installiert, einschließlich:

– Alle Kyverno-Controller (Policy Engine, Mutate, Generate, Cleanup usw.)

– Von Kyverno benötigte benutzerdefinierte Ressourcendefinitionen (CRDs)

– Standardkonfigurationen aus dem Helm-Chart  

Erstellen Sie in infra-services/ die Datei kyverno.yaml. Diese definiert die Argo CD-Anwendung, die Kyverno in Ihrem Cluster bereitstellt. Sie verwendet einen lokalen Helm-Chart-Wrapper, der das offizielle Kyverno-Chart als Abhängigkeit einbindet. Die Anmerkung sync-wave stellt sicher, dass Kyverno immer installiert ist, bevor Richtlinien angewendet werden.

Infra-Services/Kyverno.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kyverno
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "1"
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true
spec:
  project: default
  source:
    repoURL: https://github.com/demo-infra.git
    targetRevision: main
    path: kyverno
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: kyverno
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Ein paar Dinge, die hier erwähnenswert sind:

– ServerSideApply=true

 Dies ist für Kyverno erforderlich, da seine CRDs groß sind und die Annotationsgrößenbeschränkung überschreiten können, die von der clientseitigen Anwendung verwendet wird.

– IncludeMutationWebhook=true

  Diese Vergleichsoption weist Argo CD an, die sich verändernden Webhooks von Kyverno bei der Berechnung von Unterschieden zu berücksichtigen, wodurch ständige Warnungen wegen nicht synchronisierter Ressourcen, die Kyverno verändert, vermieden werden.

– ServerSideDiff=true

  Dadurch wird Argo CD angewiesen, Unterschiede anhand der serverseitigen Darstellung von Ressourcen statt anhand des lokalen Manifests zu berechnen. Dies funktioniert besser mit Tools wie Kyverno, die Ressourcen zum Zeitpunkt der Aufnahme mutieren, und hilft, störende oder falsche Unterschiede zu vermeiden.

Schritt 2: Wickeln Sie die offizielle Kyverno-Helm-Tabelle ein.

Helm-Repository unter https://kyverno.github.io/kyverno/

Diagramm: kyverno

kyverno/Diagramm.yaml

Die Datei „kyverno/Chart.yaml“ fasst das offizielle Diagramm als Abhängigkeit zusammen, die aus Kyverno abgerufen wird. 

apiVersion: v2
name: kyverno
description: Helm Chart for Kyverno
type: application
version: 1.0.0
dependencies:
 - name: kyverno
   version: "3.7.1"
   repository: https://kyverno.github.io/kyverno/

kyverno/Werte.yaml

Hinweis: Um den Deleting/Cleanup Controller zum automatischen Bereinigen von Ressourcen zu verwenden, fügen Sie Folgendes zu Ihrer Datei kyverno/values.yaml hinzu. Wenn Sie keine Richtlinien für die Bereinigung/Löschung verwenden möchten, sind die Standardeinstellungen aus dem offiziellen Chart völlig ausreichend.

kyverno:
 cleanupController:
   rbac:
     clusterRole:
       extraResources:
         - apiGroups:
             - ""
           resources:
             - pods
           verbs:
             - get
             - list
             - watch
             - delete

Schritt 3: Bestätigen Sie in der ArgoCD-Benutzeroberfläche, dass die Argo-Anwendung Kyverno erstellt wurde.

Nachdem diese Änderungen übernommen wurden, wird Argo CD Kyverno im Cluster bereitstellen:

Hinweis: Wenn Kyverno bei „unsynced“ hängen bleibt, stellen Sie sicher, dass Sie die Anmerkungen in der Anwendung hinzugefügt haben:

argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true

Schritt 4: Kyverno-Richtlinien als Argo CD-Anwendung hinzufügen

In diesem Schritt werden die eigentlichen Richtlinien installiert, die Kyverno durchsetzen soll.  

Dadurch erhalten Sie eine Reihe von Startrichtlinien für Ihren Cluster, die Sie später mithilfe Ihrer values.yaml anpassen oder in templates/ eigene erstellen können.

Erstellen Sie bei laufendem Kyverno die Datei kyverno-policies.yaml in infra-services/, um Ihre Richtlinien bereitzustellen. Diese folgt dem gleichen Muster, verweist auf das Verzeichnis kyverno-policies/ und wird bei sync-wave „2“ ausgeführt, sodass sie immer erst nach der Bereitstellung von Kyverno selbst ausgeführt wird:

Infrastrukturdienste/Kyverno-Richtlinien.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: kyverno-policies
 namespace: argocd
 annotations:
   argocd.argoproj.io/sync-wave: "2"
spec:
 project: default
 source:
   repoURL: https://github.com/demo-infra.git
   targetRevision: main
   path: kyverno-policies
   helm:
     valueFiles:
       - values.yaml
 destination:
   server: https://kubernetes.default.svc
   namespace: kyverno
 syncPolicy:
   automated:
     prune: true
     selfHeal: true
   syncOptions:
     - CreateNamespace=true

Schritt 5: Kyverno-Richtlinien-Helm-Chart verpacken und konfigurieren

In diesem Schritt definieren wir einen Helm-Wrapper für die offizielle Richtlinien-Chart von Kyverno. Dadurch können wir:

• Installieren Sie vom Kyverno-Projekt verwaltete, produktionsreife Basisrichtlinien.
• Konfigurieren Sie das Verhalten der Richtlinie (Audit vs. Durchsetzung, Schweregrad, PSS-Stufe) mithilfe von values.yaml.
• Fügen Sie unsere eigenen benutzerdefinierten Richtlinien neben den offiziellen Richtlinien in einem einzigen GitOps-Workflow hinzu.

Die im vorherigen Schritt erstellte untergeordnete Anwendung „kyverno-policies“ verweist auf dieses Verzeichnis.

Helm-Repository unter https://kyverno.github.io/kyverno/

Diagramm: kyverno-policies

kyverno-policies/Chart.yaml

Die Datei „kyverno-policies/Chart.yaml“ enthält das offizielle Kyverno-Policies-Helm-Chart als Abhängigkeit. Das Chart wird direkt aus dem Kyverno-Helm-Repository abgerufen.

apiVersion: v2
name: kyverno-policies
description: Helm Chart for Kyverno Policies
type: application
version: 1.0.0
dependencies:
 - name: kyverno-policies
   version: "3.7.1"
   repository: https://kyverno.github.io/kyverno/

kyverno-richtlinien/werte.yaml

Und kyverno-policies/values.yaml legt den Pod-Sicherheitsstandard und den Standardvalidierungsmodus für diese Bibliotheksrichtlinien fest:

kyverno-policies:
 policyType: ValidatingPolicy
 podSecurityStandard: baseline
 validationFailureAction: Audit
 podSecuritySeverity: Medium

– policyType: ValidatingPolicy: Weist das Diagramm an , Validierungsrichtlinien (Richtlinien, die Ressourcen anhand von Regeln überprüfen) zu generieren, anstatt sie zu mutieren. Diese Richtlinien blockieren oder melden Ressourcen, die nicht den definierten Standards entsprechen.

– podSecurityStandard: baseline: Wählt aus, welche Pod Security Standard-Richtlinien installiert werden sollen. Kubernetes definiert drei Stufen: privilegiert (uneingeschränkt), baseline (verhindert bekannte Privilegieneskalationen) und eingeschränkt (stark gesperrt). baseline ist ein guter Ausgangspunkt, da es Dinge wie privilegierte Container und Host-Netzwerke blockiert, ohne so streng zu sein, dass es gängige Workloads beeinträchtigt.

– validationFailureAction: Audit: Legt fest, was passiert, wenn eine Ressource gegen eine Richtlinie verstößt. Audit bedeutet, dass Verstöße protokolliert werden und in Richtlinienberichten sichtbar sind, die Ressource jedoch weiterhin erstellt werden darf. Wenn Sie diese Option auf „Enforce“ setzen, wird die Erstellung nicht konformer Ressourcen vollständig blockiert. Wenn Sie mit „Audit“ beginnen, können Sie sehen, was nicht funktioniert, bevor Sie etwas blockieren.

– podSecuritySeverity: Mittel: Legt den Schweregrad fest, der bei Erkennung eines Verstoßes gemeldet wird. Dieser wird in den Richtlinienberichten von Kyverno angezeigt und kann zum Filtern und Priorisieren verwendet werden. Die Optionen sind Niedrig, Mittel, Hoch und Kritisch.

Nach dem Übernehmen dieser Änderungen wird Argo CD kyverno-policies im Cluster bereitstellen:

Schritt 6: Unterstützung für benutzerdefinierte Kyverno-Richtlinien hinzufügen (optional)

Bisher haben wir installiert:

• Kyverno selbst
• Eine Reihe grundlegender offizieller Kyverno-Richtlinien, die über Helm verwaltet werden
  

In vielen realen Szenarien möchten Sie auch organisationsspezifische Regeln durchsetzen, die nicht in der Standardrichtlinienbibliothek enthalten sind. Zu diesem Zweck fügen wir ein Verzeichnis für benutzerdefinierte Richtlinienmanifeste hinzu.

Erstellen Sie das folgende Verzeichnis in Ihrem Repository:

kyverno-richtlinien/vorlagen/

Jede Kyverno-Richtlinie im YAML-Format, die in diesem Verzeichnis abgelegt wird, wird automatisch beim Rendern des Helm-Charts berücksichtigt. Sobald die Änderung in Git committet wurde, erkennt Argo CD die Änderung und Kyverno setzt die Richtlinie durch, ohne dass manuelle Schritte erforderlich sind.

Dadurch bleiben die integrierte Richtlinienbibliothek und benutzerdefinierte Richtlinien klar voneinander getrennt, während weiterhin derselbe GitOps-Workflow befolgt wird.

Schritt 7: Verwenden benutzerdefinierter Richtlinien

Gute Beispiele für alle Arten von Richtlinien finden Sie auf der offiziellen Kyverno-Website: https://kyverno.io/policies/

Als Beispiel für den Blog hier eine Richtlinie, die ich auf der offiziellen Kyverno-Website gefunden habe. Sie können sie zum Verzeichnis kyverno-policies/templates/ hinzufügen.

Validierungspolitik: Beschränkung der Nutzung externer IP-Adressen

Typ: Validieren | Modus: Audit | Schweregrad: Mittel

Beschreibung: Das Festlegen von externalIPs für einen Dienst ist ein bekannter Vektor für Man-in-the-Middle-Angriffe (CVE-2020-8554). Dadurch kann der für eine beliebige IP bestimmte Datenverkehr abgefangen und umgeleitet werden, was in jedem Multi-Tenant-Cluster ein ernstes Risiko darstellt. Diese Richtlinie stellt sicher, dass für keinen Dienst das Feld externalIPs festgelegt ist, wodurch diese Angriffsfläche vollständig blockiert wird.

kyverno-policies/templates/clusterpolicy-restrict-external-ips.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: restrict-external-ips
 annotations:
   policies.kyverno.io/title: Restrict External IPs
   policies.kyverno.io/category: Best Practices
   policies.kyverno.io/minversion: 1.6.0
   policies.kyverno.io/severity: medium
   policies.kyverno.io/subject: Service
   policies.kyverno.io/description: "Service externalIPs can be used for a MITM attack (CVE-2020-8554). Restrict externalIPs or limit to a known set of addresses. See: https://github.com/kyverno/kyverno/issues/1367. This policy validates that the `externalIPs` field is not set on a Service."
spec:
 validationFailureAction: Audit
 background: true
 rules:
   - name: check-ips
     match:
       any:
         - resources:
             kinds:
               - Service
     validate:
       message: externalIPs are not allowed.
       pattern:
         spec:
           X(externalIPs): "null"

Verstöße gegen die Nutzungsbedingungen anzeigen

Sobald Kyverno-Richtlinien in Ihrem Cluster ausgeführt werden, lässt sich leicht erkennen, wenn eine Ressource nicht mit diesen Richtlinien übereinstimmt. Das genaue Verhalten hängt von der in Ihren Richtlinien konfigurierten validationFailureAction ab. Wie bereits erwähnt, können Richtlinien im Audit-Modus (Verstöße melden) oder im Enforce-Modus (Ressourcen vollständig blockieren) ausgeführt werden.

Argo CD-Benutzeroberfläche

Dadurch wird während eines GitOps-Workflows sofort sichtbar, wenn eine in Git eingeführte Änderung gegen die Cluster-Richtlinie verstößt.

Kyverno-Richtlinienberichte

Wenn Richtlinien im Audit-Modus ausgeführt werden, wird die Ressource weiterhin erstellt, aber die Verletzung wird in einer Kyverno PolicyReport- oder ClusterPolicyReport-Ressource protokolliert.

Sie können diese anzeigen mit:

• kubectl get policyreport -A
• kubectl get clusterpolicyreport

Um die Details eines Verstoßes zu überprüfen:

• kubectl describe clusterpolicyreport

Diese Berichte zeigen:

• Die Ressource, die gegen die Richtlinie verstoßen hat
• Der Name der Richtlinie
• Die Regel, die versagt hat
• Der Schweregrad
• Die in der Richtlinie definierte Nachricht

Dadurch können Teams zunächst im Audit-Modus beginnen, um zu beobachten, wie sich Richtlinien auf Workloads auswirken, bevor sie in den Durchsetzungsmodus wechseln, um nicht konforme Ressourcen aktiv zu blockieren.