argocd/docs/AUTOMATISATION-SYNC-TLS.md

Automatisation de la Synchronisation des Secrets TLS

Vue d'ensemble

Ce document décrit les différentes options pour automatiser la synchronisation des secrets TLS depuis le cluster OPS (où cert-manager génère les certificats) vers les clusters DEV, RCT et PRD (où les applications sont déployées).

Architecture

┌─────────────────┐
│  Cluster OPS    │
│                 │
│  cert-manager   │─── Génère les certificats Let's Encrypt
│                 │
│  Certificates   │─── Crée les secrets TLS dans certificates-ops
│                 │
│  CronJob        │─── Synchronise automatiquement les secrets
│  tls-sync       │    vers les autres clusters
└─────────────────┘
         │
         ├───► Cluster DEV (homarr-dev, headlamp-dev, etc.)
         ├───► Cluster RCT (applications RCT)
         └───► Cluster PRD (applications PRD)

Solution Implémentée : CronJob Kubernetes

Avantages

✅ Simple et fiable : Utilise les ressources Kubernetes natives
✅ GitOps compatible : Déployé via ArgoCD depuis Git
✅ Facile à déboguer : Logs disponibles via kubectl logs
✅ Configurable : Fréquence de synchronisation ajustable
✅ Robuste : Gestion automatique des erreurs et retry

Inconvénients

⚠️ Délai de synchronisation : Maximum 1 heure (selon la fréquence configurée)
⚠️ Nécessite les kubeconfigs : Les contextes kubectl doivent être disponibles dans le pod

Installation

1. Créer le Secret avec les kubeconfigs

Le CronJob a besoin d'accéder aux différents clusters. Créez un Secret contenant les kubeconfigs :

# Option 1 : Utiliser le kubeconfig par défaut (si tous les contextes sont dedans)
kubectl create secret generic tls-sync-kubeconfig \
  --from-file=config=/root/.kube/config \
  -n certificates-ops \
  --dry-run=client -o yaml | kubectl apply -f -

# Option 2 : Créer un kubeconfig combiné avec tous les contextes
# (recommandé si vous avez plusieurs fichiers kubeconfig)
kubectl config view --flatten > /tmp/combined-kubeconfig.yaml
kubectl create secret generic tls-sync-kubeconfig \
  --from-file=config=/tmp/combined-kubeconfig.yaml \
  -n certificates-ops \
  --dry-run=client -o yaml | kubectl apply -f -

Important : Assurez-vous que le fichier dans le Secret s'appelle config pour que kubectl le trouve automatiquement dans /root/.kube/config.

2. Déployer via ArgoCD

Le chart Helm est déjà configuré dans apps/applicationset-tls-sync.yaml. ArgoCD le déploiera automatiquement sur le cluster OPS.

Si vous préférez déployer manuellement :

helm install tls-sync ./helm/tls-sync/ops \
  -n certificates-ops \
  --create-namespace

3. Vérifier le déploiement

# Vérifier le CronJob
kubectl get cronjob -n certificates-ops

# Vérifier les Jobs créés
kubectl get jobs -n certificates-ops -l app=tls-sync

# Voir les logs du dernier Job
kubectl logs -n certificates-ops -l app=tls-sync --tail=100

# Déclencher manuellement une synchronisation
kubectl create job --from=cronjob/tls-sync tls-sync-manual-$(date +%s) -n certificates-ops

Configuration

Modifier la fréquence de synchronisation

Éditez helm/tls-sync/ops/values.yaml :

tlsSync:
  schedule: "0 */2 * * *"  # Toutes les 2 heures
  # Autres exemples :
  # "0 * * * *"     - Toutes les heures
  # "*/30 * * * *"  - Toutes les 30 minutes
  # "0 0 * * *"     - Tous les jours à minuit

Modifier les ressources

tlsSync:
  resources:
    requests:
      memory: "128Mi"
      cpu: "100m"
    limits:
      memory: "256Mi"
      cpu: "500m"

Alternatives

Option 1 : Watch/Webhook (Réactif)

Utiliser un opérateur Kubernetes qui surveille les changements de secrets et synchronise immédiatement.

Avantages :

• Synchronisation instantanée
• Réactif aux changements

Inconvénients :

• Plus complexe à mettre en place
• Nécessite un opérateur personnalisé ou External Secrets Operator
• Plus de ressources consommées

Option 2 : External Secrets Operator

Utiliser ESO pour synchroniser les secrets depuis un backend (comme Kubernetes secrets dans OPS).

Avantages :

• Solution standardisée
• Support multi-cluster natif

Inconvénients :

• Nécessite d'installer ESO sur tous les clusters
• Configuration plus complexe
• Overhead supplémentaire

Option 3 : ArgoCD Application (GitOps)

Créer des Applications ArgoCD qui référencent les secrets TLS depuis OPS.

Avantages :

• Complètement GitOps
• Intégré avec ArgoCD

Inconvénients :

• Les secrets ne sont pas dans Git (contraire aux pratiques GitOps)
• Nécessite une configuration complexe avec des secrets externes

Dépannage

Le CronJob ne se déclenche pas

# Vérifier le schedule
kubectl get cronjob tls-sync -n certificates-ops -o yaml | grep schedule

# Vérifier les événements
kubectl get events -n certificates-ops --sort-by='.lastTimestamp' | grep tls-sync

Les Jobs échouent

# Voir les logs du dernier Job
kubectl logs -n certificates-ops -l app=tls-sync --tail=100

# Vérifier les erreurs
kubectl describe job -n certificates-ops -l app=tls-sync

Erreur "context not found"

Le Secret tls-sync-kubeconfig n'est pas correctement configuré ou les contextes kubectl ne sont pas disponibles.

# Vérifier le Secret
kubectl get secret tls-sync-kubeconfig -n certificates-ops -o yaml

# Tester l'accès depuis un pod
kubectl run -it --rm debug --image=bitnami/kubectl:1.31 --restart=Never \
  --overrides='
{
  "spec": {
    "containers": [{
      "name": "debug",
      "image": "bitnami/kubectl:1.31",
      "command": ["/bin/sh"],
      "args": ["-c", "sleep 3600"],
      "volumeMounts": [{
        "name": "kubeconfig",
        "mountPath": "/root/.kube"
      }]
    }],
    "volumes": [{
      "name": "kubeconfig",
      "secret": {
        "secretName": "tls-sync-kubeconfig"
      }
    }]
  }
}' -n certificates-ops

# Dans le pod, tester :
kubectl config get-contexts
kubectl get nodes --context=cluster-dev

Les secrets ne sont pas synchronisés

1. Vérifier que les certificats existent dans OPS :

   kubectl get certificates -n certificates-ops
   

2. Vérifier que les secrets TLS existent dans OPS :

   kubectl get secrets -n certificates-ops | grep tls
   

3. Vérifier que les contextes kubectl sont corrects :

   kubectl config get-contexts
   

4. Vérifier les logs du Job pour voir les erreurs spécifiques

Monitoring

Vérifier l'historique des synchronisations

# Voir tous les Jobs créés par le CronJob
kubectl get jobs -n certificates-ops -l app=tls-sync --sort-by=.metadata.creationTimestamp

# Voir les logs de tous les Jobs réussis
for job in $(kubectl get jobs -n certificates-ops -l app=tls-sync -o name | grep -v "No resources"); do
  echo "=== $job ==="
  kubectl logs -n certificates-ops $job
done

Alertes (optionnel)

Vous pouvez créer des alertes Prometheus pour surveiller :

• Le nombre de Jobs échoués
• La durée d'exécution des Jobs
• Le nombre de secrets synchronisés

Conclusion

La solution CronJob est recommandée car elle est :

• ✅ Simple à mettre en place
• ✅ Fiable et robuste
• ✅ Compatible avec GitOps
• ✅ Facile à maintenir et déboguer

Pour la plupart des cas d'usage, une synchronisation toutes les heures est suffisante, car les certificats Let's Encrypt sont valides pendant 90 jours et sont renouvelés automatiquement 30 jours avant expiration.