Étape 1 - Installer le client Helm

Ignorez cette section si vous avez installé Helm.  Le moyen le plus simple d'installer cert-manager consiste à utiliser Helm, un outil de modélisation et de déploiement de ressources Kubernetes.  Tout d’abord, assurez-vous que le client Helm est installé en suivant les instructions d’installation de Helm.  

Par exemple, sur macOS:  

$ brew install kubernetes-helm

Mise en place d'un Ingress

Un deuxième schéma simplifié pour expliquer le principe de load balancing :

Une solution, Cert-Manager

Étape 1 - Installer le Tiller

Ignorez cette section si vous avez configuré le tiller.  

Tiller est le composant côté serveur de Helm, que le client helm utilise pour déployer des ressources.  Le déploiement de ressources est une opération privilégiée. dans le cas général nécessitant des privilèges. Avec cet exemple, nous donnons à Tiller le contrôle complet du cluster.

Créez un compte de service pour Helm:

$ kubectl create serviceaccount tiller --namespace=kube-system
serviceaccount "tiller" created

Accordez les privilèges d’administrateur du cluster au compte de service tiller:

$ kubectl create clusterrolebinding tiller-admin --serviceaccount=kube-system:tiller --clusterrole=cluster-admin
clusterrolebinding.rbac.authorization.k8s.io "tiller-admin" created

Installer Tiller avec le compte de service de Tiller :

$ helm init --service-account=tiller
$HELM_HOME has been configured at /Users/myaccount/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

Mettez à jour le repository Helm avec les derniers charts:

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "coreos" chart repository
Update Complete. ⎈ Happy Helming!⎈

Pré-requis :


Étape 2 - Déployer le contrôleur d’ingress NGINX

Un contrôleur d’ingress kubernetes est conçu pour être le point d’accès du trafic HTTP et HTTPS au logiciel exécuté dans votre cluster. Pour ce faire, le contrôleur nginx-ingress fournit un service de proxy HTTP pris en charge par l’équilibreur de charge de votre fournisseur de cloud.  Vous pouvez obtenir plus de détails sur nginx-ingress et son fonctionnement dans la documentation de nginx-ingress.  Utilisez helm pour installer un contrôleur Nginx Ingress:

$ helm install stable/nginx-ingress --name quickstart

NAME:   quickstart
LAST DEPLOYED: Sat Nov 10 10:25:06 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                                 AGE
quickstart-nginx-ingress-controller  0s

==> v1beta1/ClusterRole
quickstart-nginx-ingress  0s

==> v1beta1/Deployment
quickstart-nginx-ingress-controller       0s
quickstart-nginx-ingress-default-backend  0s

==> v1/Pod(related)

NAME                                                      READY  STATUS             RESTARTS  AGE
quickstart-nginx-ingress-controller-6cfc45747-wcxrg       0/1    ContainerCreating  0         0s
quickstart-nginx-ingress-default-backend-bf9db5c67-dkg4l  0/1    ContainerCreating  0         0s

==> v1/ServiceAccount

NAME                      AGE
quickstart-nginx-ingress  0s

==> v1beta1/ClusterRoleBinding
quickstart-nginx-ingress  0s

==> v1beta1/Role
quickstart-nginx-ingress  0s

==> v1beta1/RoleBinding
quickstart-nginx-ingress  0s

==> v1/Service
quickstart-nginx-ingress-controller       0s
quickstart-nginx-ingress-default-backend  0s


NOTES:
The nginx-ingress controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace default get services -o wide -w quickstart-nginx-ingress-controller'

An example Ingress that makes use of the controller:

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    annotations:
      kubernetes.io/ingress.class: nginx
    name: example
    namespace: foo
  spec:
    rules:
      - host: www.example.com
        http:
          paths:
            - backend:
                serviceName: exampleService
                servicePort: 80
              path: /
    # This section is only required if TLS is to be enabled for the Ingress
    tls:
        - hosts:
            - www.example.com
          secretName: example-tls

If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
    tls.crt: <base64 encoded cert>
    tls.key: <base64 encoded key>
  type: kubernetes.io/tls

Il peut prendre une minute ou deux au cloud provider (Gcloud) pour fournir et lier une adresse IP publique. Une fois l’opération terminée, vous pouvez voir l’adresse IP externe à l’aide de la commande kubectl:  Cette commande vous montre tous les services de votre cluster (dans le namespace par défaut), ainsi que leurs adresses IP externes. Lorsque vous créez le contrôleur pour la première fois, votre fournisseur de cloud n'a pas encore attribué et alloué d'adresse IP via LoadBalancer.

En attendant, l'adresse IP externe du service sera répertoriée comme <pending>. Votre fournisseur de cloud peut disposer d'options pour réserver une adresse IP avant de créer le contrôleur d'ingress et utiliser cette adresse IP au lieu d'attribuer une adresse IP à partir d'un pool. Lisez la documentation de votre fournisseur de cloud pour savoir comment organiser cela.

Étape 3 - Attribuer un DNS

L'adresse IP externe allouée au contrôleur d'entrée est l'adresse IP vers laquelle tout le trafic entrant doit être acheminé. Pour l'activer, ajoutez-le à une zone DNS que vous contrôlez, par exemple en tant qu'example.votre-domaine.com.  

MBP-de-admin:~ admin$ kubectl describe secret quickstart-example-tls
Name:         quickstart-example-tls
Namespace:    default
Labels:       certmanager.k8s.io/certificate-name=quickstart-example-tls
Annotations:  <none>

Type:  kubernetes.io/tls

Data
====
ca.crt:   0 bytes
tls.crt:  0 bytes
tls.key:  1679 bytes
MBP-de-admin:~ admin$ kubectl describe secret quickstart-example-tls
Name:         quickstart-example-tls
Namespace:    default
Labels:       certmanager.k8s.io/certificate-name=quickstart-example-tls
Annotations:  certmanager.k8s.io/alt-names=website.gsagnard.fr
              certmanager.k8s.io/common-name=website.gsagnard.fr
              certmanager.k8s.io/issuer-kind=Issuer
              certmanager.k8s.io/issuer-name=letsencrypt-staging

Type:  kubernetes.io/tls

Data
====
ca.crt:   0 bytes
tls.crt:  3562 bytes
tls.key:  1679 bytes

Étape 4 - Déployer un exemple de service

Votre service peut avoir son propre chart ou vous pouvez le déployer directement avec des manifestes. Ce quickstart utilise des manifestes pour créer et exposer un exemple de service. L'exemple de service utilise kuard, une application de démonstration qui constitue un excellent back-end pour les exemples.

L'exemple de démarrage rapide utilise trois manifestes pour l'échantillon. Les deux premiers sont un exemple de déploiement et un service associé:  manifeste de déploiement: deployment.yaml

... literalinclude:: example/deployment.yaml    :language: yaml
.. literalinclude:: example/service.yaml    :language: yaml 

Vous pouvez créer, télécharger et référencer ces fichiers localement, ou vous pouvez les référencer à partir du repository source GitHub pour cette documentation. Pour installer le service d'exemple à partir des fichiers du didacticiel directement à partir de GitHub, vous pouvez utiliser les commandes suivantes:

$ kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/master/docs/tutorials/acme/quick-start/example/deployment.yaml
deployment.extensions "kuard" created

$ kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/master/docs/tutorials/acme/quick-start/example/service.yaml
service "kuard" created

Kubernetes utilise une ressource d'ingress pour exposer cet exemple de service en dehors du cluster. Vous devrez télécharger et modifier l'exemple de manifeste pour qu'il corresponde au domaine que vous possédez ou contrôlez pour compléter cet exemple.  

Voici un exemple d’ingress avec lequel vous pouvez commencer:

.. literalinclude:: example/ingress.yaml
   :language: yaml


Vous pouvez télécharger le manifeste exemple depuis github, le modifier et l'envoyer à Kubernetes à l'aide de la commande suivante:

$ kubectl create --edit -f https://raw.githubusercontent.com/jetstack/cert-manager/master/docs/tutorials/acme/quick-start/example/ingress.yaml

# edit the file in your editor, and once it is saved:
ingress.extensions "kuard" created

Remarque :

L'exemple d'ingress que nous montrons ci-dessus contient une définition d'hôte. Le contrôleur nginx-ingress acheminera le trafic lorsque le nom d'hôte demandé correspondra à la définition de l'ingress. Vous pouvez déployer une ingress sans définition d'hôte dans la règle, mais ce modèle ne peut pas être utilisé avec un certificat TLS, qui attend un nom de domaine complet.  Une fois qu'il est déployé, vous pouvez utiliser la commande kubectl get ingress pour voir l'état de l'ingress:

NAME      HOSTS     ADDRESS   PORTS     AGE
kuard     *                   80, 443   17s

Cela peut prendre quelques minutes, en fonction de votre fournisseur de services, pour que l'entrée soit entièrement créée. Une fois créée et liée, l’ingress indiquera également une adresse:

NAME      HOSTS     ADDRESS         PORTS     AGE kuard     *         34.76.164.145   80        9m

Remarque  

L'adresse IP sur l'ingress peut ne pas correspondre à l'adresse IP du contrôleur nginx-ingress. C'est normal. Il s’agit d’un détail bizarre/d’implémentation du fournisseur de services hébergeant votre cluster Kubernetes. Étant donné que nous utilisons nginx-ingress-controller au lieu de tout système d'ingress spécifique au fournisseur de cloud, utilisez l’adresse IP définie et allouée pour la ressource LoadBalancer de nginx-ingress-service en tant que point d’accès principal de votre service.  

Assurez-vous que le service est accessible via le nom de domaine que vous avez ajouté ci-dessus, par exemple http://website.votre-domaine.com. La méthode la plus simple consiste à ouvrir un navigateur et à entrer le nom que vous avez défini dans DNS et pour lequel nous venons d'ajouter l'entrée.  Vous pouvez également utiliser un outil de ligne de commande tel que curl pour vérifier l'entrée.

$ curl -kivL -H 'Host: website.your-domain.com' '34.76.164.145'

Les options de cette commande curl fourniront une sortie détaillée, après les redirections, s'afficheront les en-têtes TLS dans la sortie et non une erreur sur les certificats non-sécurisés.

Avec nginx-ingress-controller, le service sera disponible avec un certificat TLS, mais il utilisera un certificat auto-signé fourni par défaut par nginx-ingress-controller. Les navigateurs afficheront un avertissement indiquant qu'il s'agit d'un certificat non valide. Ceci est normal et attendu, car nous n’avons pas encore utilisé cert-manager pour obtenir un certificat entièrement fiable pour notre site.  

Attention

Il est essentiel de vous assurer que votre ingress est disponible et répond correctement sur Internet. Cet exemple de démarrage rapide utilise Let's Encypt pour fournir les certificats, ce qui nécessite et valide à la fois que le service est disponible et que, lors de la délivrance d'un certificat, utilise cette validation comme preuve que la demande de domaine appartient à une personne disposant d'un contrôle suffisant sur le domaine.

Étape 5 - Déployer Cert Manager

Nous devons installer cert-manager pour faire le travail avec kubernetes afin de demander un certificat et répondre au défi de le valider. Nous pouvons utiliser helm pour installer cert-manager. Cet exemple a installé cert-manager dans le namespace kube-system à partir des charts publics d'Helm.

# Install the cert-manager CRDs. We must do this before installing the Helm
# chart in the next step
$ kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.6/deploy/manifests/00-crds.yaml

# Update your local Helm chart repositories
$ helm repo update

# Install cert-manager
$ helm install --name cert-manager --namespace cert-manager stable/cert-manager

NAME:   cert-manager
LAST DEPLOYED: Wed Jan  9 13:36:13 2019
NAMESPACE: cert-manager
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/ClusterRoleBinding
NAME                                 AGE
cert-manager-webhook-ca-sync         2s
cert-manager-webhook:auth-delegator  2s
cert-manager                         2s

==> v1beta1/APIService
NAME                                  AGE
v1beta1.admission.certmanager.k8s.io  2s

==> v1alpha1/Certificate
cert-manager-webhook-webhook-tls  1s
cert-manager-webhook-ca           1s

==> v1beta1/ValidatingWebhookConfiguration
cert-manager-webhook  1s

==> v1/ServiceAccount
NAME                          SECRETS  AGE
cert-manager-webhook-ca-sync  1        2s
cert-manager-webhook          1        2s
cert-manager                  1        2s

==> v1beta1/RoleBinding
NAME                                                AGE
cert-manager-webhook:webhook-authentication-reader  2s

==> v1beta1/Deployment
NAME                  DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
cert-manager-webhook  1        1        1           0          2s
cert-manager          1        1        1           0          2s

==> v1/Job
NAME                          DESIRED  SUCCESSFUL  AGE
cert-manager-webhook-ca-sync  1        0           2s

==> v1beta1/CronJob
NAME                          SCHEDULE      SUSPEND  ACTIVE  LAST SCHEDULE  AGE
cert-manager-webhook-ca-sync  * * */24 * *  False    0       <none>         2s

==> v1beta1/ClusterRole
NAME                          AGE
cert-manager-webhook-ca-sync  2s
cert-manager                  2s

==> v1/ClusterRole
cert-manager-webhook:webhook-requester  2s
cert-manager-view                       2s
cert-manager-edit                       2s

==> v1/Service
NAME                  TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE
cert-manager-webhook  ClusterIP  10.3.244.237  <none>       443/TCP  2s

==> v1/ConfigMap
NAME                          DATA  AGE
cert-manager-webhook-ca-sync  1     2s

==> v1alpha1/Issuer
NAME                           AGE
cert-manager-webhook-ca        1s
cert-manager-webhook-selfsign  1s

==> v1/Pod(related)
NAME                                   READY  STATUS             RESTARTS  AGE
cert-manager-webhook-745b49d445-rnxm2  0/1    ContainerCreating  0         2s
cert-manager-9cdd9f774-t856z           0/1    ContainerCreating  0         2s
cert-manager-webhook-ca-sync-ddf4b     0/1    ContainerCreating  0         2s

NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.readthedocs.io/en/latest/reference/issuers.html

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.readthedocs.io/en/latest/reference/ingress-shim.html

Cert-manager utilise deux ressources personnalisées différentes, également appelées CRD, pour configurer et contrôler son fonctionnement, ainsi que pour partager le statut de son fonctionnement.

Étape 6 - Configurer Let's Encrypt Issuer

Nous allons configurer deux issuers pour Let's Encrypt dans cet exemple. L'issuer de production Let's Encrypt a des limites de taux très strictes. Lorsque vous expérimentez et apprenez, il est très facile de respecter ces limites et de confondre limitation de débit et erreurs de configuration ou de fonctionnement.

Pour cette raison, nous commencerons par l'issuer de staging Let's Encrypt et, une fois que cela fonctionnera, basculerez vers un issuer de production.  Créez cette définition localement et mettez à jour l'adresse électronique avec la vôtre. Cet e-mail est requis par Let's Encrypt et utilisé pour vous avertir de l'expiration des certificats et des mises à jour.

.. literalinclude:: example/staging-issuer.yaml
   :language: yaml

Une fois édité, appliquez la ressource personnalisée:

$ kubectl apply -f staging-issuer.yaml
issuer.certmanager.k8s.io "letsencrypt-staging" created

Créez également un issuer de production et déployez-le. Comme pour l'issuer intermédiaire, vous devrez mettre à jour cet exemple et ajouter votre propre adresse électronique.

.. literalinclude:: example/production-issuer.yaml
   :language: yaml
   :emphasize-lines: 10
$ kubectl apply -f production-issuer.yaml
issuer.certmanager.k8s.io "letsencrypt-prod" created

Vérifiez le statut de l'issuer après l'avoir créé. Vous devriez voir l'issuer répertorié avec un compte enregistré.

Avec toutes les configurations préalables en place, nous pouvons maintenant effectuer les tâches pour demander le certificat TLS. Il existe deux manières principales de le faire: utiliser des annotations sur l'ingress, ou créer directement une ressource de certificat.  

Dans cet exemple, nous allons ajouter des annotations à l'ingress et tirer parti de l'ingress-shim pour qu'il crée la ressource de certificat en notre nom. Après avoir créé un certificat, le cert-manager mettra à jour ou créera une ressource ingress et l’utilisera pour valider le domaine. Une fois vérifié et publié, cert-manager créera ou mettra à jour le secret défini dans le certificat.  

Remarque  

Le secret utilisé dans l'ingress doit correspondre au secret défini dans le certificat. Il n'y a pas de vérification explicite, donc une faute de frappe dans le contrôleur nginx-ingress reviendra à son certificat auto-signé. Dans notre exemple, nous utilisons des annotations sur l'entrée (et l'entrée-shim) qui créeront les secrets corrects pour vous.  Modifiez l'entrée en ajoutant les annotations commentées dans notre exemple précédent:

.. literalinclude:: example/ingress-tls.yaml    :language: yaml    :emphasize-lines: 6-8  

et appliquez-le :

$ kubectl apply -f ingress-tls.yaml ingress.extensions "kuard" configured

Cert-manager lira ces annotations et les utilisera pour créer un certificat, que vous pourrez demander et voir:

$ kubectl get certificate
NAME                     AGE
quickstart-example-tls   38s

Cert-manager reflète l'état du processus pour chaque demande de l'objet de certificat. Vous pouvez afficher ces informations à l'aide de la commande kubectl describe:  Les événements associés à cette ressource et répertoriés au bas des résultats de la description indiquent l'état de la demande.

Dans l'exemple ci-dessus, le certificat a été validé et émis en quelques minutes.  Une fois terminé, cert-manager aura créé un secret contenant les détails du certificat en fonction du secret utilisé dans la ressource d'entrée. Vous pouvez également utiliser la commande describe pour afficher certains détails:

MBP-de-admin:~ admin$ kubectl describe certificate quickstart-example-tls
Name:         quickstart-example-tls
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-02-06T20:38:20Z
  Generation:          1
  Owner References:
    API Version:           extensions/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Ingress
    Name:                  kuard
    UID:                   4a8811d8-2a4c-11e9-a7b4-42010a840290
  Resource Version:        110933
  Self Link:               /apis/certmanager.k8s.io/v1alpha1/namespaces/default/certificates/quickstart-example-tls
  UID:                     24181736-2a4f-11e9-a7b4-42010a840290
Spec:
  Acme:
    Config:
      Domains:
        website.gsagnard.fr
      Http 01:
        Ingress:        
        Ingress Class:  nginx
  Dns Names:
    website.gsagnard.fr
  Issuer Ref:
    Kind:       Issuer
    Name:       letsencrypt-prod
  Secret Name:  quickstart-example-tls
Status:
  Conditions:
    Last Transition Time:  2019-02-06T20:47:53Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2019-05-07T19:47:52Z
Events:
  Type    Reason         Age               From          Message
  ----    ------         ----              ----          -------
  Normal  OrderCreated   5m (x2 over 10m)  cert-manager  Created Order resource "quickstart-example-tls-1448515998"
  Normal  OrderComplete  4m (x2 over 10m)  cert-manager  Order "quickstart-example-tls-1448515998" completed successfully
  Normal  Generated      1m (x3 over 10m)  cert-manager  Generated new private key
  Normal  Cleanup        1m                cert-manager  Deleting old Order resource "quickstart-example-tls-1448515998"
  Normal  OrderCreated   1m                cert-manager  Created Order resource "quickstart-example-tls-688706620"
  Normal  CertIssued     1m (x3 over 10m)  cert-manager  Certificate issued successfully
  Normal  OrderComplete  1m                cert-manager  Order "quickstart-example-tls-688706620" completed successfully

Maintenant que nous sommes sûrs que tout est configuré correctement, vous pouvez mettre à jour les annotations dans l'ingress pour spécifier l'issuer de production:

.. literalinclude:: example/ingress-tls-final.yaml
   :language: yaml

$ kubectl apply -f ingress.yaml

ingress.extensions "kuard" configured

Vous devrez également supprimer le secret existant, surveillé par le responsable de la certification, et lui demander de traiter à nouveau la demande avec l'issuer mis à jour.

$ kubectl delete secret quickstart-example-tls

secret "quickstart-example-tls" deleted

Cela va démarrer le processus pour obtenir un nouveau certificat, et en utilisant describe vous pouvez voir le statut. Une fois le certificat de production mis à jour, vous devriez voir l'exemple KUARD s'exécuter sur votre domaine avec un certificat TLS signé.  Vous pouvez voir l'état actuel de la commande ACME en exécutant kubectl describe sur la ressource Order créée par cert-manager pour votre certificat.

Ce qui donne au final dans le navigateur web de votre choix à l'adresse de votre site :

Have some fun :)