add wildcard
This commit is contained in:
162
helm/certificates/ops/docs/CERTIFICAT-WILDCARD.md
Normal file
162
helm/certificates/ops/docs/CERTIFICAT-WILDCARD.md
Normal file
@@ -0,0 +1,162 @@
|
||||
# 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
|
||||
|
||||
Reference in New Issue
Block a user