ArgoCD Enterprise: App-of-Apps, RBAC & SSO Guide (2026)

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.

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.