Ovh Cloud + Kubernetes + SSL

Bonjour à tous,

Petit article qui je pense peut en aider certain. Il s’agît de la mise en place des certificats SSL à l’aide de Let’s Encrypt avec Cert Manager de Kubernetes, le tout chez Ovh Cloud et plus précisément Public Cloud !

Allez c’est parti !!

Pré-requis

Tout d’abord, il vous faut un cluster Kubernetes opérationnel hébergé sur le Public Cloud d’Ovh et Cert Manager d’installé. Je ne vais pas traiter de cela dans cet article car beaucoup de tutos se trouvent assez facile sur le net. Néanmoins, je vous conseille un bouquin qui m’a grandement aidé, c’est le livre Kubernetes des Editions ENI.

Mise en place d’un Issuer

Tout d’abord nous allons mettre en place notre Issuer, c’est lui qui se chargera de « déclarer » nos certificats auprès de Let’s Encrypt.

Pour cela, nous allons créer un ficher de configuration que l’on nommera Issuer.yaml, avec le contenu suivant (en remplaçant le champ email par le votre bien entendu) :

---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-issuer
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: key-cert
    solvers:
      - selector: {}
        http01:
          ingress:
            class: nginx

On applique cette configuration dans l’espace de nom de notre choix

kubectl -n VOTRE_NAMESPACE apply -f Issuer.yaml

Simple non ? Alors continuons.

Mise en place d’Ingress

Maintenant passons à la mise en place de la règle Ingress, c’est cette Ingress qui va appeler le Issuer pour faire la demande de certificat.

Pour cela deux méthodes existent, la première en DNS01 et HTTP01. Je ne rentrerai pas dans le détails et vous renverrai encore vers le très bon livre sur Kubernetes pour les plus curieux.

Dans notre cas nous allons, utiliser la méthode HTTP01, car la méthode DNS01 n’est pas encore disponible pour Ovh. (Tout du moins à la date où j’écris ce petit article)

Pour ce faire, voici un exemple de fichier ingress.yaml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: FRONT_APPLI
  labels:
    app.kubernetes.io/name: FRONT_APPLI
    app.kubernetes.io/instance: APPLI
  annotations:
    app.kubernetes.io/name: FRONT_APPPLI
    app.kubernetes.io/instance: APPLI
    app.kubernetes.io/app: APPLI
    kubernetes.io/ingress.class: nginx
    cert-manager.io/issuer: letsencrypt-issuer
    acme.cert-manager.io/http01-edit-in-place: "true"
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  tls:
    - hosts:
        - URL_DE_VOTRE_APPLI
      secretName: key-cert-tls-front
  rules:
    - host: URL_DE_VOTRE_APPLI
      http:
        paths:
          - path: /
            backend:
              serviceName: FRONT_APPLI
              servicePort: http

Les points importants dans ce fichier de configuration sont :

  • la déclaration de l’Issuer précédemment créé : cert-manager.io/issuer: letsencrypt-issuer
  • et la méthode http01 utilisée : acme.cert-manager.io/http01-edit-in-place: « true »

Bien sûr, vous remplacerez les valeurs en MAJUSCULE par les votres.

Une fois, le fichier adapté à votre configuration, deux méthodes pour le mettre en place :

  • avec kubectl -n VOTRE_NAMESPACE apply
  • ou à l’aide d’un chart Helm

Personnellement, je suis passé par la seconde méthode mais cela serait trop long à expliquer ici.

!! ATTENTION !! Petite point important à ne pas oublier. Pour que cela fonctionne, il faut que votre Issuer et votre Ingress soient dans le même namespace !!

Si vous avez plusieurs namespace et que vous voulez utiliser un seul Issuer, il vous faudra passer pas un Cluster Issuer.

Conclusion

Nous voici avec une nouveau certificat tout beau tout propre !!

Et surtout, et c’est là tout l’intérêt, c’est qu’avec la combinaison que l’on vient de voir, plus de soucis de renouvellement !! Car cerise sur le gâteau, Cert Manager s’en occupe tout seul !!

https://www.ssllabs.com/ssltest/analyze.html?d=mon-apiculture.fr

Et voilà, je vous laisse sur ce très beau résultat et à bientôt !

Laisser un commentaire