kubernetes/argocd
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

delete wildcard

Browse Source
This commit is contained in:
Melvin
2026-01-21 01:20:09 +01:00
parent 6d2b29bc33
commit d6fd390618
21 changed files with 16 additions and 1351 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
helm/cert-manager-webhook-ovh/ops/Chart.yaml
View File

@@ -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"

67
helm/cert-manager-webhook-ovh/ops/README.md
View File

@@ -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/)

63
helm/cert-manager-webhook-ovh/ops/templates/deployment.yaml
View File

@@ -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 }}

31
helm/cert-manager-webhook-ovh/ops/templates/mutating-webhook.yaml
View File

@@ -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:
- "*/*"

31
helm/cert-manager-webhook-ovh/ops/templates/rbac.yaml
View File

@@ -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 }}

19
helm/cert-manager-webhook-ovh/ops/templates/service.yaml
View File

@@ -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

9
helm/cert-manager-webhook-ovh/ops/templates/serviceaccount.yaml
View File

@@ -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

31
helm/cert-manager-webhook-ovh/ops/templates/validating-webhook.yaml
View File

@@ -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:
- "*/*"

31
helm/cert-manager-webhook-ovh/ops/values.yaml
View File

@@ -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: {}

162
helm/certificates/ops/docs/CERTIFICAT-WILDCARD.md
View File

@@ -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

165
helm/certificates/ops/docs/CONFIGURATION-DNS01.md
View File

@@ -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

228
helm/certificates/ops/docs/CONFIGURATION-OVH.md
View File

@@ -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

52
helm/certificates/ops/templates/cluster-issuer-letsencrypt-dns01.yaml
View File

@@ -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

13
helm/certificates/ops/templates/longhorn/certificate-dev.yaml Normal file
View File

@@ -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

28
helm/certificates/ops/templates/secret-ovh-credentials.yaml
View File

@@ -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

16
helm/certificates/ops/templates/wildcard/certificate-wildcard-dev.yaml
View File

@@ -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)

6
helm/longhorn/dev/values.yaml
View File

@@ -33,11 +33,11 @@ longhorn:
className: traefik
host: longhorn.dev.gkdomaine.fr
pathType: Prefix
# Configuration TLS avec le certificat wildcard synchronisé depuis OPS
# Le secret wildcard-dev-tls couvre tous les sous-domaines *.dev.gkdomaine.fr
# Configuration TLS avec le secret synchronisé depuis OPS
# Le secret est généré par cert-manager dans OPS et synchronisé vers ce cluster
tls:
enabled: true
secretName: wildcard-dev-tls
secretName: longhorn-dev-tls
# Persistence
persistence: