@@ -50,14 +50,15 @@ La section ci-dessous décrit les composants et la logique interne de notre entr
Notre autorité racine émettra les certificats deux deux autorités intermédiaires : une pour émettre les certificats des services internes de notre entreprise, et une pour les certificats fourni avec ACME aux services externes de nos clients.
\caption{Chaîne de confiance de notre autorité de certification}
\end{figure}
\newpage
## Composants logiciels
-[**MicroK8s**](https://microk8s.io/) : Déploiement Kubernetes dans un seul package. Conçu pour le développement de services conteneurisés sur une machine locale.
...
...
@@ -66,23 +67,45 @@ Notre autorité racine émettra les certificats deux deux autorités intermédia
-[**Nginx**](https://docs.nginx.com/) : Serveur web. Utilisé pour tester le fonctionnement de notre autorité de certification.
-[**ACME**](https://www.ssl.com/fr/faq/quel-est-le-protocole-acme/)(Automated Certificate Management Environment) : Protocole utilisé pour automatiser le processus de certification. Il nous permettra de créer un service similaire à celui de Let's Encrypt, et fournir des certificats aux services de nos clients.
## Schéma des services
![Image non trouvée : images/soft.drawio.png Pile des ](images/soft.drawio.png"Pile des éléments logiciels de l'infrastructure à clef publique.")
Les commandes suivantes permettent d'installer microk8s et d'y déployer une instance de Vault. Elles ont été testées sur un système Ubuntu 22.04, et peuvent varier selon le système utilisé.
Une fois Vault déployé, le gestionnaire de secret doit être initialisé. Cette opération va créer une clef privée qui sera utilisée pour chiffrer les données de Vault. Cette clef est ensuite chiffrée par une autre clé aussi appelée clé *root key* qui est elle-même chiffrée par une autre clef appelée *unseal key* . La clé *unseal* est ensuite partagée en plusieurs partie selon le partage de secret de Shamir. Les différentes parties devront ensuite être réunies pour déverrouiller Vault.
![Secret partagé de Shamir](images/shamir.png"Secret partagé de Shamir")
\newpage
L'initialisation de Vault s'effectue avec la commande suivante :
Ces informations doivent être stockées de manière sécurisée, en utilisant un HSM (Hardware Security Module) par exemple. Une fois en possession de ces informations, on peut accéder aux fonctionnalité de Vault.
--> Pour déverrouiller Vault, il faut que 3 des 5 tokens créés soit renseignés. On doit ensuite se logger avec le token root
Pour accéder à l'interface graphique de Vault, on utilise la commande suivante :
```bash
microk8s kubectl port-forward vault-0 8200:8200
```
→ L'interface sera disponible à l'adresse 127.0.0.1:8200
![Interface graphique de Vault vérouillée](images/vault-seal.png"Interface graphique de Vault vérouillée")
## Install tools on pod
→ Pour déverrouiller Vault, il faut que 3 des 5 tokens créés soit renseignés (n'importe lesquels). On doit ensuite se logger avec un token utilisateur (root par défaut)
- jq (json parsing)
\newpage
```
## Installation d'un parser JSON
Vault est aussi utilisable en ligne de commande. Pour cela, il faut se connecter au container avec la commande suivante :
```bash
microk8s kubectl exec-ti vault-0 -- sh
```
Une fois connectés au container, on peut utiliser l'outil `vault` en ligne de commande. Comme cet outil génère principalement du JSON en sortie, il est nécessaire d'installer le parser JQ pour pouvoir réutiliser la sortie facilement.
Une fois Vault prêt, on peut commencer à mettre en place notre PKI. Les étapes ci-dessous utilise la ligne de commande mais une correspondance en interface graphique est possible, voir la documentation de Vault pour cela.
→ TTL 10 jours (doit être plus court que celui de la racine)
### 3. Création du rôle :
### Création du rôle : \newline
- Un rôle définit une politique d'accès au certificats intermédiaire : Le domaine doit être `chepia.ch` ou un sousdomaine comme `www.chepia.ch`, et le temps de vie maximum est de 120 heures.
- Un rôle définit une politique d'accès au certificats intermédiaire : Le domaine doit être `chepia.ch` ou un sous-domaine comme `www.chepia.ch`, et le temps de vie maximum est de 120 heures.
→ La variable globale `$KUBERNETES_PORT_443_TCP_ADDR`est à modifier selon votre configuration. L'adresse utilisée par le service principal de Kubernetes peut être consultée avec la commande `microk8s kubectl get services | grep kubernetes`. Dans mon cas, Kubernetes utilise l'adresse 10.152.183.1.
### 3. Configurer l'émetteur de certificats
\newpage
### Configurer l'émetteur de certificats \newline
1. Créer une identité pour communiquer avec l'émetteur. C'est avec cette identité que cert-manager utilisera pour accéder au rôle créé à l'étape précédente : \newline
`kubectl create serviceaccount issuer`
2. Créer un secret que l'identité `issuer` utilisera pour s'authentifier :
- On crée pour cela le fichier `issuer-secret.yaml`:
→ On crée pour cela le fichier `issuer-secret.yaml`:
```
```yaml
apiVersion:v1
kind:Secret
metadata:
...
...
@@ -211,7 +256,7 @@ metadata:
type:kubernetes.io/service-account-token
```
- Appliquer la config avec la commande `microk8s kubectl apply -f issuer-secret.yaml`.
→ Appliquer la config avec la commande `microk8s kubectl apply -f issuer-secret.yaml`.
3. Créer le ficher de configuration de l'émetteur `vault-issuer.yaml`:
...
...
@@ -234,13 +279,19 @@ spec:
key:token
```
- Appliquer la config avec la commande `microk8s kubectl apply -f vault-issuer.yaml`.
→ Appliquer la config avec la commande `microk8s kubectl apply -f vault-issuer.yaml`.
## Installer Nginx Ingress
- Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes :
`microk8s enable ingress`
- On peut maintenant créer des règles pour exposer des services hors de notre cluster Kubernetes.
## Mise en place de TLS sur un service
### 1. Création du service
### Création du service
- Nous allons utiliser un simple serveur web Nginx pour représenter la page d'accueil de notre entreprise. Les étapes suivantes montrent comment créer un stockage pour le code source de notre site et déployer une instance Nginx qui monte ce stockage dans le dossier `/usr/share/nginx/html`.
...
...
@@ -272,6 +323,7 @@ spec:
requests:
storage:1Gi
```
\newpage
2. Créer le fichier de config du serveur (`nginx.yaml`) :
- Appliquer la config avec la commande `microk8s kubectl apply -f cert.yaml`
### 3. Configuration de l'accès au service
### Configuration de l'accès au service
- Créer le fichier `nginx-service.yaml`:
...
...
@@ -371,28 +423,45 @@ spec:
- Appliquer la config avec la commande `microk8s kubectl apply -f nginx-service.yaml`
### 4. Test de l'accès au service
\newpage
### Test de l'accès au service
Pour pouvoir accéder à notre service de manière sécurisée, il faut le faire par son nom de domaine, car c'est à celui-ci qu'est relié le certificat créé précédemment. Pour cela, on va ajouter la ligne suivante au fichier `/etc/hosts`:
Pour pouvoir accéder à notre service de manière sécurisée, il faut le faire par son nom de domaine, car c'est à celui-ci qu'est relié le certificat créé précédemment. Pour cela, on va ajouter la ligne suivante au fichier `/etc/hosts`:\newline
`127.0.0.1 www.chepia.ch`
Ensuite, on peut tester la connexion TLS avec la commande :
` curl -kivL 'https://www.chepia.ch'`
![Connexion à notre service en https avec curl. ](images/curl.png"Connexion à notre service en https avec curl. ")
\begin{figure}
\hspace{2in}
\center
\includegraphics[width=8cm]{images/curl.png}
\caption{Connection à notre service en https avec Curl}
\end{figure}
On peut voir que le certificat du serveur est bien émit par notre autorité de certification intermédiaire. Par contre
la ligne `SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.` indique que notre CA n'a pas été reconnu. C'est normal, car on a pas encore ajouté le certificat racine de notre autorité à la liste des CA reconnu par notre système d'exploitation. Si on essaye d'accéder à notre service avec un navigateur web, on va rencontrer l'avertissement suivant :
la ligne `SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.` indique que notre CA n'a pas été reconnu. C'est normal, car on a pas encore ajouté le certificat racine de notre autorité à la liste des CA reconnu par notre système d'exploitation. Si on essaye d'accéder à notre service avec un navigateur web, on va rencontrer un avertissement similaire.
\newpage
![Notre CA n'est pas reconnu par le navigateur Firefox](images/auth_unknown.png"Notre CA n'est pas reconnu par le navigateur Firefox")
\caption{Avertissement de sécurité de Firefox. Notre CA n'est pas reconnu par le navigateur.}
\end{figure}
Pour remédier à cela, on va chercher le certificat de notre autorité intermédiaire dans l'interface graphique de Vault.
![On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch](images/cert_gui.png"On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority")
![On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority](images/cert_gui.png"On peut télécharger ou copier le certificat depuis la page secrets -> pki_int -> issuers -> chepia.ch Intermediate Authority")
\newpage
Ensuite, on crée un sous-répertoire `chepia.ch` dans le répertoire `/usr/local/share/ca-certificates`:
On place le certificat dans le répertoire et on met à jour la liste des CAs reconnus avec `sudo update-ca-certificates`.
Ensuite, on crée un sous-répertoire `chepia.ch` dans le répertoire `/usr/local/share/ca-certificates`.
On y place le certificat et on met à jour la liste des CAs reconnus avec `sudo update-ca-certificates`.
Il faut aussi ajouter le certificat à la liste des CAs de confiance de votre navigateur. Pour cela, allez dans *préférences*, *Vie privée et sécurité*, *Certificats* et cliquer sur *Afficher les certificats* puis *Importer*.
Une fois le certificat importé, on retrouve notre autorité dans la liste des CAs de confiance.
...
...
@@ -403,15 +472,17 @@ Si on retourne sur *www.chepia.ch*, l'alerte a disparu.
![Le point d'exclamation a disparu du cadenas, on peut utiliser le service de manière sécurisée.](images/lock.png"Le point d'exclamation a disparu du cadenas, on peut utiliser le service de manière sécurisée.")
### 3. Création d'un pont entre le nouveau certificat racine et l'ancien
### Création d'un pont entre le nouveau certificat racine et l'ancien
Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis longtemps et doivent mettre à jour leur certificat racine. Le pont permet à ses service de faire confiance à notre nouveau certificat racine.
