unpdate tsl sync
This commit is contained in:
@@ -1,270 +0,0 @@
|
||||
# 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 :
|
||||
|
||||
```bash
|
||||
# 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 :
|
||||
|
||||
```bash
|
||||
helm install tls-sync ./helm/tls-sync/ops \
|
||||
-n certificates-ops \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
### 3. Vérifier le déploiement
|
||||
|
||||
```bash
|
||||
# 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` :
|
||||
|
||||
```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
|
||||
|
||||
```yaml
|
||||
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
|
||||
|
||||
```bash
|
||||
# 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
|
||||
|
||||
```bash
|
||||
# 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.
|
||||
|
||||
```bash
|
||||
# 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 :
|
||||
```bash
|
||||
kubectl get certificates -n certificates-ops
|
||||
```
|
||||
|
||||
2. Vérifier que les secrets TLS existent dans OPS :
|
||||
```bash
|
||||
kubectl get secrets -n certificates-ops | grep tls
|
||||
```
|
||||
|
||||
3. Vérifier que les contextes kubectl sont corrects :
|
||||
```bash
|
||||
kubectl config get-contexts
|
||||
```
|
||||
|
||||
4. Vérifier les logs du Job pour voir les erreurs spécifiques
|
||||
|
||||
## Monitoring
|
||||
|
||||
### Vérifier l'historique des synchronisations
|
||||
|
||||
```bash
|
||||
# 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.
|
||||
|
||||
@@ -17,10 +17,11 @@ Ce CronJob automatise cette synchronisation.
|
||||
Le CronJob a besoin d'accéder aux différents clusters. Créez un Secret contenant les kubeconfigs :
|
||||
|
||||
```bash
|
||||
# Option 1 : En root Utiliser le kubeconfig par défaut (si tous les contextes sont dedans)
|
||||
# Option 1 : Utiliser le kubeconfig par défaut (si tous les contextes sont dedans)
|
||||
kubectl create secret generic tls-sync-kubeconfig \
|
||||
--from-file=config=$HOME/.kube/config \
|
||||
-n certificates-ops \
|
||||
--context=cluster-ops \
|
||||
--dry-run=client -o yaml | kubectl apply -f -
|
||||
|
||||
# Option 2 : Créer un kubeconfig combiné avec tous les contextes
|
||||
@@ -28,25 +29,21 @@ 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 \
|
||||
--context=cluster-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`.
|
||||
**Important** : Assurez-vous que le fichier dans le Secret s'appelle `config` pour que kubectl le trouve automatiquement dans `/home/user/.kube/config`.
|
||||
|
||||
### 2. Créer le ConfigMap avec le script
|
||||
### 2. Le ConfigMap avec le script est créé automatiquement
|
||||
|
||||
Le script de synchronisation doit être disponible dans un ConfigMap :
|
||||
|
||||
```bash
|
||||
kubectl create configmap tls-sync-wildcard-script \
|
||||
--from-file=sync-all-certificates.sh=../../scripts/sync-all-certificates.sh \
|
||||
-n certificates-ops \
|
||||
--dry-run=client -o yaml | kubectl apply -f -
|
||||
```
|
||||
Le script de synchronisation est automatiquement inclus dans le chart Helm via un ConfigMap. Aucune action manuelle n'est nécessaire.
|
||||
|
||||
### 3. Déployer via ArgoCD
|
||||
|
||||
Créez un ApplicationSet ou une Application ArgoCD pour déployer ce chart :
|
||||
Le chart est déployé automatiquement via l'ApplicationSet `applicationset-tls-sync-wildcard.yaml`.
|
||||
|
||||
Pour un déploiement manuel :
|
||||
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
@@ -76,6 +73,7 @@ spec:
|
||||
```bash
|
||||
helm install tls-sync-wildcard ./helm/tls-sync-wildcard/ops \
|
||||
-n certificates-ops \
|
||||
--context=cluster-ops \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
@@ -111,16 +109,16 @@ esac
|
||||
|
||||
```bash
|
||||
# Vérifier le CronJob
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Vérifier les Jobs créés
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Voir les logs du dernier Job
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --tail=100
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=100
|
||||
|
||||
# Déclencher manuellement une synchronisation
|
||||
kubectl create job --from=cronjob/tls-sync-wildcard tls-sync-wildcard-manual-$(date +%s) -n certificates-ops
|
||||
kubectl create job --from=cronjob/tls-sync-wildcard tls-sync-wildcard-manual-$(date +%s) -n certificates-ops --context=cluster-ops
|
||||
```
|
||||
|
||||
## Dépannage
|
||||
@@ -129,20 +127,20 @@ kubectl create job --from=cronjob/tls-sync-wildcard tls-sync-wildcard-manual-$(d
|
||||
|
||||
```bash
|
||||
# Vérifier le schedule
|
||||
kubectl get cronjob tls-sync-wildcard -n certificates-ops -o yaml | grep schedule
|
||||
kubectl get cronjob tls-sync-wildcard -n certificates-ops --context=cluster-ops -o yaml | grep schedule
|
||||
|
||||
# Vérifier les événements
|
||||
kubectl get events -n certificates-ops --sort-by='.lastTimestamp' | grep tls-sync-wildcard
|
||||
kubectl get events -n certificates-ops --context=cluster-ops --sort-by='.lastTimestamp' | grep tls-sync-wildcard
|
||||
```
|
||||
|
||||
### Les Jobs échouent
|
||||
|
||||
```bash
|
||||
# Voir les logs du dernier Job
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --tail=100
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=100
|
||||
|
||||
# Vérifier les erreurs
|
||||
kubectl describe job -n certificates-ops -l app=tls-sync-wildcard
|
||||
kubectl describe job -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops
|
||||
```
|
||||
|
||||
### Erreur "context not found"
|
||||
@@ -151,20 +149,21 @@ Le Secret `tls-sync-kubeconfig` n'est pas correctement configuré ou les context
|
||||
|
||||
```bash
|
||||
# Vérifier le Secret
|
||||
kubectl get secret tls-sync-kubeconfig -n certificates-ops -o yaml
|
||||
kubectl get secret tls-sync-kubeconfig -n certificates-ops --context=cluster-ops -o yaml
|
||||
|
||||
# Tester l'accès depuis un pod
|
||||
kubectl run -it --rm debug --image=bitnami/kubectl:1.31 --restart=Never \
|
||||
kubectl run -it --rm debug --image=alpine/k8s:1.33.0 --restart=Never \
|
||||
-n certificates-ops \
|
||||
--context=cluster-ops \
|
||||
--overrides='
|
||||
{
|
||||
"spec": {
|
||||
"containers": [{
|
||||
"name": "debug",
|
||||
"image": "bitnami/kubectl:1.31",
|
||||
"image": "alpine/k8s:1.33.0",
|
||||
"volumeMounts": [{
|
||||
"name": "kubeconfig",
|
||||
"mountPath": "/root/.kube",
|
||||
"mountPath": "/home/user/.kube",
|
||||
"readOnly": true
|
||||
}]
|
||||
}],
|
||||
@@ -179,6 +178,25 @@ kubectl run -it --rm debug --image=bitnami/kubectl:1.31 --restart=Never \
|
||||
-- kubectl config get-contexts
|
||||
```
|
||||
|
||||
### Erreur "jq: command not found"
|
||||
|
||||
L'image utilisée ne contient pas `jq`. Vérifiez que l'image dans `values.yaml` contient `jq` :
|
||||
|
||||
```yaml
|
||||
image:
|
||||
repository: alpine/k8s # Contient kubectl et jq
|
||||
tag: "1.33.0"
|
||||
```
|
||||
|
||||
## Sécurité
|
||||
|
||||
Le CronJob s'exécute avec les meilleures pratiques de sécurité :
|
||||
|
||||
- ✅ **Non-root** : Le conteneur s'exécute avec l'UID 1000 (utilisateur non-privilégié)
|
||||
- ✅ **Pas d'élévation de privilèges** : `allowPrivilegeEscalation: false`
|
||||
- ✅ **Capabilities minimales** : Toutes les capabilities Linux sont supprimées
|
||||
- ✅ **Image sécurisée** : Utilise une image qui contient déjà tous les outils nécessaires (pas d'installation de paquets)
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
@@ -206,3 +224,8 @@ kubectl run -it --rm debug --image=bitnami/kubectl:1.31 --restart=Never \
|
||||
└─── (même principe)
|
||||
```
|
||||
|
||||
## Scripts utiles
|
||||
|
||||
- `scripts/sync-all-certificates.sh` : Script de synchronisation (utilisé par le CronJob)
|
||||
- `scripts/verify-tls-sync.sh` : Script de vérification du fonctionnement
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
# Exemple de Dockerfile pour créer une image personnalisée SLE avec kubectl et jq
|
||||
# Usage: docker build -t harbor.gkdomaine.local/images/kubectl-sle:1.33.0 -f Dockerfile.example .
|
||||
|
||||
FROM registry.suse.com/caasp/v4/kubectl:1.33
|
||||
|
||||
# Installer jq (nécessite root pour l'installation)
|
||||
USER root
|
||||
RUN zypper --non-interactive install -y jq && \
|
||||
zypper clean -a
|
||||
|
||||
# Créer un utilisateur non-root
|
||||
RUN useradd -u 1000 -m -s /bin/bash user && \
|
||||
mkdir -p /home/user/.kube && \
|
||||
chown -R user:user /home/user
|
||||
|
||||
# Passer à l'utilisateur non-root
|
||||
USER user
|
||||
WORKDIR /home/user
|
||||
|
||||
# Vérifier que kubectl et jq sont disponibles
|
||||
RUN kubectl version --client && jq --version
|
||||
|
||||
@@ -1,268 +0,0 @@
|
||||
# Guide de Vérification - TLS Sync Wildcard
|
||||
|
||||
Ce guide vous explique comment vérifier que le CronJob de synchronisation des certificats wildcard fonctionne correctement.
|
||||
|
||||
## 1. Vérifier que le CronJob est déployé
|
||||
|
||||
```bash
|
||||
# Vérifier que le CronJob existe
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Voir les détails du CronJob
|
||||
kubectl describe cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Vérifier le schedule configuré
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops -o jsonpath='{.spec.schedule}' && echo
|
||||
```
|
||||
|
||||
**Résultat attendu** : Le CronJob doit être présent avec un schedule (par exemple `0 * * * *` pour toutes les heures).
|
||||
|
||||
## 2. Vérifier que les Jobs sont créés
|
||||
|
||||
```bash
|
||||
# Lister tous les Jobs créés par le CronJob
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Voir les Jobs récents (dernières 24h)
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --sort-by=.metadata.creationTimestamp | tail -5
|
||||
|
||||
# Vérifier le statut du dernier Job
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops -o wide | head -2
|
||||
```
|
||||
|
||||
**Résultat attendu** : Vous devriez voir des Jobs avec le statut `Complete` ou `Running`.
|
||||
|
||||
## 3. Voir les logs des Jobs
|
||||
|
||||
```bash
|
||||
# Voir les logs du dernier Job
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=100
|
||||
|
||||
# Voir les logs d'un Job spécifique
|
||||
JOB_NAME=$(kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1].metadata.name}')
|
||||
kubectl logs -n certificates-ops job/$JOB_NAME --context=cluster-ops
|
||||
|
||||
# Suivre les logs en temps réel (si un Job est en cours)
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops -f
|
||||
```
|
||||
|
||||
**Résultat attendu** : Les logs doivent montrer :
|
||||
- `=== Synchronisation automatique des secrets TLS ===`
|
||||
- `📋 Traitement du certificat: wildcard-dev-tls`
|
||||
- `🌐 Certificat wildcard détecté`
|
||||
- `✅ Synchronisé avec succès dans <namespace>`
|
||||
|
||||
## 4. Vérifier que les secrets sont synchronisés
|
||||
|
||||
### Dans le cluster DEV
|
||||
|
||||
```bash
|
||||
# Vérifier que le secret existe dans headlamp-dev
|
||||
kubectl get secret wildcard-dev-tls -n headlamp-dev --context=cluster-dev
|
||||
|
||||
# Vérifier que le secret existe dans homarr-dev
|
||||
kubectl get secret wildcard-dev-tls -n homarr-dev --context=cluster-dev
|
||||
|
||||
# Vérifier que le secret existe dans longhorn-dev
|
||||
kubectl get secret wildcard-dev-tls -n longhorn-dev --context=cluster-dev
|
||||
|
||||
# Vérifier les détails d'un secret (date de création, taille, etc.)
|
||||
kubectl describe secret wildcard-dev-tls -n headlamp-dev --context=cluster-dev
|
||||
```
|
||||
|
||||
**Résultat attendu** : Les secrets doivent exister dans tous les namespaces configurés.
|
||||
|
||||
### Comparer les secrets entre namespaces
|
||||
|
||||
```bash
|
||||
# Comparer les certificats (doivent être identiques)
|
||||
kubectl get secret wildcard-dev-tls -n certificates-ops --context=cluster-ops -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -dates
|
||||
kubectl get secret wildcard-dev-tls -n headlamp-dev --context=cluster-dev -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -dates
|
||||
```
|
||||
|
||||
**Résultat attendu** : Les certificats doivent être identiques (même sujet, mêmes dates).
|
||||
|
||||
## 5. Déclencher manuellement une synchronisation
|
||||
|
||||
```bash
|
||||
# Créer un Job manuel à partir du CronJob
|
||||
kubectl create job --from=cronjob/tls-sync-wildcard tls-sync-wildcard-manual-$(date +%s) -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Attendre quelques secondes puis voir les logs
|
||||
sleep 5
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=50
|
||||
```
|
||||
|
||||
**Résultat attendu** : Un nouveau Job est créé et exécuté immédiatement.
|
||||
|
||||
## 6. Vérifier les permissions RBAC
|
||||
|
||||
```bash
|
||||
# Vérifier que le ServiceAccount existe
|
||||
kubectl get serviceaccount tls-sync-wildcard -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Vérifier que le ClusterRole existe
|
||||
kubectl get clusterrole tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Vérifier que le ClusterRoleBinding existe
|
||||
kubectl get clusterrolebinding tls-sync-wildcard --context=cluster-ops
|
||||
|
||||
# Tester les permissions du ServiceAccount
|
||||
kubectl auth can-i get secrets --namespace=certificates-ops --as=system:serviceaccount:certificates-ops:tls-sync-wildcard --context=cluster-ops
|
||||
kubectl auth can-i create secrets --namespace=headlamp-dev --as=system:serviceaccount:certificates-ops:tls-sync-wildcard --context=cluster-dev
|
||||
```
|
||||
|
||||
**Résultat attendu** : Toutes les commandes doivent retourner `yes`.
|
||||
|
||||
## 7. Vérifier le ConfigMap avec le script
|
||||
|
||||
```bash
|
||||
# Vérifier que le ConfigMap existe
|
||||
kubectl get configmap tls-sync-wildcard-script -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Voir le contenu du script (premières lignes)
|
||||
kubectl get configmap tls-sync-wildcard-script -n certificates-ops --context=cluster-ops -o jsonpath='{.data.sync-all-certificates\.sh}' | head -20
|
||||
```
|
||||
|
||||
**Résultat attendu** : Le ConfigMap doit exister et contenir le script.
|
||||
|
||||
## 8. Vérifier le Secret kubeconfig
|
||||
|
||||
```bash
|
||||
# Vérifier que le Secret existe
|
||||
kubectl get secret tls-sync-kubeconfig -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Vérifier que le fichier config est présent
|
||||
kubectl get secret tls-sync-kubeconfig -n certificates-ops --context=cluster-ops -o jsonpath='{.data.config}' | base64 -d | head -5
|
||||
```
|
||||
|
||||
**Résultat attendu** : Le Secret doit exister et contenir un fichier `config` valide.
|
||||
|
||||
## 9. Script de vérification complète
|
||||
|
||||
Créez un script pour vérifier tout d'un coup :
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Script de vérification complète du TLS Sync
|
||||
|
||||
echo "=== Vérification du TLS Sync Wildcard ==="
|
||||
echo ""
|
||||
|
||||
echo "1. CronJob..."
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops 2>/dev/null && echo "✅ CronJob existe" || echo "❌ CronJob manquant"
|
||||
|
||||
echo ""
|
||||
echo "2. Derniers Jobs..."
|
||||
kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --sort-by=.metadata.creationTimestamp | tail -3
|
||||
|
||||
echo ""
|
||||
echo "3. Secrets dans cluster-dev..."
|
||||
for ns in headlamp-dev homarr-dev longhorn-dev; do
|
||||
if kubectl get secret wildcard-dev-tls -n "$ns" --context=cluster-dev &>/dev/null; then
|
||||
echo "✅ $ns: secret présent"
|
||||
else
|
||||
echo "❌ $ns: secret manquant"
|
||||
fi
|
||||
done
|
||||
|
||||
echo ""
|
||||
echo "4. Logs du dernier Job..."
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=20 2>/dev/null | tail -5
|
||||
|
||||
echo ""
|
||||
echo "=== Vérification terminée ==="
|
||||
```
|
||||
|
||||
## 10. Dépannage des problèmes courants
|
||||
|
||||
### Le CronJob ne crée pas de Jobs
|
||||
|
||||
```bash
|
||||
# Vérifier les événements
|
||||
kubectl get events -n certificates-ops --context=cluster-ops --sort-by='.lastTimestamp' | grep tls-sync-wildcard | tail -10
|
||||
|
||||
# Vérifier le schedule
|
||||
kubectl get cronjob -n certificates-ops tls-sync-wildcard --context=cluster-ops -o yaml | grep -A 2 schedule
|
||||
```
|
||||
|
||||
### Les Jobs échouent
|
||||
|
||||
```bash
|
||||
# Voir les détails du Job en échec
|
||||
kubectl describe job -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops | tail -30
|
||||
|
||||
# Voir les logs d'erreur
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=100 | grep -i error
|
||||
```
|
||||
|
||||
### Les secrets ne sont pas synchronisés
|
||||
|
||||
```bash
|
||||
# Vérifier que le certificat source existe
|
||||
kubectl get certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Vérifier que le secret source existe
|
||||
kubectl get secret wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
||||
|
||||
# Vérifier les logs pour voir pourquoi la synchronisation a échoué
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=200 | grep -A 10 "wildcard-dev-tls"
|
||||
```
|
||||
|
||||
### Erreur "context not found"
|
||||
|
||||
```bash
|
||||
# Vérifier que le Secret kubeconfig contient tous les contextes
|
||||
kubectl get secret tls-sync-kubeconfig -n certificates-ops --context=cluster-ops -o jsonpath='{.data.config}' | base64 -d | grep -E "contexts:|name:"
|
||||
|
||||
# Tester l'accès aux clusters depuis un pod de test
|
||||
kubectl run -it --rm test-kubeconfig --image=bitnami/kubectl:1.31 --restart=Never \
|
||||
-n certificates-ops \
|
||||
--context=cluster-ops \
|
||||
--overrides='
|
||||
{
|
||||
"spec": {
|
||||
"containers": [{
|
||||
"name": "test-kubeconfig",
|
||||
"image": "bitnami/kubectl:1.31",
|
||||
"volumeMounts": [{
|
||||
"name": "kubeconfig",
|
||||
"mountPath": "/root/.kube",
|
||||
"readOnly": true
|
||||
}]
|
||||
}],
|
||||
"volumes": [{
|
||||
"name": "kubeconfig",
|
||||
"secret": {
|
||||
"secretName": "tls-sync-kubeconfig"
|
||||
}
|
||||
}]
|
||||
}
|
||||
}' \
|
||||
-- kubectl config get-contexts
|
||||
```
|
||||
|
||||
## 11. Monitoring continu
|
||||
|
||||
Pour surveiller en continu :
|
||||
|
||||
```bash
|
||||
# Watch les Jobs
|
||||
watch -n 5 'kubectl get jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops'
|
||||
|
||||
# Watch les secrets dans un namespace
|
||||
watch -n 10 'kubectl get secret wildcard-dev-tls -n headlamp-dev --context=cluster-dev'
|
||||
```
|
||||
|
||||
## Résumé des commandes essentielles
|
||||
|
||||
```bash
|
||||
# Vérification rapide (tout en une fois)
|
||||
kubectl get cronjob,jobs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops && \
|
||||
kubectl logs -n certificates-ops -l app=tls-sync-wildcard --context=cluster-ops --tail=30 && \
|
||||
echo "--- Secrets dans cluster-dev ---" && \
|
||||
kubectl get secret wildcard-dev-tls -n headlamp-dev --context=cluster-dev && \
|
||||
kubectl get secret wildcard-dev-tls -n homarr-dev --context=cluster-dev && \
|
||||
kubectl get secret wildcard-dev-tls -n longhorn-dev --context=cluster-dev
|
||||
```
|
||||
|
||||
@@ -1,21 +1,17 @@
|
||||
# Configuration pour le CronJob de synchronisation des secrets TLS wildcard
|
||||
tlsSync:
|
||||
# Schedule Cron pour la synchronisation (toutes les heures par défaut)
|
||||
schedule: "*/5 * * * *" # Toutes les 5 minutes
|
||||
schedule: "0 0 * * *" # Toutes les jours à 00:00
|
||||
|
||||
# Cluster source (où les certificats sont générés)
|
||||
sourceCluster: "cluster-ops"
|
||||
sourceNamespace: "certificates-ops"
|
||||
sourceCluster: "cluster-ops" # Cluster OPS
|
||||
sourceNamespace: "certificates-ops" # Namespace des certificats
|
||||
|
||||
# Image à utiliser (doit contenir kubectl, bash ET jq)
|
||||
# IMPORTANT: L'image doit contenir jq car le conteneur s'exécute en non-root (sécurité)
|
||||
# Options recommandées:
|
||||
# - alpine/k8s (contient kubectl et jq)
|
||||
# - bitnami/kubectl (contient kubectl, peut nécessiter jq)
|
||||
# - Image personnalisée basée sur SLE avec jq pré-installé
|
||||
image:
|
||||
repository: alpine/k8s
|
||||
tag: "1.33.0" # Version de kubectl
|
||||
tag: "1.33.0" # Version de kubectl (doit contenir jq)
|
||||
pullPolicy: IfNotPresent
|
||||
|
||||
# Ressources
|
||||
|
||||
Reference in New Issue
Block a user