Redirection de domaine (HTTP→HTTPS ou ancien domaine)

Pour rediriger le trafic HTTP vers HTTPS ou d'un ancien domaine vers un nouveau, utilisez une configuration d'Ingress avec des annotations spécifiques. L'exemple ci-dessous redirige toutes les requêtes de l'hôte ancien.exemple.com vers le même chemin sur HTTPS.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: redirect-vers-https
  annotations:
    nginx.ingress.kubernetes.io/permanent-redirect: https://$host$request_uri
spec:
  rules:
  - host: ancien.exemple.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-placeholder
            port:
              number: 80

Dans cette configuration, l'annotation nginx.ingress.kubernetes.io/permanent-redirect génère une réponse 301 (redirection permanente). Les variables $host et $request_uri conservent le domaine et le chemin d'origine. Le service service-placeholder est utilisé comme cible fictive, car la requête ne sera jamais réellement servie par ce service.

Réécriture de chemin pour séparer front-end et back-end

Lorsqu'une application utilise une architecture séparée, il est courant de réécrire les chemins d'URL pour les routes du back-end. L'exemple suivant réécrit les chemins commençant par /api pour les rediriger vers un service back-end.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-reecriture
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: application.exemple.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: service-api
            port:
              number: 8080

Ici, l'annotation rewrite-target utilise une expression régulière pour capturer le chemin après /api. Le groupe capturé (.*) est référé par $2, et le chemin d'accès est réécrit à la racine. Ainsi, une requête vers /api/utilisateurs sera transmise à /utilisateurs sur le service service-api.

Configuration mixte : redirection et réécriture

Parfois, il faut combiner redirection de domaine et réécriture de chemin dans une seule règle Ingress. Cela peut être réalisé avec un extrait de configuration Nginx personnalisé.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: configuration-mixte
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($host = 'domaine-obsolete.com') {
        return 301 https://nouveau.exemple.com$request_uri;
      }
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
  - host: nouveau.exemple.com
    http:
      paths:
      - path: /assets/(.*)
        pathType: Prefix
        backend:
          service:
            name: service-frontend
            port:
              number: 80

Cette configuration effectue deux actions : elle redirige le trafic de domaine-obsolete.com vers nouveau.exemple.com, et réécrit les chemins /assets/... en supprimant le préfixe /assets pour le service service-frontend. L'annotation configuration-snippet permet d'injecter des directives Nginx arbitraires pour des logiques avancées.

Pour appliquer ces configurations, utilisez les commandes suivantes :

# Appliquer les règles
kubectl apply -f redirect-vers-https.yaml
kubectl apply -f demo-reecriture.yaml
# Vérifier les annotations sur l'Ingress
kubectl describe ingress configuration-mixte | grep Annotations
# Tester la redirection (devrait retourner un code 301)
curl -I http://ancien.exemple.com

Remarques importantes : les règles de réécriture doivent correspondre aux routes définies dans les services back-end. Pour les environnements de production, l'utilisation d'un gestionnaire de certificats comme cert-manager est recommandée pour automatiser la gestion HTTPS. Notez que la syntaxe des annotations peut varier selon le contrôleur d'Ingress (par exemple, Traefik utilise des préfixes différents).

Configuration SSL/TLS pour le chiffrement HTTPS

Pour sécuriser les communications avec HTTPS, vous devez d'abord créer un Secret Kubernetes contenant le certificat et la clé privée, puis lier ce Secret à une règle Ingress.

apiVersion: v1
kind: Secret
metadata:
  name: certificat-tls
  namespace: default
type: kubernetes.io/tls
data:
  tls.crt: <certificat-encod>
  tls.key: <cl>
</cl></certificat-encod>

Pour encoder les fichiers, utilisez la commande cat certificat.pem | base64 -w0. Ensuite, créez une Ingress qui active la redirection automatique HTTP vers HTTPS :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-securise
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - secure.exemple.com
    secretName: certificat-tls
  rules:
  - host: secure.exemple.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: service-web
            port:
              number: 80

L'annotation ssl-redirect force les requêtes HTTP non chiffrées à être redirigées vers HTTPS. Le bloc tls associe le certificat au domaine spécifié.

Authentification de base (Basic Auth)

Pour protéger un service avec une authentification HTTP basique, stockez les identifiants dans un Secret et configurez une annotation d'Ingress correspondante.

apiVersion: v1
kind: Secret
metadata:
  name: authentification-base
  namespace: default
type: Opaque
data:
  auth: $(echo -n 'utilisateur:motdepasse' | openssl base64 -A)

Vous pouvez générer le fichier .htpasswd avec la commande htpasswd -c authentification foo puis encoder en base64. Appliquez ensuite l'Ingress avec les annotations d'authentification :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-authentifie
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: authentification-base
    nginx.ingress.kubernetes.io/auth-realm: "Authentification requise"
spec:
  rules:
  - host: prive.exemple.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: service-prive
            port:
              number: 8080

Ces annotations définissent le type d'authentification, lient le Secret contenent les identifiants, et spécifient le message affiché par le navigateur. Pour tester l'accès, appliquez les configurations :

# Appliquer les ressources
kubectl apply -f certificat-tls.yaml
kubectl apply -f ingress-securise.yaml
# Vérifier l'état du certificat
kubectl describe ingress ingress-securise | grep -A3 'TLS'
# Tester l'authentification (devrait retourner 401 Non autorisé)
curl -v http://prive.exemple.com

Il est conseillé d'utiliser Let's Encrypt avec cert-manager en production pour automatiser les certificats. L'authentification de base doit toujours être combinée avec HTTPS pour éviter l'interception des identifiants. Gardez à l'esprit que les annotations d'authentification peuvent différer selon le contrôleur d'Ingress utilisé.