GitOps production : RBAC, notifications et DR

ArgoCD tourne, les apps se synchronisent, le Progressive Delivery est en place. Il reste trois piliers pour un GitOps production-ready : le RBAC pour contrôler qui fait quoi, les notifications pour savoir ce qui se passe, et un plan de disaster recovery pour dormir tranquille.

RBAC ArgoCD : qui peut déployer quoi et où

ArgoCD utilise Casbin pour son moteur RBAC. Le principe : tu définis des rôles avec des permissions granulaires, puis tu mappes tes groupes SSO vers ces rôles. La syntaxe est simple mais puissante.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly
  policy.csv: |
    # Équipe dev : voir et sync les apps du projet dev
    p, role:dev-team, applications, get, dev/*, allow
    p, role:dev-team, applications, sync, dev/*, allow
    p, role:dev-team, applications, action/*, dev/*, allow
    p, role:dev-team, logs, get, dev/*, allow

    # Équipe ops : accès complet
    p, role:ops-team, applications, *, */*, allow
    p, role:ops-team, clusters, get, *, allow
    p, role:ops-team, repositories, *, *, allow

    # Release managers : sync prod mais pas override
    p, role:release-mgr, applications, get, prod/*, allow
    p, role:release-mgr, applications, sync, prod/*, allow
    p, role:release-mgr, applications, override, prod/*, deny

    # Mapping groupes OIDC → rôles
    g, dev-team, role:dev-team
    g, ops-team, role:ops-team
    g, release-managers, role:release-mgr

🔥 policy.default: role:readonly est non-négociable. Sans ça, tout utilisateur authentifié a accès admin par défaut. C’est la première ligne à configurer après l’installation.

SSO avec OIDC

Le RBAC prend tout son sens avec le SSO. Tu connectes ArgoCD à ton identity provider (Keycloak, Okta, Azure AD) et les groupes utilisateur se mappent automatiquement aux rôles.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.company.com
  oidc.config: |
    name: Keycloak
    issuer: https://keycloak.company.com/realms/devops
    clientID: argocd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes:
      - openid
      - profile
      - email
      - groups
    requestedIDTokenClaims:
      groups:
        essential: true

💡 Teste les permissions avec argocd account can-i sync applications prod/myapp — ça évite les mauvaises surprises en production.

Notifications : savoir ce qui se passe en temps réel

ArgoCD Notifications envoie des alertes sur les événements clés : sync réussi, sync échoué, health dégradée. La config se fait via un ConfigMap avec trois concepts : services (où envoyer), templates (quoi envoyer), et triggers (quand envoyer).

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token

  template.app-sync-succeeded: |
    slack:
      attachments: |
        [{
          "color": "#18be52",
          "title": "✅ {{ .app.metadata.name }} synced",
          "text": "Revision {{ .app.status.sync.revision | truncate 7 }} deployed to {{ .app.spec.destination.namespace }}",
          "fields": [{
            "title": "Project",
            "value": "{{ .app.spec.project }}",
            "short": true
          }]
        }]

  template.app-health-degraded: |
    slack:
      attachments: |
        [{
          "color": "#e8463a",
          "title": "🔴 {{ .app.metadata.name }} DEGRADED",
          "text": "Health check failed — investigate immediately"
        }]

  trigger.on-sync-succeeded: |
    - when: app.status.operationState.phase in ['Succeeded']
      send: [app-sync-succeeded]

  trigger.on-health-degraded: |
    - when: app.status.health.status == 'Degraded'
      send: [app-health-degraded]

Pour activer les notifications sur une Application, une annotation suffit :

metadata:
  annotations:
    notifications.argoproj.io/subscribe.on-sync-succeeded.slack: devops-deploys
    notifications.argoproj.io/subscribe.on-health-degraded.slack: devops-alerts

⚠️ Ne notifie pas tout sur le même canal Slack. Sépare les déploiements routine (devops-deploys) des alertes critiques (devops-alerts). Sinon, l’alerte importante se noie dans le bruit.

Disaster Recovery : le cluster est jetable

Le principe fondamental du GitOps DR : ton repo Git EST ta source de vérité. Si le cluster meurt, tu en crées un nouveau et ArgoCD re-synchronise tout automatiquement. Le cluster est jetable, Git est éternel.

Mais Git ne contient pas tout. Les secrets, les volumes persistants, et la config ArgoCD elle-même doivent être sauvegardés séparément.

# Ce que Git ne contient PAS et qu'il faut sauvegarder
# 1. Secrets ArgoCD (repos, clusters)
kubectl get secrets -n argocd \
  -l argocd.argoproj.io/secret-type=repository \
  -o yaml > backup-argocd-repos.yaml

# 2. Config ArgoCD (Applications, Projects)
kubectl get applications -n argocd -o yaml > backup-apps.yaml
kubectl get appprojects -n argocd -o yaml > backup-projects.yaml

# 3. Volumes persistants (Velero)
velero backup create dr-backup \
  --include-namespaces production,staging \
  --snapshot-volumes=true \
  --ttl 720h

Le pattern App-of-Apps pour un DR en 5 minutes

Le secret d’un DR rapide : une seule Application racine qui déploie toutes les autres. Tu crées cette root-app manuellement, et ArgoCD cascade la réconciliation sur tout le stack.

# root-app.yaml — La seule chose à appliquer manuellement
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/company/gitops-config
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

La procédure DR complète :

# 1. Provisionner le nouveau cluster
terraform apply -var="cluster_name=prod-recovery"

# 2. Installer ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 3. Restaurer les secrets (Sealed Secrets key ou Vault config)
kubectl apply -f sealed-secrets-key-backup.yaml

# 4. Appliquer la root-app — ArgoCD cascade tout
kubectl apply -f root-app.yaml
# → 30 Applications créées et synchronisées en 5-10 minutes

🎯 Temps cible : 15 minutes pour un stack complet. Teste-le trimestriellement — un plan de DR non testé n’est pas un plan.

Cas entreprise : une scale-up qui a perdu son cluster

Une scale-up SaaS avec 30 microservices a perdu son cluster de production suite à une erreur Terraform (un terraform destroy accidentel sur le mauvais workspace). Pas de GitOps en place, les manifests étaient appliqués manuellement. Résultat : 8 heures de downtime pour tout reconstruire.

Après avoir adopté le GitOps complet :

• App-of-Apps : une root-app qui déploie les 30 microservices + l’infra (cert-manager, ingress, monitoring)
• External Secrets : tous les secrets proviennent d’AWS Secrets Manager, jamais de Git
• Velero : backup quotidien des PV (bases de données)
• Sync Windows : déploiements prod uniquement lun-ven 10h-17h

Ils ont testé leur DR trimestriellement. Lors d’un vrai incident (corruption etcd), le recovery a pris 12 minutes : 5 minutes pour le cluster Terraform, 2 minutes pour ArgoCD, 5 minutes pour la sync complète.

Pièges classiques et résumé

⚠️ Les secrets oubliés — Git contient les manifests, pas les credentials. Si tu perds le cluster et que tes secrets ne sont pas dans un Vault externe ou un backup chiffré, ton DR échoue. Vérifie régulièrement que le recovery complet fonctionne, secrets inclus.

⚠️ Le RBAC trop permissif — policy.default: "" (vide) donne les droits admin à tout le monde. Toujours commencer par role:readonly et ajouter les permissions explicitement.

🔥 Les Sync Windows sont essentielles mais souvent oubliées. Sans elles, un merge dans main le vendredi soir déclenche un déploiement automatique en prod. Configure un deny le weekend et les jours fériés.

💡 ArgoCD gère sa propre config — Tu peux versionner les ConfigMaps ArgoCD (argocd-cm, argocd-rbac-cm, argocd-notifications-cm) dans le repo Git. ArgoCD se reconfigure tout seul. C’est le GitOps appliqué à lui-même.

Les trois piliers d’un GitOps production-ready : RBAC pour le contrôle d’accès (Casbin + OIDC + groupes mappés), notifications pour la visibilité (Slack, PagerDuty, templates + triggers), et DR pour la résilience (App-of-Apps + External Secrets + Velero). Avec ça, ton cluster est un commodity jetable — toute la valeur est dans Git.