Skip to content
Snippets Groups Projects
Commit c8472d7f authored by leo.muff's avatar leo.muff
Browse files

updated mise en page

parent a4eea3c2
Branches
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
atelier_secu.md
+ 105
− 65
View file @ c8472d7f
# Scénario de création d'une infrastructure à clef publique \begin{titlepage}
## Glossaire \newcommand{\HRule}{\rule{\linewidth}{0.5mm}}
- **Certificat** : Dans le contexte de la sécurité informatique, un certificat est un document numérique permettant d’identifier et d'authentifier un utilisateur ou un service. Il contient aussi les informations nécessaires à l'établissement d'une communication sécurisée (clef publique, protocoles de chiffrements utilisés, etc). \center
- **Infrastructure à clef publique ou PKI (Public Key Infrastructure)** : Une PKI est un ensemble de processus basés sur l'utilisation de certificats qui permettent de chiffrer et d'authentifier les communications entre utilisateurs et services ou de service à service. \textsc{\LARGE Haute école du paysage, d'ingénierie et d'architecture de Genève}\\[1.5cm]
- **Politique de certification** : Ensemble de décisions qui définissent les caractéristique des certificats émis. La politique de certification définit le temps de vie des certificats, la chaîne de confiance, les politiques de révocations, etc. \includegraphics[width=3cm]{images/logo.png} \\[1.5cm]
- **Autorité de certification ou CA (Certificate Authority)** : Une autorité de certification est un organisme qui agit comme tiers de confiance. La CA est responsable de l'émission de certificats et de leur validation. Pour être considérée comme un tiers de confiance valide, l'autorité doit être reconnue par les principaux navigateurs et systèmes d'exploitation. \textsc{\Large Ateliers en sécurité}\\[0.5cm]
\textsc{\large Scénario d'infrastructure à clef publique}\\[0.5cm]
\HRule \\[0.4cm]
{ \huge \bfseries Créer une autorité de certification avec Vault et Kubernetes}\\[0.4cm]
\HRule \\[1.5cm]
\begin{minipage}{0.4\textwidth}
\begin{flushleft} \large
\emph{Auteurs:}\\
Flavio \textsc{Morrone}\\
Elio \textsc{Marconi}\\
Léo \textsc{Muff}\\
\end{flushleft}
\end{minipage}\\[2cm]
{\large \today}\\[2cm]
\vfill
\end{titlepage}
\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}
\tableofcontents
\newpage
https://fr.wikipedia.org/wiki/Autorit%C3%A9_de_certification
https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique
https://en.wikipedia.org/wiki/Certificate_policy
https://en.wikipedia.org/wiki/Key_management
https://www.digicert.com/fr/what-is-pki
https://www.ssldragon.com/blog/best-practices-to-store-the-private-key/
https://www.thesslstore.com/blog/what-is-a-key-management-service-key-management-services-explained/
https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html#storage
## Introduction
# Introduction
Dans le cadre du cours "Ateliers en sécurité", il nous a été demandé de créer une entreprise fictive qui utilise une infrastructure à clef publique, ou PKI (Public Key Infrastructure), pour sécuriser ses services. Ce document décrit le scénario choisi, l'organisation de notre entreprise fictive et les différents composants physiques et logiciels utilisés pour mettre en place notre infrastructure. Il décrit aussi la politique de certification utilisée pour celle-ci. Dans le cadre du cours "Ateliers en sécurité", il nous a été demandé de créer une entreprise fictive qui utilise une infrastructure à clef publique, ou PKI (Public Key Infrastructure), pour sécuriser ses services. Ce document décrit le scénario choisi, l'organisation de notre entreprise fictive et les différents composants physiques et logiciels utilisés pour mettre en place notre infrastructure. Il décrit aussi la politique de certification utilisée pour celle-ci.
## Idée principale # Idée principale
Nous avons choisi de concevoir une entreprise fournissant une version simplifiée des services proposés par une autorité de certification comme Let's Encrypt. Notre infrastructure comprendra donc sa propre autorité de certification qui permettra d'émettre des certificats pour nos services internes ainsi que pour les services publiques de nos clients. Ces derniers pourront utiliser les certificats émis par notre CA grâce à un outil similaire à [Certbot](https://certbot.eff.org/pages/about). Nous avons choisi de concevoir une entreprise fournissant une version simplifiée des services proposés par une autorité de certification comme Let's Encrypt. Notre infrastructure comprendra donc sa propre autorité de certification qui permettra d'émettre des certificats pour nos services ainsi que pour les services publiques de nos clients. La gestion de ces certificats pourra ensuite être automatisée grâce au protocole ACME (Automated Certificate Management Environment).
## Points à traiter : \newpage
- problème wildcards # Description de l'infrastructure à clef publique
- vérifier l'identité du possesseur du mail → via a challenge-and-response email exchange with the address in the WHOIS entry, for example
- expiration des certificats racines et intermédiaires → bridge CA
- service de support
- gestion des clefs privées
- changement de protocoles sécurisés
- delegation
- stratégie de révocation (personnes physiques)
- Trust sign ?
La section ci-dessous décrit les composants et la logique interne de notre entreprise fictive, qui sera appelée **Chepia**.
## Outils : ## Chaîne de confiance
- [**MicroK8s**](https://microk8s.io/) : Déploiement Kubernetes dans un seul package. 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.
- [**Vault**](https://www.vaultproject.io/) : Outil de gestion de secrets qui propose de nombreuses fonctionnalité facilitant la mise en place d'une infrastructure à clé publique.
- [**Cert-manager**](https://cert-manager.io/) : Outil de gestion de certificat pour Kubernetes
## Schéma de l'infrastructure à clef publique
## Nom de l'entreprise : \center
\hspace{1in}
\includegraphics[width=6cm]{images/trust-chain.drawio.png}
- ChepiA \newpage
## Mise en place de l'infrastructure :
### Set up k8s cluster + install Vault ## 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.
- [**Vault**](https://www.vaultproject.io/) : Outil de gestion de secrets qui propose de nombreuses fonctionnalité facilitant la mise en place d'une infrastructure à clé publique.
- [**Cert-manager**](https://cert-manager.io/) : Outil de gestion de certificat pour Kubernetes. Son rôle sera de gérer le processus de certification pour nos services via notre gestionnaire de secrets Vault.
- [**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.")
# Mise en place de l'infrastructure :
## Set up k8s cluster + install Vault
``` ```
sudo snap install microk8s --classic --channel=1.29 sudo snap install microk8s --classic --channel=1.29
...@@ -75,7 +96,7 @@ Initial Root Token: hvs.zWAYhaUkch0hfgfi18fduTvl ...@@ -75,7 +96,7 @@ Initial Root Token: hvs.zWAYhaUkch0hfgfi18fduTvl
![Interface graphique de Vault vérouillée](images/vault-seal.png "Interface graphique de Vault vérouillée") ![Interface graphique de Vault vérouillée](images/vault-seal.png "Interface graphique de Vault vérouillée")
### Install tools on pod ## Install tools on pod
- jq (json parsing) - jq (json parsing)
...@@ -87,11 +108,11 @@ chmod +x jq ...@@ -87,11 +108,11 @@ chmod +x jq
``` ```
### Configurer le PKI : ## Création de l'autorité de certification
- https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine?variants=vault-deploy%3Aselfhosted - https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine?variants=vault-deploy%3Aselfhosted
#### 1. Création du CA racine: ### 1. Création du CA racine:
Commandes : Commandes :
...@@ -107,7 +128,7 @@ vault write pki/config/urls issuing_certificates="$VAULT_ADDR/v1/pki/ca" \ crl_d ...@@ -107,7 +128,7 @@ vault write pki/config/urls issuing_certificates="$VAULT_ADDR/v1/pki/ca" \ crl_d
→ TTL de 2 semaine ( pour tester le bridge CA ) → TTL de 2 semaine ( pour tester le bridge CA )
→ Rôle permissif au niveau des noms (a changer ?) → Rôle permissif au niveau des noms (a changer ?)
#### 2. Création du CA intermédiaire : ### 2. Création du CA intermédiaire :
Commandes : Commandes :
...@@ -129,7 +150,7 @@ vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem ...@@ -129,7 +150,7 @@ vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
→ TTL 10 jours → TTL 10 jours
#### 3. Création du rôle : ### 3. Création du rôle :
- 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. - 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.
...@@ -144,7 +165,7 @@ Commandes : ...@@ -144,7 +165,7 @@ Commandes :
``` ```
#### 4. Demander un certificat : ### 4. Demander un certificat :
Commande : Commande :
...@@ -154,15 +175,15 @@ vault write pki_int/issue/chepia-dot-ch common_name="test.chepia.ch" ttl="24h" ...@@ -154,15 +175,15 @@ vault write pki_int/issue/chepia-dot-ch common_name="test.chepia.ch" ttl="24h"
→ Crée un certificat valide 24 heures pour le nom de domaine "test.chepia.ch" → Crée un certificat valide 24 heures pour le nom de domaine "test.chepia.ch"
### Configurer cert-manager ## Configuration de cert-manager
- https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager - https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
#### 1. Activation de cert-manager : ### 1. Activation de cert-manager :
- `microk8s enable cert-manager` - `microk8s enable cert-manager`
#### 2. Configurer l'accès entre Vault et Kubernetes ### 2. Configurer l'accès entre Vault et Kubernetes
```bash ```bash
kubectl exec --stdin=true --tty=true vault-0 -- /bin/sh kubectl exec --stdin=true --tty=true vault-0 -- /bin/sh
...@@ -173,7 +194,7 @@ write auth/kubernetes/config \ ...@@ -173,7 +194,7 @@ write auth/kubernetes/config \
→ 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. → 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 ### 3. Configurer l'émetteur de certificats
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 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` `kubectl create serviceaccount issuer`
2. Créer un secret que l'identité `issuer` utilisera pour s'authentifier : 2. Créer un secret que l'identité `issuer` utilisera pour s'authentifier :
...@@ -217,9 +238,9 @@ spec: ...@@ -217,9 +238,9 @@ spec:
### Mise en place de TLS sur un service ## Mise en place de TLS sur un service
#### 1. Création du service ### 1. 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`. - 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`.
...@@ -287,7 +308,7 @@ spec: ...@@ -287,7 +308,7 @@ spec:
3. Appliquer les configs : `microk8s kubectl apply -f html-volumes.yaml`, `microk8s kubectl apply -f nginx.yaml` 3. Appliquer les configs : `microk8s kubectl apply -f html-volumes.yaml`, `microk8s kubectl apply -f nginx.yaml`
#### 2. Création du certificat du service : ### 2. Création du certificat du service :
- Création du fichier `cert.yaml` : - Création du fichier `cert.yaml` :
...@@ -308,7 +329,7 @@ spec: ...@@ -308,7 +329,7 @@ spec:
- Appliquer la config avec la commande `microk8s kubectl apply -f cert.yaml` - Appliquer la config avec la commande `microk8s kubectl apply -f cert.yaml`
#### 3. Configuration de l'accès au service ### 3. Configuration de l'accès au service
- Créer le fichier `nginx-service.yaml`: - Créer le fichier `nginx-service.yaml`:
...@@ -350,7 +371,7 @@ spec: ...@@ -350,7 +371,7 @@ spec:
- Appliquer la config avec la commande `microk8s kubectl apply -f nginx-service.yaml` - Appliquer la config avec la commande `microk8s kubectl apply -f nginx-service.yaml`
#### 4. Test de l'accès au service ### 4. 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`:
`127.0.0.1 www.chepia.ch` `127.0.0.1 www.chepia.ch`
...@@ -382,15 +403,15 @@ Si on retourne sur *www.chepia.ch*, l'alerte a disparu. ...@@ -382,15 +403,15 @@ 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.") ![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.")
### Mise à jour des certificats ## Mise à jour des certificats
#### 1. Suppression des certificats expirés ### 1. Suppression des certificats expirés
``` ```
vault write pki_int/tidy tidy_cert_store=true tidy_revoked_certs=true vault write pki_int/tidy tidy_cert_store=true tidy_revoked_certs=true
``` ```
#### 2. Rotation du certificat racine ### 2. Rotation du certificat racine
``` ```
vault write pki/root/rotate/internal \ vault write pki/root/rotate/internal \
...@@ -403,7 +424,7 @@ vault write pki/roles/chepia-servers allow_any_name=true ...@@ -403,7 +424,7 @@ vault write pki/roles/chepia-servers allow_any_name=true
``` ```
#### 3. Création d'un pont entre le nouveau certificat racine et l'ancien ### 3. 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. 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.
...@@ -427,13 +448,13 @@ Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis lon ...@@ -427,13 +448,13 @@ Cette étape permet aux services qui n'ont pas communiqué avec le CA depuis lon
``` ```
#### 4. Remplacer l'émetteur par défaut ### 4. Remplacer l'émetteur par défaut
``` ```
vault write pki/root/replace default=root-2 vault write pki/root/replace default=root-2
``` ```
#### 5. Signer l'autorité intermédiaire avec notre nouveau certificat racine ### 5. Signer l'autorité intermédiaire avec notre nouveau certificat racine
```bash ```bash
cd vault cd vault
...@@ -453,26 +474,26 @@ vault write -format=json pki/issuer/root-2/sign-intermediate \ ...@@ -453,26 +474,26 @@ vault write -format=json pki/issuer/root-2/sign-intermediate \
vault write pki_int/intermediate/set-signed certificate=@cross-signed-intermediate.crt vault write pki_int/intermediate/set-signed certificate=@cross-signed-intermediate.crt
``` ```
### ACME setup ## ACME setup
#### terminal : ### terminal :
```bash ```bash
vault write /sys/mounts/pki_int/tune \ vault write /sys/mounts/pki_int/tune \
passthrough_request_headers="If-Modified-Since" \ passthrough_request_headers="If-Modified-Since" \
allowed_response_headers="Last-Modified,Location,Replay-Nonce,Link" allowed_response_headers="Last-Modified,Location,Replay-Nonce,Link"
``` ```
#### GUI : ### GUI :
- go to the intermediate certificate configuration page - go to the intermediate certificate configuration page
- add url `http://127.0.0.1:8200/v1/pki_int` to AIA path and Mount's API path - add url `http://127.0.0.1:8200/v1/pki_int` to AIA path and Mount's API path
- Tick "Enable ACME" - Tick "Enable ACME"
- save - save
### Add ACME to cert-manager ## Add ACME to cert-manager
https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-cert-manager
#### add issuer ### add issuer
- Création du fichier de configuration acme.yaml - Création du fichier de configuration acme.yaml
...@@ -496,7 +517,7 @@ spec: ...@@ -496,7 +517,7 @@ spec:
- Activation de la config avec `microk8s kubectl apply -f acme.yaml ` - Activation de la config avec `microk8s kubectl apply -f acme.yaml `
### Add ingress to the k8s cluster ## Add ingress to the k8s cluster
- Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes : - Activer l'addon `ingress`qui permet d'exposer des services gérés par le cluster kubernetes :
...@@ -504,7 +525,7 @@ spec: ...@@ -504,7 +525,7 @@ spec:
- On peut maintenant créer des règles pour exposer des services en https. - On peut maintenant créer des règles pour exposer des services en https.
### Create certificate ## Create certificate
``` ```
apiVersion: cert-manager.io/v1 apiVersion: cert-manager.io/v1
...@@ -534,4 +555,23 @@ spec: ...@@ -534,4 +555,23 @@ spec:
https://cert-manager.io/docs/usage/ingress/ https://cert-manager.io/docs/usage/ingress/
\ No newline at end of file
# Glossaire
- **Kubernetes** : Système d'orchestration de conteneurs qui permet de créer facilement une infrastructure virtuelle en automatisant le déploiement d'applications, la configuration du réseau et des services, etc.
- **Certificat** : Dans le contexte de la sécurité informatique, un certificat est un document numérique permettant d’identifier et d'authentifier un utilisateur ou un service. Il contient aussi les informations nécessaires à l'établissement d'une communication sécurisée (clef publique, protocoles de chiffrements utilisés, etc).
- **Infrastructure à clef publique ou PKI (Public Key Infrastructure)** : Une PKI est un ensemble de processus basés sur l'utilisation de certificats qui permettent de chiffrer et d'authentifier les communications entre utilisateurs et services ou de service à service.
- **Politique de certification** : Ensemble de décisions qui définissent les caractéristique des certificats émis. La politique de certification définit le temps de vie des certificats, la chaîne de confiance, les politiques de révocations, etc.
- **Autorité de certification ou CA (Certificate Authority)** : Une autorité de certification est un organisme qui agit comme tiers de confiance. La CA est responsable de l'émission de certificats et de leur validation. Pour être considérée comme un tiers de confiance valide, l'autorité doit être reconnue par les principaux navigateurs et systèmes d'exploitation.
- **Chaîne de confiance**
# Références
https://fr.wikipedia.org/wiki/Autorit%C3%A9_de_certification
https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique
https://en.wikipedia.org/wiki/Certificate_policy
https://en.wikipedia.org/wiki/Key_management
https://www.digicert.com/fr/what-is-pki
https://www.ssldragon.com/blog/best-practices-to-store-the-private-key/
https://www.thesslstore.com/blog/what-is-a-key-management-service-key-management-services-explained/
https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html#storage
\ No newline at end of file
atelier_secu.pdf
+ 0
− 0
View file @ c8472d7f
No preview for this file type
images/logo.png 0 → 100644
+ 0
− 0
View file @ c8472d7f
images/logo.png

149 KiB

images/soft.drawio.png 0 → 100644
+ 0
− 0
View file @ c8472d7f
images/soft.drawio.png

699 KiB

images/trust-chain.drawio.png 0 → 100644
+ 0
− 0
View file @ c8472d7f
images/trust-chain.drawio.png

28.1 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment