ArgoCD Enterprise: App-of-Apps, RBAC und SSO

TL;DR

ArgoCD synchronisiert den gewünschten Zustand aus Git mit dem tatsächlichen Cluster-Zustand -- vollautomatisch und auditierbar
Das App-of-Apps-Pattern ist der beste Einstiegspunkt fuer Enterprise-Setups mit vielen Microservices
Multi-Repo schlaegt Mono-Repo, sobald mehrere Teams unabhaengig deployen muessen
RBAC ueber ArgoCD-Projects und SSO-Integration (OIDC/SAML) sind Pflicht fuer den Produktivbetrieb
Kustomize fuer einfache Umgebungs-Overrides, Helm fuer komplexe Third-Party-Charts -- beides laesst sich kombinieren

Warum GitOps mit ArgoCD?

GitOps verlagert die Wahrheit ueber den Cluster-Zustand in ein Git-Repository. ArgoCD ueberwacht dieses Repository und gleicht Abweichungen automatisch ab. Dadurch entfallen manuelle kubectl apply-Aktionen, und jede Aenderung ist ueber Git-History nachvollziehbar.

Gegenueber Flux bietet ArgoCD eine ausgereifte Web-UI, feingranulares RBAC ueber Projects und native Multi-Cluster-Unterstuetzung. Fuer Unternehmen, die Wert auf Sichtbarkeit und Zugriffskontrolle legen, ist das oft entscheidend.

Architekturentscheidung: Mono-Repo vs. Multi-Repo

Kriterium	Mono-Repo	Multi-Repo
Team-Autonomie	Gering -- alle Teams arbeiten im selben Repo	Hoch -- jedes Team verwaltet eigene Manifests
Zugriffssteuerung	Ueber CODEOWNERS/Branch-Protection	Natuerliche Trennung ueber Repo-Permissions
CI/CD-Komplexitaet	Einfacher Start, skaliert schlecht	Mehr Setup, skaliert besser
Blast Radius	Ein fehlerhafter Merge betrifft potenziell alles	Isoliert auf das jeweilige Repo
Empfehlung	Kleine Teams (unter 5 Devs, unter 10 Services)	Ab 3+ Teams oder 15+ Services

Praxis-Empfehlung: Starten Sie mit einem dedizierten Infrastruktur-Repo (Cluster-weite Ressourcen wie Namespaces, RBAC, Monitoring) und separaten App-Repos pro Team.

Beispiel-Verzeichnisstruktur (Multi-Repo)

# Repo: infra-gitops
├── argocd/
│   ├── projects/         # ArgoCD AppProjects
│   ├── apps/             # App-of-Apps Definitionen
│   └── root-app.yaml     # Bootstrap-Application
├── cluster-config/
│   ├── namespaces/
│   ├── rbac/
│   └── network-policies/
└── monitoring/
    ├── prometheus/
    └── grafana/

# Repo: team-a-apps
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

ArgoCD installieren

Fuer den Produktivbetrieb empfiehlt sich die HA-Installation:

# Namespace anlegen
kubectl create namespace argocd

# HA-Installation (empfohlen fuer Produktion)
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.13.3/manifests/ha/install.yaml

# CLI installieren (macOS)
brew install argocd

# Initiales Admin-Passwort auslesen
argocd admin initial-password -n argocd

# Sofort aendern
argocd login argocd-server.argocd.svc.cluster.local
argocd account update-password

Nach der Installation sollte das initiale Admin-Passwort sofort geaendert und die Secret-basierte Authentifizierung durch SSO ersetzt werden.

Das App-of-Apps-Pattern

Das zentrale Pattern fuer Enterprise-ArgoCD: Eine Root-Application verwaltet alle anderen Applications. Aenderungen an der Anwendungslandschaft werden so ebenfalls ueber Git gesteuert.

Root Application

# argocd/root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/mein-unternehmen/infra-gitops.git
    targetRevision: main
    path: argocd/apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Einzelne Application-Definition

# argocd/apps/team-a-api.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: team-a-api
  namespace: argocd
  labels:
    team: team-a
    env: production
spec:
  project: team-a
  source:
    repoURL: https://github.com/mein-unternehmen/team-a-apps.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: team-a-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 3
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

RBAC mit ArgoCD Projects

ArgoCD Projects definieren, welche Teams auf welche Repositories, Cluster und Namespaces zugreifen duerfen. Das ist unabhaengig von Kubernetes-RBAC und eine zusaetzliche Schutzschicht.

# argocd/projects/team-a.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: "Projekt fuer Team A - Payment Service"
  sourceRepos:
    - 'https://github.com/mein-unternehmen/team-a-apps.git'
  destinations:
    - namespace: 'team-a-*'
      server: https://kubernetes.default.svc
  # Cluster-weite Ressourcen verbieten
  clusterResourceWhitelist: []
  # Nur bestimmte Namespace-Ressourcen erlauben
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: 'Deployment'
    - group: ''
      kind: 'Service'
    - group: ''
      kind: 'ConfigMap'
    - group: 'networking.k8s.io'
      kind: 'Ingress'
  roles:
    - name: team-a-dev
      description: "Entwickler Team A"
      policies:
        - p, proj:team-a:team-a-dev, applications, get, team-a/*, allow
        - p, proj:team-a:team-a-dev, applications, sync, team-a/*, allow
      groups:
        - team-a-developers
    - name: team-a-admin
      description: "Admin Team A"
      policies:
        - p, proj:team-a:team-a-admin, applications, *, team-a/*, allow
      groups:
        - team-a-leads

SSO-Integration (OIDC)

Fuer Unternehmen ist SSO ueber den vorhandenen Identity Provider Pflicht. ArgoCD unterstuetzt OIDC, SAML und Dex als Vermittler.

# argocd-cm ConfigMap (Auszug)
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.mein-unternehmen.de
  oidc.config: |
    name: Keycloak
    issuer: https://keycloak.mein-unternehmen.de/realms/infra
    clientID: argocd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes:
      - openid
      - profile
      - email
      - groups

Die Gruppen aus dem Identity Provider werden dann in den ArgoCD-Project-Roles referenziert (siehe groups im Beispiel oben).

Kustomize und Helm kombinieren

ArgoCD unterstuetzt beide Tools nativ. Eine bewaehlte Strategie: Kustomize fuer eigene Anwendungen, Helm fuer Third-Party-Software.

Kustomize-Overlay fuer verschiedene Umgebungen

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: team-a-prod

resources:
  - ../../base

replicas:
  - name: api-server
    count: 3

patches:
  - target:
      kind: Deployment
      name: api-server
    patch: |
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/memory
        value: "512Mi"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: "1Gi"

images:
  - name: api-server
    newTag: v2.4.1

Helm-Chart ueber ArgoCD deployen

# argocd/apps/prometheus.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-stack
  namespace: argocd
spec:
  project: infra
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 65.8.1
    helm:
      releaseName: monitoring
      valuesObject:
        prometheus:
          retention: 30d
          storageSpec:
            volumeClaimTemplate:
              spec:
                storageClassName: gp3
                resources:
                  requests:
                    storage: 100Gi
        grafana:
          adminPassword: vault:secret/grafana#admin-password
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Sync-Strategien und Waves

Fuer komplexe Deployments koennen Sie mit Sync-Waves die Reihenfolge steuern:

# Namespace zuerst (Wave -1)
apiVersion: v1
kind: Namespace
metadata:
  name: team-a-prod
  annotations:
    argocd.argoproj.io/sync-wave: "-1"

---
# Secrets vor dem Deployment (Wave 0)
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: team-a-prod
  annotations:
    argocd.argoproj.io/sync-wave: "0"
type: Opaque
data:
  password: base64-encoded-value

---
# Deployment zuletzt (Wave 1)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  namespace: team-a-prod
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  # ...

Notifications einrichten

ArgoCD Notifications informiert Teams ueber Sync-Status per Slack, Teams oder E-Mail:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-alert]
  template.slack-alert: |
    message: |
      App {{.app.metadata.name}} sync fehlgeschlagen!
      Status: {{.app.status.operationState.phase}}
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: platform-alerts

Secrets-Management

ArgoCD selbst sollte keine Secrets im Klartext aus Git lesen. Gaengige Loesungen:

Tool	Ansatz	Komplexitaet
Sealed Secrets	Verschluesselt im Git, Controller entschluesselt im Cluster	Niedrig
External Secrets Operator	Referenz auf AWS SM / Azure KV / Vault	Mittel
SOPS + Age/KMS	Verschluesselte YAML-Dateien direkt im Repo	Mittel
Vault mit ArgoCD Vault Plugin	Inline-Referenzen in Manifests	Hoch

Fuer die meisten Setups ist der External Secrets Operator der beste Kompromiss aus Sicherheit und Bedienbarkeit. Mehr dazu in unserem Artikel zu Kubernetes Secrets Management.

Monitoring der ArgoCD-Instanz

ArgoCD exponiert Prometheus-Metriken auf Port 8083. Wichtige Metriken:

# ServiceMonitor fuer ArgoCD
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-metrics
  namespace: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  endpoints:
    - port: metrics
      interval: 30s

Kritische Alerts, die Sie einrichten sollten:

argocd_app_info{sync_status="OutOfSync"} -- Anwendung weicht vom Git-Zustand ab
argocd_app_info{health_status="Degraded"} -- Anwendung ist nicht gesund
argocd_app_sync_total{phase="Error"} -- Sync-Fehler zaehlen

Weiterfuehrend: Kubernetes Monitoring und Observability

Typische Fehler bei der Einfuehrung

Zu frueh automated sync aktivieren -- Starten Sie mit manuellem Sync, bis das Team Vertrauen in den Prozess hat
Kein AppProject-RBAC -- Ohne Projects kann jede Application auf jeden Namespace zugreifen
Secrets im Git-Repo -- Auch in privaten Repos gehoeren Secrets nicht als Klartext hinein
Zu grosse Applications -- Eine Application pro Microservice, nicht eine fuer den gesamten Stack
Fehlende Health Checks -- ArgoCD kann nur korrekt synchronisieren, wenn Deployments Readiness-/Liveness-Probes haben

Rollout-Plan fuer die Einfuehrung

Phase	Dauer	Ziel
PoC	1-2 Wochen	ArgoCD auf Dev-Cluster, ein Team, ein Service
Pilot	2-4 Wochen	2-3 Teams, Staging-Umgebung, SSO + RBAC
Rollout	4-8 Wochen	Alle Teams, Produktion, Monitoring + Alerting
Optimierung	Laufend	ApplicationSets, Image Updater, Multi-Cluster

Weiterführende Ressourcen

Sie planen die Einfuehrung von GitOps mit ArgoCD? Wir unterstuetzen Sie von der Architekturplanung ueber die Implementierung bis zum Betrieb. Sprechen Sie uns an -- als erfahrene Kubernetes-Berater kennen wir die typischen Stolpersteine und helfen Ihnen, sie zu vermeiden.