Name: Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
Rating: 5 (1 reviews)

Objectifs du chapitre et prérequis

Le chapitre précédent explique comment exposer une application sur Internet. Il est ainsi possible de la consulter depuis n’importe où. En revanche, la question de la sécurisation de l’accès n’a pas été traitée.

Le chapitre abordera plusieurs mécanismes :

La mise en place du protocole HTTPS (à l’aide de certificats Let’s Encrypt).
La restriction des accès par authentification HTTP basic.
La mise en place d’une restriction d’accès par Oauth2.

Les exercices qui suivent utiliseront le gestionnaire Ingress Nginx, mais des indications seront également données pour Traefik.

La sécurisation des accès internes sera abordée dans le prochain chapitre.

Mise en place de Let’s Encrypt

1. Présentation de Let’s Encrypt

D’après Wikipédia, Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015. Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS.

Le but de cette autorité de certification vise à généraliser l’utilisation de connexions sécurisées sur Internet comme par exemple avec le protocole HTTPS.

La création des certificats se fait de manière automatique sur le principe d’un défi-réponse basé sur la création d’entrées DNS ou HTTP. Un automate se charge ensuite de vérifier que ces entrées sont bien créées.

Pour plus de détails, consultez l’article Let’s Encrypt de Wikipédia France disponible à l’adresse suivante : https://fr.wikipedia.org/wiki/Let%27s_Encrypt

2. Installation du chart Helm cert-manager

a. Présentation du chart Helm

Le chart Helm jetstack/cert-manager mis à disposition par Jetstack propose une version prête à l’emploi du gestionnaire de certificats. Ce gestionnaire va prendre en charge tout le cycle de vie des certificats du cluster :

Demande de création.
Renouvellement automatique.

Il sera présenté afin de fonctionner avec le gestionnaire de certificats Let’s Encrypt.

Pour fonctionner correctement, le gestionnaire de certificats doit avoir les droits de gérer des enregistrements DNS. Ces droits peuvent être positionnés :

soit par une police au niveau du cluster au moment de la création,
soit par la création d’un compte dédié et l’utilisation d’un secret (cf. chapitre Exposition des applications sur Internet).

À noter que le déroulement des exercices réclame la mise en place du gestionnaire des entrées DNS (external-dns) vu dans le chapitre précédent. Il est impératif de disposer d’un compte de service permettant la gestion des entrées DNS.

b. Prérequis avant installation

Le gestionnaire de certificats procède - au premier déploiement - à la création d’un nouveau type de ressources personnalisées (CustomResourceDefinition ou CRD en abrégé)....

Protection de l’accès aux applications

1. Origine du besoin

Du fait de la présence de certificats, il n’est plus possible d’espionner le trafic des utilisateurs. En revanche, il n’y pas de contrôle d’accès des utilisateurs : toute personne qui récupère l’adresse de MailHog y accède sans limitation.

Afin de protéger les applications, il convient de mettre en place un mécanisme de contrôle d’accès.

2. Mot de passe simple (HTTP basic)

a. Principe de fonctionnement

Une des solutions les plus courantes de protection est d’utiliser une authentification par identifiant/mot de passe (on parle de protection HTTP basic). Au moment d’accéder à l’application à l’aide du navigateur, l’utilisateur est invité à saisir un identifiant et son mot de passe.

Ce mécanisme d’authentification est relativement ancien et trouve son origine dans les premiers serveurs HTTP et notamment le serveur Apache. Ce dernier met à disposition l’outil htpasswd : il permet de générer des signatures de mots de passe avec salage dans des fichiers dédiés à cet usage.

Dans ce qui va suivre, l’utilisateur va aborder une technique permettant de stocker ces éléments directement dans un secret Kubernetes puis d’indiquer au contrôleur Ingress comment y accéder.

b. Création du secret à l’aide de htpasswd

La mise en place de cette protection réclame la création d’un fichier contenant les identifiants utilisateurs. Cette opération se fait à l’aide de la commande htpasswd suivie des options suivantes :

L’option -c (à ajouter dans le cas de la création initiale).
Le nom du fichier (exemple : mailhog-secret.htpasswd).
Le nom de l’utilisateur à créer dans le fichier.

Initialisez le contenu du fichier à l’aide de la commande suivante :

$ htpasswd -c mailhog-secret.htpasswd mailhog-user

La commande demande la double saisie du mot de passe de l’utilisateur :

New password: 
Re-type new password: 
Adding password for user mailhog-user

N’hésitez pas à observer le contenu du fichier à...

Authentification basée sur OAuth2

1. À propos du protocole OAuth2

Le protocole OAuth2 est un protocole qui permet de gérer les accès à un site web en s’appuyant sur un mécanisme existant (Facebook, Google, GitHub, Gitlab, etc.).

Pour plus de détails, vous pouvez consulter l’article suivant sur Wikipédia : https://fr.wikipedia.org/wiki/OAuth

Le principal intérêt de ce protocole est qu’il permet de déléguer l’identification des utilisateurs auprès d’un tiers connu par ces derniers. Ainsi, ils peuvent réutiliser une identité existante.

2. Principe de la solution

L’authentification de l’utilisateur va se faire auprès d’un service dédié à l’aide d’un proxy. Ce dernier se chargera d’authentifier l’utilisateur et de le renvoyer vers MailHog.

Le mécanisme de proxy s’appuiera sur l’outil oauth2-proxy disponible sous la forme de chart Helm.

Schéma de principe utilisant le service d’authentification de GitHub comme autorité OAuth2

GitHub servira de tiers d’authentification, mais l’exercice est transposable à d’autres tiers externes comme par exemple Google, Facebook, Twitter, etc. ou internes (ex. : Keycloak, OpenAM, Azure Active Directory, etc.).

Même si l’outil OAuth2 Proxy supporte plusieurs fournisseurs d’identité, il ne peut en utiliser qu’un seul à la fois.

3. Création d’un identifiant GitHub

Pour la suite de l’exercice, l’utilisateur devra disposer d’un identifiant sur GitHub.

La première opération va être de créer une nouvelle application GitHub. Pour cela, entrez l’adresse suivante dans un navigateur : https://github.com/settings/applications/new

L’écran va demander les éléments suivants sur l’application :

Le nom de l’application.
L’adresse de l’application (ex. : https://mailhog.eni.yannig.ovh).
Une description facultative.
L’adresse de gestion de l’authentification : il s’agit de la même chose que l’adresse de l’application suivie du contexte /oauth2.