ArgoCD Security

GitOps mit Argo CD nutzt verschiedene Security Features. Wie überall in der Security verwenden wir hier auch den Ansatz von Security in Depth.

Unautorisierter Schreib-Zugriff auf das Git Repository hat schwerwiegende Security Implikationen! Ein Angreifer kann beispielsweise unautorisierte Deployments durchführen und damit auch bösartige Container Images im Cluster deployen sowie bestehende Ressourcen löschen.

 

Commit Signing

Ein erster Schritt zur Absicherung besteht darin, die Git Commits mit seinem privaten Schlüssel zu signieren. Der entsprechende Publik Key kann in ArgoCD zur Verifizierung der Commits benutzt werden. Dies verringert das Risiko bei einer kompromittierten Git Instanz enorm. Auch wenn ein Angreifer auf die Git Repositories Zugriff hat, ist es für ihn nicht möglich eigene Commits einzuschleusen. Dazu benötigt er mindestens einen Private Key, welcher auf dem lokalen Rechner des Entwicklers abgespeichert ist und mit einer Passphrase geschützt ist. Seit Git v2.34 ist es auch möglich ein SSH Key zum Signieren der Commits zu verwenden. Somit ist es ganz einfach möglich, die SSH Keys sowohl für das Pullen/Pushen wie auch für das Signen der Commits zu verwenden. Eine Anleitung zur Einrichtung dazu findet sich hier.

RBAC

Es gibt drei verschiedene Orten an welchen wir (Role Based) Access Controll einsetzen können.

1. Git Tool Permissions

Die erste Stufe ist auf Level Git. Git selbst unterstützt keine Security Features, diese sind gewöhnlich in den zu verwendeten Git Tools integriert (GitLab, GitHub etc.)

• Limit Project Access: Nur Personen welche Zugang zu den Repositories benötigen für das Projekt berechtigen
• Protect Branches: Branches welche von ArgoCD angezogen und deployed werden sollten immer Protected sein
• Merge Requests: Änderungen dürfen nie direkt auf einen Protected Branch gepusht werden. Sämtliche Änderungen müssen via Merge Request commited werden.

Empfehlenswert ist ausserdem das oben erwähnte Dev-Ops(-Infra) Repository Pattern. Damit lassen sich die Berechtigungen pro Projekt/Repository vergeben.

2. ArgoCD Projects

Auch ArgoCD selbst kommt mit verschiedenen Security Features daher.

ArgoCD bietet die Möglichkeit von sogenannten Projects. Diese Projects sind nicht zu verwechseln mit den OpenShift Projects! Projects bieten eine logische Gruppierung von Applikationen. Diese Gruppierung macht besonders Sinn, wenn ArgoCD von mehreren Teams gleichzeitig verwendet wird. Projects bieten folgende Features:

• Einschränken woher Resourcen deployed werden können. (Allow List von Git Repositories)
• Einschränken wohin Resourcen deployed werden dürfen (Allow List von Cluster und Namespaces)
• Einschränken was für Resourcen deployted werden dürfen (Allow List von Kubernetes Resourcen)
• Einschränken wer Resourcen deployen darf. GPG Signature verification ist eine weitere Möglichkeit die Security von GitOps / ArgoCD zu erhöhen. Git bietet die Möglichkeit Commits mit einem GPG Private Key zu signieren. Dies erlaubt anschliessend anderen Benutzern den Commit zu überprüfen ob dieser aus einer vertrauenswürdigen Quelle stammt. ArgoCD besitzt ebenfalls die Möglichkeit die Commits vor dem Synchronisieren zu validieren, ob diese von einem bekannten und bewilligten User stammen. Dies reduziert den sogenannten Surface Attack Vector enorm, da bei einem unbefugten Zugriff auf das Ops-Repositories trotzdem keine Commits eingeschleust werden können.

Als Beispiel betrachten wir einmal das Dev-Ops-Infra Repository Pattern. Dieses Pattern lässt sich auch auf Seiten ArgoCD Abbilden.

• Application Project: In ArgoCD wird ein sogenanntes Application Project angelegt. Dieses Projekt hat folgende Einschränkungen:
  • Woher: Nur OPS-Repositories welches dem folgendene URL Pattern entsprechen sind berechtigt ssh://gitlab.ssh.gitlab.puzzle.ch/apps/*
  • Wohin: ArgoCD Applications dürfen nur in Namespaces deployed werden, welche explizit definiert sind pitc-apps-*
  • Was: Nur Ressourcen welche Namespaced sind dürfen deployed werden.
• Infrastructur Project:
  • Woher: Nur OPS-Repositories welches dem folgendene URL Pattern entsprechen sind berechtigt ssh://gitlab.ssh.gitlab.puzzle.ch/infra/*
  • Wohin: Argo CD Applications dürfen nur in Namespaces deployt werden welche explizit definiert sind pitc-infra-*
  • Was: Alle Ressourcen dürfen deployed werden.

3. Cluster RBAC

Standardmässig benutzt ArgoCD eine Cluster Admin Rolle für folgende Tasks:

• Watch & Operate Cluster State (Read / List)
• Deployen von Ressourcen im Cluster (Create / Update / Patch / Delete)

Für das korrekte Funktionieren von ArgoCD ist mindestens eine clusterweite Read Rolle nötig. Es ist nicht zwingend nötig eine clusterweite Write Rolle zu benutzen. Diese kann und sollte die entsprechenden Namespaces, welche von Argo CD verwaltet werden, einschränken.

Secret Managment

Wie auch in der Software Entwicklung sollte man nie sensitive Informationen (Passwörter, Private Keys, Private Certificates etc.) in Git eingecheckt werden.
ArgoCD selbst bietet keine Möglichkeit Secrets direkt zu managen, aber ebenfalls ist es unparteiisch was das Managen von Kubernetes Secrets betrifft. Nachfolgend möchten wir euch einige Tools vorstellen für das Verwalten von Secretsmit ArgoCD.

Wir empfehlen den Einsatz von gitleaks oder ähnlichen Tools damit versehentlich eingecheckte Secrets schnell entdeckt werden. Für zusätzliche Sicherheit können diese Tools auch während einem Pre-Commit Hook (Client Seitig) oder als pre-receive Hook (Server Seitig) eingebunden werden.

Sealed Secrets

Eine bei Puzzle weit verbreitete Lösung zum Managen von Secrets ist der Sealed Secrets Controller von Bitnami. Die Idee hinter den Sealed Secrets ist einfach und simpel. Anstelle von Kubernetes Secrets werden sensitive Informationen mit einem asymmetrischen Key Verfahren verschlüsselt und als Sealed Secret Resource im Git Repository abgelegt. Diese Sealed Secret Resource wird anschliessend im Cluster wieder entschlüsselt und daraus ein Plain Kubernetes Secret erstellt. Somit können die Secret Ressourcen problemlos in Git abgelegt und verfolgt werden ohne dass sensitive Informationen geleakt werden.

ArgoCD-Vault-Plugin

Mit dem ArgoCD Vault Plugin ist es möglich, externe Secrets Stores anzubinden. Damit ist es nicht mehr nötig Secrets mit sensitiven Information in Git einzuchecken. Anstelle davon enthalten die Secrets nur die Referenz auf ein extern gespeichertes Secret. Besonders im Enterprise Umfeld wo häufig bereits eine Zentrale Instanz für das Secret Managment besteht, bietet es sich an Gebrauch von diesem Plugin zu machen.

Unterstützende Secret Store Backends sind aktuell:

• HashiCorp Vault
• IBM Cloud Secret Manager
• AWS Secrets Manager
• GCP Secret Manager
• Azure Key Vault
• SOPS
• Yandex Cloud Lockbox
• 1Password Connect

Recap

Wir haben nun einige Möglichkeiten gelernt wie wir einerseits Secrets sicher mit GitOps verwalten können und wie wir unser GitOps Konzept mithilfe von Git Tools, Argo CD Projects und OpenShift RBAC absichern können.

Im nächsten und letzten Teil der Serie möchten wir euch noch einige Ansätze aufzeigen, wie ArgoCD benutzt werden kann, um Multi Environment Deployments machen. Zudem zeigen wir, wie wir unser Dev Repository am besten strukturieren um ein reibungsloses Propagieren der Konfiguration über verschiedene Stages / Environments hinweg ermöglichen.