delete wildcard
This commit is contained in:
@@ -1,47 +0,0 @@
|
|||||||
apiVersion: argoproj.io/v1alpha1
|
|
||||||
kind: ApplicationSet
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: argocd-ops
|
|
||||||
spec:
|
|
||||||
generators:
|
|
||||||
# Le webhook OVH est déployé UNIQUEMENT sur le cluster OPS
|
|
||||||
- merge:
|
|
||||||
generators:
|
|
||||||
# Premier générateur : scanne les répertoires Helm pour cert-manager-webhook-ovh
|
|
||||||
- git:
|
|
||||||
repoURL: https://git.gkdomaine.fr/kubernetes/argocd.git
|
|
||||||
revision: main
|
|
||||||
directories:
|
|
||||||
- path: "helm/cert-manager-webhook-ovh/*"
|
|
||||||
# Deuxième générateur : lit la config OPS uniquement
|
|
||||||
- git:
|
|
||||||
repoURL: https://git.gkdomaine.fr/kubernetes/argocd.git
|
|
||||||
revision: main
|
|
||||||
files:
|
|
||||||
- path: "configs/ops/config.json"
|
|
||||||
mergeKeys:
|
|
||||||
- path.basename
|
|
||||||
template:
|
|
||||||
metadata:
|
|
||||||
name: 'cert-manager-webhook-ovh-{{path.basename}}'
|
|
||||||
spec:
|
|
||||||
project: default
|
|
||||||
source:
|
|
||||||
repoURL: '{{repository}}'
|
|
||||||
targetRevision: '{{targetRevision}}'
|
|
||||||
path: '{{helmPath}}/cert-manager-webhook-ovh/{{path.basename}}'
|
|
||||||
helm:
|
|
||||||
valueFiles:
|
|
||||||
- values.yaml
|
|
||||||
destination:
|
|
||||||
# Déploie uniquement sur le cluster OPS
|
|
||||||
name: '{{name}}'
|
|
||||||
namespace: cert-manager-ops
|
|
||||||
syncPolicy:
|
|
||||||
automated:
|
|
||||||
prune: true
|
|
||||||
selfHeal: true
|
|
||||||
syncOptions:
|
|
||||||
- CreateNamespace=true
|
|
||||||
|
|
||||||
@@ -1,79 +0,0 @@
|
|||||||
# Construction de l'Image Docker pour cert-manager-webhook-ovh
|
|
||||||
|
|
||||||
## Problème
|
|
||||||
|
|
||||||
L'image Docker `quay.io/cert-manager-webhook-ovh/cert-manager-webhook-ovh:v1.0.0` n'existe pas ou nécessite une authentification.
|
|
||||||
|
|
||||||
## Solution Recommandée : Utiliser l'Image GitHub Container Registry
|
|
||||||
|
|
||||||
L'image est disponible sur GitHub Container Registry :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
image:
|
|
||||||
repository: ghcr.io/baarde/cert-manager-webhook-ovh
|
|
||||||
tag: "v0.6.1"
|
|
||||||
```
|
|
||||||
|
|
||||||
Cette image est déjà configurée dans `helm/cert-manager-webhook-ovh/ops/values.yaml`.
|
|
||||||
|
|
||||||
## Alternative : Construire l'Image Vous-Même
|
|
||||||
|
|
||||||
Si vous préférez construire l'image vous-même (par exemple pour la pousser sur Harbor) :
|
|
||||||
|
|
||||||
### Étape 1 : Cloner le Repository
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git clone https://github.com/baarde/cert-manager-webhook-ovh.git
|
|
||||||
cd cert-manager-webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
### Étape 2 : Construire l'Image
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Construire l'image
|
|
||||||
docker build -t harbor.gkdomaine.local/images/cert-manager-webhook-ovh:v0.6.1 .
|
|
||||||
|
|
||||||
# Tester l'image localement (optionnel)
|
|
||||||
docker run --rm harbor.gkdomaine.local/images/cert-manager-webhook-ovh:v0.6.1 --help
|
|
||||||
```
|
|
||||||
|
|
||||||
### Étape 3 : Pousser l'Image vers Harbor
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Se connecter à Harbor
|
|
||||||
docker login harbor.gkdomaine.local
|
|
||||||
|
|
||||||
# Pousser l'image
|
|
||||||
docker push harbor.gkdomaine.local/images/cert-manager-webhook-ovh:v0.6.1
|
|
||||||
```
|
|
||||||
|
|
||||||
### Étape 4 : Mettre à jour values.yaml
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
image:
|
|
||||||
repository: harbor.gkdomaine.local/images/cert-manager-webhook-ovh
|
|
||||||
tag: "v0.6.1"
|
|
||||||
pullPolicy: IfNotPresent
|
|
||||||
```
|
|
||||||
|
|
||||||
## Vérification
|
|
||||||
|
|
||||||
Après avoir mis à jour l'image, vérifiez que le pod démarre :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier les pods
|
|
||||||
kubectl get pods -n cert-manager-ops | grep webhook-ovh
|
|
||||||
|
|
||||||
# Voir les logs
|
|
||||||
kubectl logs -n cert-manager-ops -l app=cert-manager-webhook-ovh
|
|
||||||
|
|
||||||
# Vérifier les événements
|
|
||||||
kubectl get events -n cert-manager-ops --sort-by='.lastTimestamp' | grep webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
|
|
||||||
- L'image `ghcr.io/baarde/cert-manager-webhook-ovh:v0.6.1` est publique et devrait fonctionner directement
|
|
||||||
- Si vous utilisez Harbor, vous pouvez construire et pousser l'image pour un contrôle total
|
|
||||||
- Assurez-vous que votre cluster peut accéder à GitHub Container Registry ou à Harbor selon votre choix
|
|
||||||
|
|
||||||
@@ -1,147 +0,0 @@
|
|||||||
# Création du Secret OVH pour cert-manager
|
|
||||||
|
|
||||||
## Problème
|
|
||||||
|
|
||||||
Le Secret `ovh-credentials` n'existe pas dans le namespace `certificates-ops`, ce qui empêche cert-manager d'utiliser le provider OVH.
|
|
||||||
|
|
||||||
## Solution
|
|
||||||
|
|
||||||
Créez le Secret avec votre Application Secret OVH.
|
|
||||||
|
|
||||||
## Étape 1 : Récupérer votre Application Secret OVH
|
|
||||||
|
|
||||||
Si vous ne l'avez plus, vous devez créer une nouvelle application API OVH :
|
|
||||||
|
|
||||||
1. Allez sur [https://eu.api.ovh.com/createApp/](https://eu.api.ovh.com/createApp/)
|
|
||||||
2. Créez une nouvelle application
|
|
||||||
3. Notez l'**Application Secret** (vous ne pourrez plus le voir après)
|
|
||||||
|
|
||||||
## Étape 2 : Créer le Secret Kubernetes
|
|
||||||
|
|
||||||
### Option 1 : Création directe (Recommandée)
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-literal=application-secret=VOTRE_APPLICATION_SECRET \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
**Remplacez `VOTRE_APPLICATION_SECRET`** par votre vrai Application Secret OVH.
|
|
||||||
|
|
||||||
### Option 2 : Création depuis un fichier
|
|
||||||
|
|
||||||
Créez un fichier `ovh-secret.txt` avec votre Application Secret :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
echo -n 'VOTRE_APPLICATION_SECRET' > ovh-secret.txt
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-file=application-secret=ovh-secret.txt \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
rm ovh-secret.txt # Supprimez le fichier après création
|
|
||||||
```
|
|
||||||
|
|
||||||
### Option 3 : Création via YAML
|
|
||||||
|
|
||||||
Créez un fichier `ovh-credentials-secret.yaml` :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: v1
|
|
||||||
kind: Secret
|
|
||||||
metadata:
|
|
||||||
name: ovh-credentials
|
|
||||||
namespace: certificates-ops
|
|
||||||
type: Opaque
|
|
||||||
data:
|
|
||||||
# Encodez votre Application Secret en base64
|
|
||||||
# echo -n 'VOTRE_APPLICATION_SECRET' | base64
|
|
||||||
application-secret: <VOTRE_SECRET_ENCODE_EN_BASE64>
|
|
||||||
```
|
|
||||||
|
|
||||||
Puis appliquez-le :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl apply -f ovh-credentials-secret.yaml --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 3 : Vérifier le Secret
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier que le Secret existe
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier le contenu (la valeur sera encodée en base64)
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops -o yaml
|
|
||||||
|
|
||||||
# Décoder pour vérifier (optionnel)
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops \
|
|
||||||
-o jsonpath='{.data.application-secret}' | base64 -d
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 4 : Vérifier le ClusterIssuer
|
|
||||||
|
|
||||||
Après avoir créé le Secret, vérifiez que le ClusterIssuer fonctionne :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier le ClusterIssuer
|
|
||||||
kubectl get clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir les détails
|
|
||||||
kubectl describe clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
Vous devriez voir un message indiquant que le ClusterIssuer est prêt.
|
|
||||||
|
|
||||||
## Étape 5 : Tester le Certificat Wildcard
|
|
||||||
|
|
||||||
Une fois le Secret créé, cert-manager devrait pouvoir générer le certificat wildcard :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier le certificat
|
|
||||||
kubectl get certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir les détails
|
|
||||||
kubectl describe certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier les challenges DNS
|
|
||||||
kubectl get challenges -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Le Secret existe mais le certificat ne se génère toujours pas
|
|
||||||
|
|
||||||
1. **Vérifier les logs de cert-manager** :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager-ops -l app.kubernetes.io/name=cert-manager --context=cluster-ops --tail=100
|
|
||||||
```
|
|
||||||
|
|
||||||
2. **Vérifier que les credentials OVH sont corrects** :
|
|
||||||
- Application Key dans le ClusterIssuer
|
|
||||||
- Application Secret dans le Secret Kubernetes
|
|
||||||
- Consumer Key dans le ClusterIssuer
|
|
||||||
|
|
||||||
3. **Vérifier les permissions OVH** :
|
|
||||||
- L'application API doit avoir les permissions pour modifier les zones DNS
|
|
||||||
- Le Consumer Key doit être valide
|
|
||||||
|
|
||||||
### Erreur "Invalid credentials"
|
|
||||||
|
|
||||||
- Vérifiez que l'Application Secret dans le Secret correspond bien à celui de votre application OVH
|
|
||||||
- Vérifiez que le Consumer Key n'a pas expiré
|
|
||||||
- Régénérez un nouveau Consumer Key si nécessaire
|
|
||||||
|
|
||||||
## Sécurité
|
|
||||||
|
|
||||||
⚠️ **Important** :
|
|
||||||
- Ne commitez **jamais** le Secret avec les vraies valeurs dans Git
|
|
||||||
- Le Secret doit être créé manuellement sur le cluster
|
|
||||||
- Utilisez des outils comme Sealed Secrets ou External Secrets Operator pour sécuriser les secrets dans Git
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
|
|
||||||
- Le Secret doit être dans le namespace `certificates-ops`
|
|
||||||
- Le nom du Secret doit être exactement `ovh-credentials`
|
|
||||||
- La clé dans le Secret doit être exactement `application-secret`
|
|
||||||
|
|
||||||
@@ -1,135 +0,0 @@
|
|||||||
# Installation du Webhook OVH pour cert-manager
|
|
||||||
|
|
||||||
## Problème
|
|
||||||
|
|
||||||
Cert-manager v1.19.2 ne supporte **pas nativement** le provider OVH. L'erreur `no DNS01 provider configured` apparaît car cert-manager ne reconnaît pas la syntaxe `ovh:` directement.
|
|
||||||
|
|
||||||
## Solution
|
|
||||||
|
|
||||||
Installer le webhook `cert-manager-webhook-ovh` qui ajoute le support OVH à cert-manager.
|
|
||||||
|
|
||||||
## Étape 1 : Ajouter le dépôt Helm
|
|
||||||
|
|
||||||
```bash
|
|
||||||
helm repo add cert-manager-webhook-ovh https://cert-manager.github.io/webhook-ovh
|
|
||||||
helm repo update
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 2 : Installer le Webhook OVH
|
|
||||||
|
|
||||||
```bash
|
|
||||||
helm install cert-manager-webhook-ovh cert-manager-webhook-ovh/cert-manager-webhook-ovh \
|
|
||||||
-n cert-manager-ops \
|
|
||||||
--create-namespace \
|
|
||||||
--set groupName=acme.gkdomaine.fr
|
|
||||||
```
|
|
||||||
|
|
||||||
**Important** : Le `groupName` doit correspondre à celui configuré dans le ClusterIssuer (`acme.gkdomaine.fr`).
|
|
||||||
|
|
||||||
## Étape 3 : Vérifier l'Installation
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier que le webhook est installé
|
|
||||||
kubectl get pods -n cert-manager-ops | grep webhook-ovh
|
|
||||||
|
|
||||||
# Vérifier les logs
|
|
||||||
kubectl logs -n cert-manager-ops -l app.kubernetes.io/name=cert-manager-webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 4 : Mettre à jour le Secret OVH
|
|
||||||
|
|
||||||
Le Secret doit maintenant contenir les 3 clés (application-key, application-secret, consumer-key) :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-literal=application-key=e598bb73ded17ee6 \
|
|
||||||
--from-literal=application-secret=VOTRE_APPLICATION_SECRET \
|
|
||||||
--from-literal=consumer-key=372e273858204d972dbf7c50506d12a1 \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
Ou mettez à jour le Secret existant :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl patch secret ovh-credentials -n certificates-ops \
|
|
||||||
--type='json' \
|
|
||||||
-p='[
|
|
||||||
{"op": "add", "path": "/data/application-key", "value": "'$(echo -n 'e598bb73ded17ee6' | base64)'"},
|
|
||||||
{"op": "add", "path": "/data/consumer-key", "value": "'$(echo -n '372e273858204d972dbf7c50506d12a1' | base64)'"}
|
|
||||||
]' \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 5 : Vérifier le ClusterIssuer
|
|
||||||
|
|
||||||
Après installation du webhook, le ClusterIssuer devrait être accepté :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier le ClusterIssuer
|
|
||||||
kubectl get clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir les détails
|
|
||||||
kubectl describe clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Alternative : Utiliser Cloudflare (si disponible)
|
|
||||||
|
|
||||||
Si vous avez accès à Cloudflare pour gérer votre DNS, vous pouvez utiliser Cloudflare qui est supporté nativement par cert-manager :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- selector:
|
|
||||||
dnsZones:
|
|
||||||
- "dev.gkdomaine.fr"
|
|
||||||
dns01:
|
|
||||||
cloudflare:
|
|
||||||
email: gkpoubelle78@gmail.com
|
|
||||||
apiKeySecretRef:
|
|
||||||
name: cloudflare-api-key
|
|
||||||
key: api-key
|
|
||||||
```
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Le webhook ne démarre pas
|
|
||||||
|
|
||||||
1. Vérifiez les logs :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager-ops -l app.kubernetes.io/name=cert-manager-webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Vérifiez les événements :
|
|
||||||
```bash
|
|
||||||
kubectl get events -n cert-manager-ops --sort-by='.lastTimestamp' | grep webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
### Le ClusterIssuer est toujours rejeté
|
|
||||||
|
|
||||||
1. Vérifiez que le `groupName` correspond :
|
|
||||||
- Dans le ClusterIssuer : `groupName: acme.gkdomaine.fr`
|
|
||||||
- Dans l'installation du webhook : `--set groupName=acme.gkdomaine.fr`
|
|
||||||
|
|
||||||
2. Vérifiez les logs du webhook cert-manager :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager-ops -l app.kubernetes.io/component=webhook
|
|
||||||
```
|
|
||||||
|
|
||||||
### Le certificat ne se génère pas
|
|
||||||
|
|
||||||
1. Vérifiez que le Secret contient les 3 clés :
|
|
||||||
```bash
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops -o yaml
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Vérifiez les challenges DNS :
|
|
||||||
```bash
|
|
||||||
kubectl get challenges -n certificates-ops
|
|
||||||
kubectl describe challenge -n certificates-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
|
|
||||||
- [cert-manager-webhook-ovh GitHub](https://github.com/cert-manager/webhook-ovh)
|
|
||||||
- [Documentation cert-manager DNS-01](https://cert-manager.io/docs/configuration/acme/dns01/)
|
|
||||||
|
|
||||||
@@ -1,7 +0,0 @@
|
|||||||
apiVersion: v2
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
description: Webhook OVH pour cert-manager - Ajoute le support DNS-01 pour OVH
|
|
||||||
type: application
|
|
||||||
version: 1.0.0
|
|
||||||
appVersion: "1.0.0"
|
|
||||||
|
|
||||||
@@ -1,67 +0,0 @@
|
|||||||
# Cert-manager Webhook OVH
|
|
||||||
|
|
||||||
Ce chart Helm déploie le webhook OVH pour cert-manager, permettant d'utiliser le DNS-01 challenge avec OVH comme fournisseur DNS.
|
|
||||||
|
|
||||||
## Installation via ArgoCD
|
|
||||||
|
|
||||||
Ce chart est déployé automatiquement via l'ApplicationSet `cert-manager-webhook-ovh` dans ArgoCD.
|
|
||||||
|
|
||||||
## Image Docker
|
|
||||||
|
|
||||||
**Important** : L'image Docker officielle pour cert-manager-webhook-ovh peut ne pas exister. Vous avez deux options :
|
|
||||||
|
|
||||||
### Option 1 : Utiliser une image existante
|
|
||||||
|
|
||||||
Si une image existe sur un registry (Docker Hub, Quay.io, etc.), mettez à jour `values.yaml` :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
image:
|
|
||||||
repository: votre-registry/cert-manager-webhook-ovh
|
|
||||||
tag: "v1.0.0"
|
|
||||||
```
|
|
||||||
|
|
||||||
### Option 2 : Construire l'image vous-même
|
|
||||||
|
|
||||||
1. Clonez le repository du webhook OVH :
|
|
||||||
```bash
|
|
||||||
git clone https://github.com/cert-manager/webhook-ovh.git
|
|
||||||
cd webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Construisez l'image :
|
|
||||||
```bash
|
|
||||||
docker build -t votre-registry/cert-manager-webhook-ovh:v1.0.0 .
|
|
||||||
docker push votre-registry/cert-manager-webhook-ovh:v1.0.0
|
|
||||||
```
|
|
||||||
|
|
||||||
3. Mettez à jour `values.yaml` avec votre image.
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
|
|
||||||
Le `groupName` dans `values.yaml` doit correspondre exactement à celui configuré dans le ClusterIssuer :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
groupName: acme.gkdomaine.fr
|
|
||||||
```
|
|
||||||
|
|
||||||
## Vérification
|
|
||||||
|
|
||||||
Après déploiement :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier les pods
|
|
||||||
kubectl get pods -n cert-manager-ops | grep webhook-ovh
|
|
||||||
|
|
||||||
# Vérifier les logs
|
|
||||||
kubectl logs -n cert-manager-ops -l app=cert-manager-webhook-ovh
|
|
||||||
|
|
||||||
# Vérifier les webhooks
|
|
||||||
kubectl get mutatingwebhookconfiguration cert-manager-webhook-ovh
|
|
||||||
kubectl get validatingwebhookconfiguration cert-manager-webhook-ovh
|
|
||||||
```
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
|
|
||||||
- [cert-manager Webhooks](https://cert-manager.io/docs/concepts/webhook/)
|
|
||||||
- [DNS-01 Challenge](https://cert-manager.io/docs/configuration/acme/dns01/)
|
|
||||||
|
|
||||||
@@ -1,63 +0,0 @@
|
|||||||
apiVersion: apps/v1
|
|
||||||
kind: Deployment
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/component: webhook
|
|
||||||
spec:
|
|
||||||
replicas: {{ .Values.replicaCount }}
|
|
||||||
selector:
|
|
||||||
matchLabels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
template:
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/component: webhook
|
|
||||||
spec:
|
|
||||||
serviceAccountName: cert-manager-webhook-ovh
|
|
||||||
containers:
|
|
||||||
- name: webhook
|
|
||||||
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
|
|
||||||
imagePullPolicy: {{ .Values.image.pullPolicy }}
|
|
||||||
args:
|
|
||||||
- --v=2
|
|
||||||
- --group-name={{ .Values.groupName }}
|
|
||||||
- --secure-port=10250
|
|
||||||
ports:
|
|
||||||
- name: https
|
|
||||||
containerPort: 10250
|
|
||||||
protocol: TCP
|
|
||||||
livenessProbe:
|
|
||||||
httpGet:
|
|
||||||
path: /healthz
|
|
||||||
port: 6080
|
|
||||||
scheme: HTTP
|
|
||||||
initialDelaySeconds: 60
|
|
||||||
periodSeconds: 10
|
|
||||||
timeoutSeconds: 1
|
|
||||||
successThreshold: 1
|
|
||||||
failureThreshold: 3
|
|
||||||
readinessProbe:
|
|
||||||
httpGet:
|
|
||||||
path: /healthz
|
|
||||||
port: 6080
|
|
||||||
scheme: HTTP
|
|
||||||
initialDelaySeconds: 10
|
|
||||||
periodSeconds: 10
|
|
||||||
timeoutSeconds: 1
|
|
||||||
successThreshold: 1
|
|
||||||
failureThreshold: 3
|
|
||||||
resources:
|
|
||||||
{{- toYaml .Values.resources | nindent 10 }}
|
|
||||||
nodeSelector:
|
|
||||||
{{- toYaml .Values.nodeSelector | nindent 8 }}
|
|
||||||
tolerations:
|
|
||||||
{{- toYaml .Values.tolerations | nindent 8 }}
|
|
||||||
affinity:
|
|
||||||
{{- toYaml .Values.affinity | nindent 8 }}
|
|
||||||
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
apiVersion: admissionregistration.k8s.io/v1
|
|
||||||
kind: MutatingWebhookConfiguration
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
webhooks:
|
|
||||||
- name: webhook.cert-manager.io
|
|
||||||
admissionReviewVersions:
|
|
||||||
- v1
|
|
||||||
- v1beta1
|
|
||||||
clientConfig:
|
|
||||||
service:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
path: "/mutate"
|
|
||||||
failurePolicy: Fail
|
|
||||||
sideEffects: None
|
|
||||||
rules:
|
|
||||||
- apiGroups:
|
|
||||||
- cert-manager.io
|
|
||||||
- acme.cert-manager.io
|
|
||||||
apiVersions:
|
|
||||||
- v1
|
|
||||||
operations:
|
|
||||||
- CREATE
|
|
||||||
- UPDATE
|
|
||||||
resources:
|
|
||||||
- "*/*"
|
|
||||||
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
apiVersion: rbac.authorization.k8s.io/v1
|
|
||||||
kind: ClusterRole
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh:webhook-requester
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
rules:
|
|
||||||
- apiGroups:
|
|
||||||
- ""
|
|
||||||
resources:
|
|
||||||
- secrets
|
|
||||||
verbs:
|
|
||||||
- get
|
|
||||||
- list
|
|
||||||
---
|
|
||||||
apiVersion: rbac.authorization.k8s.io/v1
|
|
||||||
kind: ClusterRoleBinding
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh:webhook-requester
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
roleRef:
|
|
||||||
apiGroup: rbac.authorization.k8s.io
|
|
||||||
kind: ClusterRole
|
|
||||||
name: cert-manager-webhook-ovh:webhook-requester
|
|
||||||
subjects:
|
|
||||||
- apiGroup: ""
|
|
||||||
kind: ServiceAccount
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
|
|
||||||
@@ -1,19 +0,0 @@
|
|||||||
apiVersion: v1
|
|
||||||
kind: Service
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/component: webhook
|
|
||||||
spec:
|
|
||||||
type: ClusterIP
|
|
||||||
ports:
|
|
||||||
- name: https
|
|
||||||
port: 443
|
|
||||||
targetPort: 10250
|
|
||||||
protocol: TCP
|
|
||||||
selector:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
|
|
||||||
@@ -1,9 +0,0 @@
|
|||||||
apiVersion: v1
|
|
||||||
kind: ServiceAccount
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
apiVersion: admissionregistration.k8s.io/v1
|
|
||||||
kind: ValidatingWebhookConfiguration
|
|
||||||
metadata:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
labels:
|
|
||||||
app: cert-manager-webhook-ovh
|
|
||||||
app.kubernetes.io/name: cert-manager-webhook-ovh
|
|
||||||
webhooks:
|
|
||||||
- name: webhook.cert-manager.io
|
|
||||||
admissionReviewVersions:
|
|
||||||
- v1
|
|
||||||
- v1beta1
|
|
||||||
clientConfig:
|
|
||||||
service:
|
|
||||||
name: cert-manager-webhook-ovh
|
|
||||||
namespace: {{ .Values.namespace }}
|
|
||||||
path: "/validate"
|
|
||||||
failurePolicy: Fail
|
|
||||||
sideEffects: None
|
|
||||||
rules:
|
|
||||||
- apiGroups:
|
|
||||||
- cert-manager.io
|
|
||||||
- acme.cert-manager.io
|
|
||||||
apiVersions:
|
|
||||||
- v1
|
|
||||||
operations:
|
|
||||||
- CREATE
|
|
||||||
- UPDATE
|
|
||||||
resources:
|
|
||||||
- "*/*"
|
|
||||||
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
# Configuration pour cert-manager-webhook-ovh
|
|
||||||
# GroupName pour le webhook (doit correspondre à celui du ClusterIssuer)
|
|
||||||
groupName: acme.gkdomaine.fr
|
|
||||||
|
|
||||||
# Namespace où installer le webhook
|
|
||||||
namespace: cert-manager-ops
|
|
||||||
|
|
||||||
# Image du webhook
|
|
||||||
# Image officielle depuis GitHub Container Registry (maintenue par baarde)
|
|
||||||
image:
|
|
||||||
repository: ghcr.io/baarde/cert-manager-webhook-ovh
|
|
||||||
tag: "v0.6.1"
|
|
||||||
pullPolicy: IfNotPresent
|
|
||||||
|
|
||||||
# Ressources
|
|
||||||
resources:
|
|
||||||
requests:
|
|
||||||
memory: "64Mi"
|
|
||||||
cpu: "50m"
|
|
||||||
limits:
|
|
||||||
memory: "128Mi"
|
|
||||||
cpu: "200m"
|
|
||||||
|
|
||||||
# Réplicas
|
|
||||||
replicaCount: 1
|
|
||||||
|
|
||||||
# Node selector, tolerations, etc.
|
|
||||||
nodeSelector: {}
|
|
||||||
tolerations: []
|
|
||||||
affinity: {}
|
|
||||||
|
|
||||||
@@ -1,162 +0,0 @@
|
|||||||
# Certificat Wildcard avec DNS-01 Challenge
|
|
||||||
|
|
||||||
## Vue d'ensemble
|
|
||||||
|
|
||||||
Le certificat wildcard `*.dev.gkdomaine.fr` permet de couvrir tous les sous-domaines de l'environnement DEV avec un seul certificat Let's Encrypt.
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
|
|
||||||
### 1. ClusterIssuer DNS-01
|
|
||||||
|
|
||||||
Le ClusterIssuer `letsencrypt-dns01-prod` utilise le DNS-01 challenge pour valider le domaine via DNS au lieu de HTTP.
|
|
||||||
|
|
||||||
**Important** : Vous devez configurer votre fournisseur DNS dans `cluster-issuer-letsencrypt-dns01.yaml`.
|
|
||||||
|
|
||||||
### 2. Certificat Wildcard
|
|
||||||
|
|
||||||
Le certificat `wildcard-dev-tls` couvre :
|
|
||||||
- `*.dev.gkdomaine.fr` (tous les sous-domaines)
|
|
||||||
- `dev.gkdomaine.fr` (le domaine racine)
|
|
||||||
|
|
||||||
## Configuration du Fournisseur DNS
|
|
||||||
|
|
||||||
### Cloudflare (Recommandé)
|
|
||||||
|
|
||||||
1. Créez un token API dans Cloudflare :
|
|
||||||
- Allez dans "My Profile" > "API Tokens"
|
|
||||||
- Créez un token avec les permissions : Zone DNS:Edit, Zone:Read
|
|
||||||
|
|
||||||
2. Créez le Secret Kubernetes :
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic cloudflare-api-key \
|
|
||||||
--from-literal=api-key=VOTRE_TOKEN_CLOUDFLARE \
|
|
||||||
-n certificates-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
3. Décommentez la section Cloudflare dans `cluster-issuer-letsencrypt-dns01.yaml` :
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- dns01:
|
|
||||||
cloudflare:
|
|
||||||
email: gkpoubelle78@gmail.com
|
|
||||||
apiKeySecretRef:
|
|
||||||
name: cloudflare-api-key
|
|
||||||
key: api-key
|
|
||||||
```
|
|
||||||
|
|
||||||
### Route53 (AWS)
|
|
||||||
|
|
||||||
1. Créez un utilisateur IAM avec les permissions Route53
|
|
||||||
2. Configurez les credentials AWS (via IAM Role ou Secret)
|
|
||||||
3. Décommentez la section Route53 dans le ClusterIssuer
|
|
||||||
|
|
||||||
### OVH
|
|
||||||
|
|
||||||
1. Créez une application API dans OVH
|
|
||||||
2. Créez un Secret avec les credentials :
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-literal=application-secret=VOTRE_SECRET \
|
|
||||||
-n certificates-ops
|
|
||||||
```
|
|
||||||
3. Décommentez la section OVH dans le ClusterIssuer
|
|
||||||
|
|
||||||
### Autres Fournisseurs
|
|
||||||
|
|
||||||
Consultez la [documentation cert-manager](https://cert-manager.io/docs/configuration/acme/dns01/) pour votre fournisseur DNS.
|
|
||||||
|
|
||||||
## Utilisation du Certificat Wildcard
|
|
||||||
|
|
||||||
### Pour une nouvelle application
|
|
||||||
|
|
||||||
Au lieu de créer un certificat spécifique, utilisez directement le secret `wildcard-dev-tls` dans votre Ingress :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
ingress:
|
|
||||||
enabled: true
|
|
||||||
className: traefik
|
|
||||||
host: monapp.dev.gkdomaine.fr
|
|
||||||
tls:
|
|
||||||
enabled: true
|
|
||||||
secretName: wildcard-dev-tls # Utilise le certificat wildcard
|
|
||||||
```
|
|
||||||
|
|
||||||
### Migration des certificats existants
|
|
||||||
|
|
||||||
Les applications existantes peuvent être migrées pour utiliser le certificat wildcard :
|
|
||||||
|
|
||||||
1. Supprimez le certificat spécifique (ex: `homarr-dev-tls`)
|
|
||||||
2. Mettez à jour l'Ingress pour utiliser `wildcard-dev-tls`
|
|
||||||
3. Le secret sera synchronisé automatiquement vers le cluster DEV
|
|
||||||
|
|
||||||
## Avantages
|
|
||||||
|
|
||||||
- ✅ **Un seul certificat** pour tous les sous-domaines DEV
|
|
||||||
- ✅ **Certificat Let's Encrypt valide** (pas d'avertissement navigateur)
|
|
||||||
- ✅ **Renouvellement automatique** par cert-manager
|
|
||||||
- ✅ **Fonctionne pour les serveurs internes** (validation via DNS uniquement)
|
|
||||||
|
|
||||||
## Inconvénients
|
|
||||||
|
|
||||||
- ⚠️ Nécessite un fournisseur DNS compatible avec DNS-01
|
|
||||||
- ⚠️ Nécessite des credentials API pour votre DNS
|
|
||||||
- ⚠️ Si le certificat est compromis, tous les sous-domaines le sont aussi
|
|
||||||
|
|
||||||
## Vérification
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier le ClusterIssuer
|
|
||||||
kubectl get clusterissuer letsencrypt-dns01-prod
|
|
||||||
|
|
||||||
# Vérifier le certificat wildcard
|
|
||||||
kubectl get certificate wildcard-dev-tls -n certificates-ops
|
|
||||||
|
|
||||||
# Vérifier le secret TLS généré
|
|
||||||
kubectl get secret wildcard-dev-tls -n certificates-ops
|
|
||||||
|
|
||||||
# Voir les détails du certificat
|
|
||||||
kubectl describe certificate wildcard-dev-tls -n certificates-ops
|
|
||||||
|
|
||||||
# Vérifier les challenges DNS
|
|
||||||
kubectl get challenges -n certificates-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Le certificat ne se génère pas
|
|
||||||
|
|
||||||
1. Vérifiez que le ClusterIssuer est configuré correctement :
|
|
||||||
```bash
|
|
||||||
kubectl describe clusterissuer letsencrypt-dns01-prod
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Vérifiez que le Secret DNS existe :
|
|
||||||
```bash
|
|
||||||
kubectl get secret cloudflare-api-key -n certificates-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
3. Vérifiez les logs de cert-manager :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager -l app.kubernetes.io/name=cert-manager
|
|
||||||
```
|
|
||||||
|
|
||||||
### Le challenge DNS échoue
|
|
||||||
|
|
||||||
1. Vérifiez que le domaine est résolvable publiquement :
|
|
||||||
```bash
|
|
||||||
dig _acme-challenge.dev.gkdomaine.fr TXT
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Vérifiez que les permissions API sont correctes
|
|
||||||
3. Vérifiez les logs des challenges :
|
|
||||||
```bash
|
|
||||||
kubectl describe challenge -n certificates-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Notes Importantes
|
|
||||||
|
|
||||||
- Le domaine `dev.gkdomaine.fr` doit être résolvable publiquement via DNS
|
|
||||||
- Les serveurs peuvent rester internes (pas besoin d'accès HTTP depuis Internet)
|
|
||||||
- Le certificat wildcard couvre tous les sous-domaines de `dev.gkdomaine.fr`
|
|
||||||
- Le secret `wildcard-dev-tls` sera synchronisé automatiquement vers le cluster DEV
|
|
||||||
|
|
||||||
@@ -1,165 +0,0 @@
|
|||||||
# Configuration DNS-01 Challenge pour Certificat Wildcard
|
|
||||||
|
|
||||||
## Étapes de Configuration
|
|
||||||
|
|
||||||
### 1. Choisir votre Fournisseur DNS
|
|
||||||
|
|
||||||
Le ClusterIssuer `letsencrypt-dns01-prod` doit être configuré selon votre fournisseur DNS.
|
|
||||||
|
|
||||||
### 2. Configuration Cloudflare (Recommandé)
|
|
||||||
|
|
||||||
#### Étape 1 : Créer un Token API Cloudflare
|
|
||||||
|
|
||||||
1. Connectez-vous à [Cloudflare](https://dash.cloudflare.com/)
|
|
||||||
2. Allez dans "My Profile" > "API Tokens"
|
|
||||||
3. Cliquez sur "Create Token"
|
|
||||||
4. Utilisez le template "Edit zone DNS" ou créez un token personnalisé avec :
|
|
||||||
- Permissions : `Zone` > `DNS` > `Edit`
|
|
||||||
- Zone Resources : `Include` > `Specific zone` > `gkdomaine.fr`
|
|
||||||
|
|
||||||
#### Étape 2 : Créer le Secret Kubernetes
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic cloudflare-api-key \
|
|
||||||
--from-literal=api-key=VOTRE_TOKEN_CLOUDFLARE \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Étape 3 : Activer la Configuration dans le ClusterIssuer
|
|
||||||
|
|
||||||
Éditez `helm/certificates/ops/templates/cluster-issuer-letsencrypt-dns01.yaml` et décommentez la section Cloudflare :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- dns01:
|
|
||||||
cloudflare:
|
|
||||||
email: gkpoubelle78@gmail.com
|
|
||||||
apiKeySecretRef:
|
|
||||||
name: cloudflare-api-key
|
|
||||||
key: api-key
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3. Configuration Route53 (AWS)
|
|
||||||
|
|
||||||
#### Étape 1 : Créer un Utilisateur IAM
|
|
||||||
|
|
||||||
Créez un utilisateur IAM avec la politique `AmazonRoute53FullAccess` ou une politique personnalisée.
|
|
||||||
|
|
||||||
#### Étape 2 : Créer le Secret Kubernetes
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic route53-credentials \
|
|
||||||
--from-literal=access-key-id=VOTRE_ACCESS_KEY \
|
|
||||||
--from-literal=secret-access-key=VOTRE_SECRET_KEY \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Étape 3 : Activer la Configuration dans le ClusterIssuer
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- dns01:
|
|
||||||
route53:
|
|
||||||
region: eu-west-1
|
|
||||||
accessKeyIDSecretRef:
|
|
||||||
name: route53-credentials
|
|
||||||
key: access-key-id
|
|
||||||
secretAccessKeySecretRef:
|
|
||||||
name: route53-credentials
|
|
||||||
key: secret-access-key
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Configuration OVH
|
|
||||||
|
|
||||||
#### Étape 1 : Créer une Application API OVH
|
|
||||||
|
|
||||||
1. Connectez-vous à [OVH API](https://eu.api.ovh.com/)
|
|
||||||
2. Créez une application API
|
|
||||||
3. Notez l'Application Key et l'Application Secret
|
|
||||||
4. Générez un Consumer Key
|
|
||||||
|
|
||||||
#### Étape 2 : Créer le Secret Kubernetes
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-literal=application-secret=VOTRE_APPLICATION_SECRET \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Étape 3 : Activer la Configuration dans le ClusterIssuer
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- dns01:
|
|
||||||
ovh:
|
|
||||||
applicationKey: "VOTRE_APPLICATION_KEY"
|
|
||||||
applicationSecretRef:
|
|
||||||
name: ovh-credentials
|
|
||||||
key: application-secret
|
|
||||||
consumerKey: "VOTRE_CONSUMER_KEY"
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Autres Fournisseurs DNS
|
|
||||||
|
|
||||||
Consultez la [documentation cert-manager](https://cert-manager.io/docs/configuration/acme/dns01/) pour :
|
|
||||||
- Google Cloud DNS
|
|
||||||
- Azure DNS
|
|
||||||
- DigitalOcean
|
|
||||||
- Namecheap
|
|
||||||
- Et d'autres...
|
|
||||||
|
|
||||||
## Vérification
|
|
||||||
|
|
||||||
Après avoir configuré le ClusterIssuer :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier le ClusterIssuer
|
|
||||||
kubectl get clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier la configuration
|
|
||||||
kubectl describe clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier que le certificat wildcard est en cours de génération
|
|
||||||
kubectl get certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir les détails du certificat
|
|
||||||
kubectl describe certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier les challenges DNS
|
|
||||||
kubectl get challenges -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Le certificat ne se génère pas
|
|
||||||
|
|
||||||
1. Vérifiez que le ClusterIssuer est correctement configuré
|
|
||||||
2. Vérifiez que le Secret DNS existe et contient les bonnes valeurs
|
|
||||||
3. Vérifiez les logs de cert-manager :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager -l app.kubernetes.io/name=cert-manager --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
### Le challenge DNS échoue
|
|
||||||
|
|
||||||
1. Vérifiez que le domaine est résolvable publiquement :
|
|
||||||
```bash
|
|
||||||
dig _acme-challenge.dev.gkdomaine.fr TXT
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Vérifiez que les permissions API sont correctes
|
|
||||||
3. Vérifiez les détails du challenge :
|
|
||||||
```bash
|
|
||||||
kubectl describe challenge -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Notes Importantes
|
|
||||||
|
|
||||||
- Le domaine `dev.gkdomaine.fr` doit être résolvable publiquement via DNS
|
|
||||||
- Les serveurs peuvent rester internes (pas besoin d'accès HTTP depuis Internet)
|
|
||||||
- Le certificat wildcard couvre tous les sous-domaines `*.dev.gkdomaine.fr`
|
|
||||||
- Le secret `wildcard-dev-tls` sera synchronisé automatiquement vers le cluster DEV
|
|
||||||
|
|
||||||
@@ -1,228 +0,0 @@
|
|||||||
# Configuration DNS-01 avec OVH
|
|
||||||
|
|
||||||
## Vue d'ensemble
|
|
||||||
|
|
||||||
Ce guide explique comment configurer cert-manager pour générer des certificats Let's Encrypt wildcard en utilisant le DNS-01 challenge avec OVH comme fournisseur DNS.
|
|
||||||
|
|
||||||
## Prérequis
|
|
||||||
|
|
||||||
- Un compte OVH avec accès à la gestion DNS du domaine `gkdomaine.fr`
|
|
||||||
- Le domaine `dev.gkdomaine.fr` doit être résolvable publiquement via DNS OVH
|
|
||||||
|
|
||||||
## Étape 1 : Créer une Application API OVH
|
|
||||||
|
|
||||||
### 1.1 Accéder à l'API OVH
|
|
||||||
|
|
||||||
1. Connectez-vous à votre compte OVH
|
|
||||||
2. Allez sur [https://eu.api.ovh.com/createApp/](https://eu.api.ovh.com/createApp/) (pour l'Europe)
|
|
||||||
3. Connectez-vous avec votre compte OVH
|
|
||||||
|
|
||||||
### 1.2 Créer l'Application
|
|
||||||
|
|
||||||
1. Remplissez le formulaire :
|
|
||||||
- **Application name** : `cert-manager-gkdomaine` (ou un nom de votre choix)
|
|
||||||
- **Application description** : `Cert-manager pour certificats Let's Encrypt`
|
|
||||||
- **Application validity** : `Unlimited` (ou la durée souhaitée)
|
|
||||||
- **Callback URL** : Laissez vide
|
|
||||||
|
|
||||||
2. Cliquez sur **Create application**
|
|
||||||
|
|
||||||
3. **Notez les identifiants** :
|
|
||||||
- **Application Key** (AK) : `xxxxxxxxxxxxxxxx`
|
|
||||||
- **Application Secret** (AS) : `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`
|
|
||||||
|
|
||||||
⚠️ **Important** : Notez ces valeurs, vous ne pourrez plus les voir après !
|
|
||||||
|
|
||||||
## Étape 2 : Générer les Permissions et Consumer Key
|
|
||||||
|
|
||||||
### 2.1 Générer les Permissions
|
|
||||||
|
|
||||||
Vous devez générer les permissions pour que l'application puisse modifier les enregistrements DNS.
|
|
||||||
|
|
||||||
Utilisez l'API OVH ou le script suivant :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Remplacer par vos valeurs
|
|
||||||
APPLICATION_KEY="VOTRE_APPLICATION_KEY"
|
|
||||||
APPLICATION_SECRET="VOTRE_APPLICATION_SECRET"
|
|
||||||
|
|
||||||
# Générer les permissions pour DNS
|
|
||||||
curl -X POST "https://eu.api.ovh.com/v1/auth/credential" \
|
|
||||||
-H "X-Ovh-Application: $APPLICATION_KEY" \
|
|
||||||
-H "Content-Type: application/json" \
|
|
||||||
-d '{
|
|
||||||
"accessRules": [
|
|
||||||
{
|
|
||||||
"method": "GET",
|
|
||||||
"path": "/domain/zone/*"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"method": "POST",
|
|
||||||
"path": "/domain/zone/*"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"method": "PUT",
|
|
||||||
"path": "/domain/zone/*"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"method": "DELETE",
|
|
||||||
"path": "/domain/zone/*"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"redirection": "https://www.ovh.com"
|
|
||||||
}'
|
|
||||||
```
|
|
||||||
|
|
||||||
Cela retournera une URL de validation. Ouvrez cette URL dans votre navigateur et validez les permissions.
|
|
||||||
|
|
||||||
### 2.2 Récupérer le Consumer Key
|
|
||||||
|
|
||||||
Après validation, vous recevrez un **Consumer Key** (CK). Notez-le également.
|
|
||||||
|
|
||||||
## Étape 3 : Créer le Secret Kubernetes
|
|
||||||
|
|
||||||
Créez un Secret Kubernetes contenant l'Application Secret :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create secret generic ovh-credentials \
|
|
||||||
--from-literal=application-secret=VOTRE_APPLICATION_SECRET \
|
|
||||||
-n certificates-ops \
|
|
||||||
--context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
**Important** : Remplacez `VOTRE_APPLICATION_SECRET` par la valeur réelle de votre Application Secret.
|
|
||||||
|
|
||||||
## Étape 4 : Configurer le ClusterIssuer
|
|
||||||
|
|
||||||
### 4.1 Mettre à jour le ClusterIssuer
|
|
||||||
|
|
||||||
Éditez `helm/certificates/ops/templates/cluster-issuer-letsencrypt-dns01.yaml` et remplacez :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
solvers:
|
|
||||||
- dns01:
|
|
||||||
ovh:
|
|
||||||
endpoint: ovh-eu # ovh-eu pour l'Europe
|
|
||||||
applicationKey: "VOTRE_APPLICATION_KEY" # Remplacez par votre Application Key
|
|
||||||
applicationSecretRef:
|
|
||||||
name: ovh-credentials
|
|
||||||
key: application-secret
|
|
||||||
consumerKey: "VOTRE_CONSUMER_KEY" # Remplacez par votre Consumer Key
|
|
||||||
```
|
|
||||||
|
|
||||||
**Remplacez** :
|
|
||||||
- `VOTRE_APPLICATION_KEY` par votre Application Key
|
|
||||||
- `VOTRE_CONSUMER_KEY` par votre Consumer Key
|
|
||||||
|
|
||||||
### 4.2 Endpoints OVH disponibles
|
|
||||||
|
|
||||||
- `ovh-eu` : Pour l'Europe (recommandé pour la France)
|
|
||||||
- `ovh-us` : Pour les États-Unis
|
|
||||||
- `ovh-ca` : Pour le Canada
|
|
||||||
|
|
||||||
## Étape 5 : Vérifier la Configuration
|
|
||||||
|
|
||||||
### 5.1 Vérifier le Secret
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier le contenu (la valeur sera encodée en base64)
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops -o yaml
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.2 Vérifier le ClusterIssuer
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl get clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir la configuration complète
|
|
||||||
kubectl describe clusterissuer letsencrypt-dns01-prod --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.3 Vérifier le Certificat Wildcard
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Vérifier que le certificat est créé
|
|
||||||
kubectl get certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Voir les détails
|
|
||||||
kubectl describe certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
|
|
||||||
# Vérifier les challenges DNS
|
|
||||||
kubectl get challenges -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
## Étape 6 : Tester la Génération du Certificat
|
|
||||||
|
|
||||||
Une fois déployé via ArgoCD, cert-manager tentera automatiquement de générer le certificat wildcard.
|
|
||||||
|
|
||||||
Vous pouvez forcer la régénération en supprimant le certificat :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl delete certificate wildcard-dev-tls -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
Cert-manager le recréera automatiquement.
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Le certificat ne se génère pas
|
|
||||||
|
|
||||||
1. **Vérifier les logs de cert-manager** :
|
|
||||||
```bash
|
|
||||||
kubectl logs -n cert-manager -l app.kubernetes.io/name=cert-manager --context=cluster-ops --tail=100
|
|
||||||
```
|
|
||||||
|
|
||||||
2. **Vérifier que le Secret existe** :
|
|
||||||
```bash
|
|
||||||
kubectl get secret ovh-credentials -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
3. **Vérifier les credentials OVH** :
|
|
||||||
- Vérifiez que l'Application Key est correcte
|
|
||||||
- Vérifiez que l'Application Secret dans le Secret Kubernetes est correcte
|
|
||||||
- Vérifiez que le Consumer Key est correct et valide
|
|
||||||
|
|
||||||
### Le challenge DNS échoue
|
|
||||||
|
|
||||||
1. **Vérifier que le domaine est résolvable** :
|
|
||||||
```bash
|
|
||||||
dig _acme-challenge.dev.gkdomaine.fr TXT
|
|
||||||
```
|
|
||||||
|
|
||||||
2. **Vérifier les permissions OVH** :
|
|
||||||
- Assurez-vous que l'application API a les permissions pour modifier les zones DNS
|
|
||||||
- Vérifiez que le Consumer Key est toujours valide
|
|
||||||
|
|
||||||
3. **Vérifier les détails du challenge** :
|
|
||||||
```bash
|
|
||||||
kubectl describe challenge -n certificates-ops --context=cluster-ops
|
|
||||||
```
|
|
||||||
|
|
||||||
### Erreur "Invalid credentials"
|
|
||||||
|
|
||||||
- Vérifiez que l'Application Key, Application Secret et Consumer Key sont corrects
|
|
||||||
- Vérifiez que le Consumer Key n'a pas expiré
|
|
||||||
- Régénérez un nouveau Consumer Key si nécessaire
|
|
||||||
|
|
||||||
## Sécurité
|
|
||||||
|
|
||||||
⚠️ **Important** :
|
|
||||||
- Ne commitez **jamais** les credentials OVH dans Git
|
|
||||||
- Utilisez des secrets Kubernetes pour stocker l'Application Secret
|
|
||||||
- L'Application Key et Consumer Key sont dans le ClusterIssuer (déployé via Git) - considérez utiliser Sealed Secrets ou External Secrets Operator pour les sécuriser
|
|
||||||
|
|
||||||
## Documentation OVH
|
|
||||||
|
|
||||||
- [Documentation API OVH](https://docs.ovh.com/fr/api/)
|
|
||||||
- [Génération des credentials OVH](https://docs.ovh.com/fr/api/first-steps-with-ovh-api/)
|
|
||||||
- [Gestion DNS OVH via API](https://docs.ovh.com/fr/domains/editer-ma-zone-dns/)
|
|
||||||
|
|
||||||
## Notes Importantes
|
|
||||||
|
|
||||||
- Le domaine `dev.gkdomaine.fr` doit être géré par OVH DNS
|
|
||||||
- Les serveurs peuvent rester internes (pas besoin d'accès HTTP depuis Internet)
|
|
||||||
- Le certificat wildcard couvre tous les sous-domaines `*.dev.gkdomaine.fr`
|
|
||||||
- Le secret `wildcard-dev-tls` sera synchronisé automatiquement vers le cluster DEV
|
|
||||||
|
|
||||||
@@ -1,52 +0,0 @@
|
|||||||
apiVersion: cert-manager.io/v1
|
|
||||||
kind: ClusterIssuer
|
|
||||||
metadata:
|
|
||||||
name: letsencrypt-dns01-prod
|
|
||||||
spec:
|
|
||||||
acme:
|
|
||||||
server: https://acme-v02.api.letsencrypt.org/directory
|
|
||||||
email: gkpoubelle78@gmail.com
|
|
||||||
privateKeySecretRef:
|
|
||||||
name: letsencrypt-dns01-prod-key
|
|
||||||
solvers:
|
|
||||||
# Configuration DNS-01 pour OVH via webhook
|
|
||||||
# IMPORTANT: Vous devez installer cert-manager-webhook-ovh avant d'utiliser cette configuration
|
|
||||||
# Installation: helm repo add cert-manager-webhook-ovh https://cert-manager.github.io/webhook-ovh
|
|
||||||
# helm install cert-manager-webhook-ovh cert-manager-webhook-ovh/cert-manager-webhook-ovh -n cert-manager-ops
|
|
||||||
- selector:
|
|
||||||
dnsZones:
|
|
||||||
- "dev.gkdomaine.fr"
|
|
||||||
dns01:
|
|
||||||
webhook:
|
|
||||||
groupName: acme.gkdomaine.fr
|
|
||||||
solverName: ovh
|
|
||||||
config:
|
|
||||||
endpoint: ovh-eu
|
|
||||||
applicationKeyRef:
|
|
||||||
name: ovh-credentials
|
|
||||||
key: application-key
|
|
||||||
applicationSecretRef:
|
|
||||||
name: ovh-credentials
|
|
||||||
key: application-secret
|
|
||||||
consumerKeyRef:
|
|
||||||
name: ovh-credentials
|
|
||||||
key: consumer-key
|
|
||||||
|
|
||||||
# Option 4 : Generic (webhook personnalisé)
|
|
||||||
# - dns01:
|
|
||||||
# webhook:
|
|
||||||
# groupName: acme.example.com
|
|
||||||
# solverName: my-dns-solver
|
|
||||||
# config:
|
|
||||||
# # Configuration spécifique au webhook
|
|
||||||
|
|
||||||
# Option 5 : RFC2136 (DNS dynamique standard)
|
|
||||||
# - dns01:
|
|
||||||
# rfc2136:
|
|
||||||
# nameserver: 8.8.8.8
|
|
||||||
# tsigSecretSecretRef:
|
|
||||||
# name: rfc2136-credentials
|
|
||||||
# key: tsig-secret
|
|
||||||
# tsigKeyName: "keyname"
|
|
||||||
# tsigAlgorithm: HMACSHA256
|
|
||||||
|
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
apiVersion: cert-manager.io/v1
|
||||||
|
kind: Certificate
|
||||||
|
metadata:
|
||||||
|
name: longhorn-dev-tls
|
||||||
|
namespace: certificates-ops
|
||||||
|
spec:
|
||||||
|
secretName: longhorn-dev-tls
|
||||||
|
issuerRef:
|
||||||
|
name: letsencrypt-prod
|
||||||
|
kind: ClusterIssuer
|
||||||
|
dnsNames:
|
||||||
|
- longhorn.dev.gkdomaine.fr
|
||||||
|
|
||||||
@@ -1,28 +0,0 @@
|
|||||||
# Secret pour les credentials OVH
|
|
||||||
# IMPORTANT: Remplacez VOTRE_APPLICATION_SECRET par votre vrai Application Secret OVH
|
|
||||||
# Ce fichier est un template - vous devez créer le Secret manuellement avec vos vraies valeurs
|
|
||||||
#
|
|
||||||
# Pour créer le Secret manuellement :
|
|
||||||
# kubectl create secret generic ovh-credentials \
|
|
||||||
# --from-literal=application-secret=VOTRE_APPLICATION_SECRET \
|
|
||||||
# -n certificates-ops \
|
|
||||||
# --context=cluster-ops
|
|
||||||
#
|
|
||||||
# OU utilisez ce template en remplaçant la valeur base64 ci-dessous :
|
|
||||||
# echo -n 'VOTRE_APPLICATION_SECRET' | base64
|
|
||||||
|
|
||||||
apiVersion: v1
|
|
||||||
kind: Secret
|
|
||||||
metadata:
|
|
||||||
name: ovh-credentials
|
|
||||||
namespace: certificates-ops
|
|
||||||
type: Opaque
|
|
||||||
data:
|
|
||||||
# Encodez vos credentials en base64 :
|
|
||||||
# echo -n 'VOTRE_APPLICATION_KEY' | base64
|
|
||||||
# echo -n 'VOTRE_APPLICATION_SECRET' | base64
|
|
||||||
# echo -n 'VOTRE_CONSUMER_KEY' | base64
|
|
||||||
application-key: ZTVhOGJiNzNkZWQxN2VlNg== # e598bb73ded17ee6 en base64
|
|
||||||
application-secret: NDYyMGM0ODI0OTlmOTcxZjRkMTgxNGY4MTU3ZjgyY2M= # VOTRE_APPLICATION_SECRET en base64
|
|
||||||
consumer-key: MzcyZTI3Mzg1ODIwNGQ5NzJkYmY3YzUwNTA2ZDEyYTE= # 372e273858204d972dbf7c50506d12a1 en base64
|
|
||||||
|
|
||||||
@@ -1,16 +0,0 @@
|
|||||||
apiVersion: cert-manager.io/v1
|
|
||||||
kind: Certificate
|
|
||||||
metadata:
|
|
||||||
name: wildcard-dev-tls
|
|
||||||
namespace: certificates-ops
|
|
||||||
spec:
|
|
||||||
secretName: wildcard-dev-tls
|
|
||||||
issuerRef:
|
|
||||||
name: letsencrypt-dns01-prod
|
|
||||||
kind: ClusterIssuer
|
|
||||||
dnsNames:
|
|
||||||
- "*.dev.gkdomaine.fr"
|
|
||||||
- dev.gkdomaine.fr # Inclut aussi le domaine racine
|
|
||||||
# Note: Certificat wildcard pour tous les sous-domaines dev
|
|
||||||
# Nécessite DNS-01 challenge (le domaine doit être résolvable publiquement)
|
|
||||||
|
|
||||||
@@ -33,11 +33,11 @@ longhorn:
|
|||||||
className: traefik
|
className: traefik
|
||||||
host: longhorn.dev.gkdomaine.fr
|
host: longhorn.dev.gkdomaine.fr
|
||||||
pathType: Prefix
|
pathType: Prefix
|
||||||
# Configuration TLS avec le certificat wildcard synchronisé depuis OPS
|
# Configuration TLS avec le secret synchronisé depuis OPS
|
||||||
# Le secret wildcard-dev-tls couvre tous les sous-domaines *.dev.gkdomaine.fr
|
# Le secret est généré par cert-manager dans OPS et synchronisé vers ce cluster
|
||||||
tls:
|
tls:
|
||||||
enabled: true
|
enabled: true
|
||||||
secretName: wildcard-dev-tls
|
secretName: longhorn-dev-tls
|
||||||
|
|
||||||
# Persistence
|
# Persistence
|
||||||
persistence:
|
persistence:
|
||||||
|
|||||||
Reference in New Issue
Block a user