delete wildcard
This commit is contained in:
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user