Mirror the French docs onto the English structure
This commit is contained in:
Djeex
@@ -1,257 +0,0 @@
|
||||
---
|
||||
title: Wireguard
|
||||
description: Installer et configurer WireGuard VPN pour accéder à votre homelab de n'importe où et connecter tous vos appareils à votre réseau privé.
|
||||
---
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
# Wireguard
|
||||
|
||||
::note
|
||||
🎯 __Objectifs :__
|
||||
|
||||
- Installer Wireguard
|
||||
- Configurer les clients
|
||||
- Accéder au réseau sécurisé
|
||||
::
|
||||
|
||||
## Introduction
|
||||
L'utilisation d'un VPN permet d'accéder à distance aux ressources locales du serveur sans les exposer sur internet. C'est notamment une manière propre de sécuriser l'accès à la console SSH, plutot que d'exposer le port sur internet. C'est pouvoir se connecter à son réseau où que l'on soit, de maniere sécurisée, et de faire dialoguer des machines qui sont sur des réseaux différents.
|
||||
|
||||
Ici nous utiliserons [Wireguard](https://www.wireguard.com/), un serveur VPN sécurisé et très performant, à l'aide des conteneurs :
|
||||
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) pour le serveur, qui propose une interface web très simple pour controler les connexions et télécharger les fichiers de conf (notamment par QR code pour les téléphones)
|
||||
- [Wireguard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) pour les clients linux
|
||||
|
||||
Il existe aussi des clients Windows, MacOS, iOS et Android.
|
||||
|
||||
Le principe est le suivant :
|
||||
|
||||
- Sur internet, n'importe qui peut contacter n'importe quel box internet et donc essayer de contacter n'importe quel serveur exposé.
|
||||
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le meme réseau que votre serveur et donc etre chez vous. De plus, vous devez laisser ouvert les ports utilisés par vos services à travers le pare feu de votre serveur.
|
||||
- Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de maniere securisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
|
||||
- Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de maniere sécurisée deux instances de Dockge pour tout controler depuis la meme interface.
|
||||
|
||||
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est à dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elle comme dans un réseau local.
|
||||
|
||||
D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyiez.
|
||||
|
||||
|
||||
|
||||
Dans cette illustration, la machine 1 est sur deux réseaux :
|
||||
|
||||
- son réseau local (tous les appareils liés à la box, avec une adresse IP du type `192.168.x.x ` donc ici la machine 1 et la machine 2)
|
||||
- le réseau du VPN (tous les appareils reliés au VPN, avec une seconde adresse IP du type `10.8.x.x` donc ici la machine 1 et 4)
|
||||
|
||||
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les acces à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en terme de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la meme adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
|
||||
|
||||
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elle depuis ce réseau. Elles ne pourront pas dialoguer avec une machine situées sur un autre réseau local et non reliée au VPN.
|
||||
|
||||
## Côté serveur
|
||||
::note
|
||||
📋 __A vérifier au préalable :__
|
||||
|
||||
- Vérifiez si le port `51820 UDP` estlibre sur votre serveur, et bien routé dans le NAT de la box `Source 51820 UDP -> Destination 51820 UDP -> Serveur`. En effet, votre serveur étant derrière votre box, le port de votre box doit etre joignable et rediriger vers le port de votre serveur connecté à votre VPN.
|
||||
- Vérifiez aussi que le port `51821 TCP` est libre sur le serveur pour accéder à la web ui.
|
||||
::
|
||||
|
||||
::warning
|
||||
|
||||
__Attention__: Si votre IP n'est pas fixe, vous devez avoir un nom de domaine redirigeant vers l'IP à jour à l'aide d'un [DynDNS](https://en.wikipedia.org/wiki/Dynamic_DNS). Si votre opérateur internet utilise un [CGNAT](https://en.wikipedia.org/wiki/Carrier-grade_NAT), vous êtes cuit. Vous devrez utiliser un VPS externe pour ce tuto, et y connecter votre serveur comme client.
|
||||
::
|
||||
|
||||
Structure des dossiers
|
||||
|
||||
```text [Arborescence]
|
||||
root
|
||||
└── docker
|
||||
└── wg-easy
|
||||
├── config
|
||||
│ └── etc_wireguard
|
||||
├── compose.yaml
|
||||
└── .env
|
||||
```
|
||||
|
||||
Ouvrez Dockge, cliquez sur `compose` et nommez la stack `wg_easy`.
|
||||
|
||||
Copiez la configuration suivante :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
wg-easy:
|
||||
environment:
|
||||
- INSECURE=true
|
||||
image: ghcr.io/wg-easy/wg-easy:15
|
||||
container_name: wg-easy
|
||||
networks:
|
||||
wg:
|
||||
ipv4_address: 10.42.42.42
|
||||
ipv6_address: fdcc:ad94:bacf:61a3::2a
|
||||
volumes:
|
||||
- ./etc_wireguard:/etc/wireguard
|
||||
- /lib/modules:/lib/modules:ro
|
||||
ports:
|
||||
- "51820:51820/udp"
|
||||
- "51821:51821/tcp"
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- SYS_MODULE
|
||||
sysctls:
|
||||
- net.ipv4.ip_forward=1
|
||||
- net.ipv4.conf.all.src_valid_mark=1
|
||||
- net.ipv6.conf.all.disable_ipv6=0
|
||||
- net.ipv6.conf.all.forwarding=1
|
||||
- net.ipv6.conf.default.forwarding=1
|
||||
|
||||
networks:
|
||||
wg:
|
||||
driver: bridge
|
||||
enable_ipv6: true
|
||||
ipam:
|
||||
driver: default
|
||||
config:
|
||||
- subnet: 10.42.42.0/24
|
||||
- subnet: fdcc:ad94:bacf:61a3::/64
|
||||
|
||||
```
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__
|
||||
|
||||
- Vous pouvez personnaliser le port de wireguard et de la webui au lieu des ports par défaut.
|
||||
- Ajoutez le label de watchtower afin d'automatiser les mises à jour
|
||||
|
||||
```yaml [compose.yaml]
|
||||
services:
|
||||
wg-easy:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
Puis déployez la stack et connectez vous via le web en local sur `http://ipduserveur:51821`
|
||||
|
||||
::caution
|
||||
|
||||
En cas d'échec, vérifiez les règles du pare-feu.
|
||||
::
|
||||
|
||||
Une fois connecté, la webui vous guidera :
|
||||
|
||||
- Pour créer votre compte et mot de passe d'accès
|
||||
- Pour configurer l'host à utiliser dans les fichiers de conf : utilisez l'IP publique de votre box internet (ou de votre VPS), ou le nom de domaine redirigeant vers l'IP de votre box, le cas écheant.
|
||||
|
||||
Une fois fait:
|
||||
|
||||
- Cliquez sur *« Administrator »* > *« Admin Panel »* > *« Config »*
|
||||
- Modifiez `Allowed IPs` en remplaçant `0.0.0.0/24` par `10.8.0.0/24`. Cela signifie que seules les requêtes IP de `10.8.0.1` à `10.8.0.255` seront redirigées dans le tunnel (split tunneling), laissant ainsi à l'appareil la possibilité d'etre connecté à d'autres tunnels, et à accéder à internet par lui meme. Si vous voulez tout rediriger dans le tunnel, y compris l'acces à internet, laissez `0.0.0.0/24`.
|
||||
- Supprimez l'IPv6, cela n'apportera que des problèmes.
|
||||
|
||||
### Recuperation des fichiers de conf
|
||||
|
||||
Afin de configurer les clients, vous devez télécharger les fichiers de conf générés par l'host :
|
||||
|
||||
- Connectez vous via le web en local sur `http://ipduserveur:51821`
|
||||
- Créez un client
|
||||
- Modifiez le client en cliquant sur l'icone d'édition
|
||||
- Modifiez `Server Allowed IPs` en ajoutant `10.8.0.0/24`. Cela signifie que le serveur laissera vos clients accéder à toutes les IP `10.8.0.1` à `10.8.0.255` connectées à lui, et donc laissera les clients dialoguer entre eux si nécessaire. Si vous voulez laisser vos clients accéder à tous les appareils réseau connectés autour de votre serveur en local, mettez `0.0.0.0`, à condition de l'avoir fait précédemment dans la configuration générale.
|
||||
- (facultatif) Si votre client est un serveur qui doit être connecté en permanence, modifiez `Advanced` > `Persistent Keep Alive` en mettant `25`.
|
||||
- Sauvegardez
|
||||
- Téléchargez le fichier de conf
|
||||
- Renommez le en `wg0.conf`. (Si ce n'est pas le premier, incrémentez: `wg1.conf`, etc...)
|
||||
|
||||
## Sur le serveur client
|
||||
---
|
||||
::note
|
||||
|
||||
Nous partons du principe que le serveur client est un serveur linux avec Docker installé
|
||||
::
|
||||
|
||||
Structure des dossiers
|
||||
|
||||
```text [Arborescence]
|
||||
root
|
||||
└── docker
|
||||
└── wireguard
|
||||
└── config
|
||||
│ └── wg_confs
|
||||
└── compose.yaml
|
||||
```
|
||||
|
||||
Creez le dossier `/docker/wireguard/config/wg_confs`.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/fr/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -p /docker/wireguard/config/wg_confs
|
||||
```
|
||||
|
||||
Créez le fichier `wg0.conf`
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/wireguard/config/wg_confs/wg0.conf
|
||||
```
|
||||
|
||||
Copiez-collez le contenu du `wg0.conf` que vous avez téléchargé, puis enregistrez avec :kbd{value="Ctrl+O"} et :kbd{value="Entrée"}, et quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ Un autre moyen est de transférer le fichier par sftp dans le dossier `/home/nomdutilisateur` puis de le copier dans le bon dossier :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo cp ~/wg0.conf /docker/wireguard/config/wg_confs
|
||||
```
|
||||
::
|
||||
|
||||
Creez le `compose.yaml` dans `/docker/wireguard `:
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/wireguard/compose.yaml
|
||||
```
|
||||
Copiez la configuration ci-dessous
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
wireguard:
|
||||
image: lscr.io/linuxserver/wireguard:latest
|
||||
container_name: wireguard
|
||||
network_mode: host
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- SYS_MODULE #optional
|
||||
environment:
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /docker/wireguard/config:/config
|
||||
- /lib/modules:/lib/modules #optional
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Lancez le conteneur :
|
||||
```bash [Terminal]
|
||||
cd /docker/wireguard
|
||||
sudo docker compose up -d
|
||||
```
|
||||
::note
|
||||
|
||||
A répéter pour chaque client
|
||||
::
|
||||
|
||||
## Autres appareils
|
||||
|
||||
- **Téléphone :** installer wireguard et scanner le QR code via le webui (http://ipduserveur:51821)
|
||||
- **PC :** Installer wireguard client et mettre directement le fichier de conf téléchargé via le webui
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ Si des machines clientes sont sur le meme réseau local que le serveur (derriere la box), éditez le fichier `wg0.conf` uploadé sur cette machine en changeant avec l'adresse locale du serveur : `Endpoint = ipduserveur:51820`{lang=properties}
|
||||
::
|
||||
|
||||
Et voilà ce que cela peut donner !
|
||||
|
||||
|
||||
@@ -1,575 +0,0 @@
|
||||
---
|
||||
title: Authentik
|
||||
description: Installer Authentik comme fournisseur d'identité auto-hébergé — configurer le MFA et protéger vos services avec du SSO et l'authentification via reverse proxy.
|
||||
---
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
# Authentik
|
||||
|
||||
::note
|
||||
🎯 __Objectifs :__
|
||||
|
||||
- Installer et exposer Authentik
|
||||
- Paramétrer le Multi-Facteur
|
||||
- Protéger une app native ou via reverse proxy
|
||||
::
|
||||
|
||||
[Authentik](https://goauthentik.io) est un outil d'authentification unique permettant de vous logger une seule fois sur les plateformes compatibles OpenID. Il permet également de sécuriser l'accès aux services que vous exposez, en s'injectant via SWAG aux requetes vers vos services.
|
||||
|
||||
Ainsi, si vous exposez Dockge sur internet via `dockge.mondomaine.fr`, au moment de l'accès à cette page, vous tomberez sur une page de login d'authentik. Si vous avez déjà été identifié sur un autre service sécurisé par authentik auparavant, alors vous serez déjà identifié. cela permet d'avoir à vous identifiez qu'une seule fois par jour sur l'ensemble des services protégés par authentik.
|
||||
|
||||
Authentik permet aussi d'utiliser le multi-facteur, notamment par TOTP (code généré par une application d'authentification de votre choix. Enfin, authentik permet aussi de se connecter directement via un compte Microsoft ou Google, si vous avez configuré une application d'un de ces services.
|
||||
|
||||
C'est une bonne manière de se passer de VPN pour exposer vos services, et d'exposer des services qui ne sont pas protégés par du MFA voir pas protégés par des login (comme le dashboard de swag).
|
||||
|
||||
Authentik dipose d'[une doc très fournie](https://docs.goauthentik.io/docs/installation/docker-compose) et des [fabuleux tuto de Cooptonian](https://www.youtube.com/@cooptonian). Ici, nous montrerons juste les bases, avec l'exemple de l'exposition de Dockge.
|
||||
|
||||
Deux modes principaux sont à connaitre:
|
||||
|
||||
- Le premier permet à une application qui dispose nativement d'une intégration avec du SSO compatible OpenID de se connecter directement à Authentik. C'est la solution à privilégier car elle permet de laisser l'application décider de ce qui est public et de ce qui est protégé.
|
||||
|
||||
|
||||
|
||||
- Le second permet d'injecter une authentification via authentik grace à SWAG avant d'arriver sur le service désiré.
|
||||
|
||||
|
||||
|
||||
Les deux modes son configurables application par application.
|
||||
|
||||
## Installation
|
||||
Structure des dossiers :
|
||||
```text [Arborescence]
|
||||
root
|
||||
└── docker
|
||||
└── authentik
|
||||
├── .env
|
||||
├── compose.yml
|
||||
├── media
|
||||
├── certs
|
||||
├── custom-template
|
||||
└── ssh
|
||||
```
|
||||
|
||||
Créez les dossiers :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -p /docker/authentik/media /docker/authentik/certs /docker/authentik/custom-template /docker/authentik/ssh
|
||||
```
|
||||
|
||||
Positionnez vous dans le dossier `authentik` via `cd /docker/authentik` et générez un mot de passe et une clé secrete que l'on va intégrer dans le .env :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo echo "PG_PASS=$(openssl rand 36 | base64)" >> .env
|
||||
sudo echo "AUTHENTIK_SECRET_KEY=$(openssl rand 60 | base64)" >> .env
|
||||
```
|
||||
::note
|
||||
|
||||
Afin de générer la clé, nous avons créé les dossiers en amont du déploiement via Dockge. Dockge vous empechera de créer une stack du meme nom dans ces dossiers s'il n'existe pas de `compose.yml`. Il faut donc créer un `compose.yml` vide afin que ce dernier la reconnaisse comme existante dans les stacks inactives :
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/authentik/compose.yml
|
||||
```
|
||||
::
|
||||
|
||||
Ouvrez dockge, et cherchez "authentik" dans les stack inactives.
|
||||
Nommez la stack authentik et collez la configuration suivante, en changeant les chiffres de `{AUTHENTIK_TAG:-2026.2}`{lang=properties} par [la dernière version de Authentik](https://goauthentik.io/docs/releases).
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
|
||||
postgresql:
|
||||
image: docker.io/library/postgres:16-alpine
|
||||
container_name: authentik-postgresql
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test:
|
||||
- CMD-SHELL
|
||||
- pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}
|
||||
start_period: 20s
|
||||
interval: 30s
|
||||
retries: 5
|
||||
timeout: 5s
|
||||
volumes:
|
||||
- database:/var/lib/postgresql/data
|
||||
environment:
|
||||
POSTGRES_PASSWORD: ${PG_PASS:?database password required}
|
||||
POSTGRES_USER: ${PG_USER:-authentik}
|
||||
POSTGRES_DB: ${PG_DB:-authentik}
|
||||
env_file:
|
||||
- .env
|
||||
|
||||
redis:
|
||||
image: docker.io/library/redis:alpine
|
||||
container_name: authentik-redis
|
||||
command: --save 60 1 --loglevel warning
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test:
|
||||
- CMD-SHELL
|
||||
- redis-cli ping | grep PONG
|
||||
start_period: 20s
|
||||
interval: 30s
|
||||
retries: 5
|
||||
timeout: 3s
|
||||
volumes:
|
||||
- redis:/data
|
||||
|
||||
server:
|
||||
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.2}
|
||||
container_name: authentik-server
|
||||
restart: unless-stopped
|
||||
command: server
|
||||
environment:
|
||||
AUTHENTIK_REDIS__HOST: redis
|
||||
AUTHENTIK_POSTGRESQL__HOST: postgresql
|
||||
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
|
||||
volumes:
|
||||
- ./media:/media
|
||||
- ./custom-templates:/templates
|
||||
- ./ssh:/authentik/.ssh
|
||||
env_file:
|
||||
- .env
|
||||
ports:
|
||||
- ${COMPOSE_PORT_HTTP:-9000}:9000
|
||||
- ${COMPOSE_PORT_HTTPS:-9443}:9443
|
||||
depends_on:
|
||||
- postgresql
|
||||
- redis
|
||||
|
||||
worker:
|
||||
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.2}
|
||||
container_name: authentik-worker
|
||||
restart: unless-stopped
|
||||
command: worker
|
||||
environment:
|
||||
AUTHENTIK_REDIS__HOST: redis
|
||||
AUTHENTIK_POSTGRESQL__HOST: postgresql
|
||||
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
|
||||
# `user: root` and the docker socket volume are optional.
|
||||
# See more for the docker socket integration here:
|
||||
# https://goauthentik.io/docs/outposts/integrations/docker
|
||||
# Removing `user: root` also prevents the worker from fixing the permissions
|
||||
# on the mounted folders, so when removing this make sure the folders have the correct UID/GID
|
||||
# (1000:1000 by default)
|
||||
user: root
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- ./media:/media
|
||||
- ./certs:/certs
|
||||
- ./custom-templates:/templates
|
||||
- ./ssh:/authentik/.ssh
|
||||
env_file:
|
||||
- .env
|
||||
depends_on:
|
||||
- postgresql
|
||||
- redis
|
||||
|
||||
volumes:
|
||||
database:
|
||||
driver: local
|
||||
redis:
|
||||
driver: local
|
||||
```
|
||||
|
||||
Dans le point `.env`, les variables `PG_PASS` et `AUTHENTIK_SECRET_KEY` sont déjà remplies.
|
||||
Déployez la stack.
|
||||
|
||||
Vous pouvez alors commencer le set-up d'authentik en tappant `http://ipduserveur:9000/if/flow/initial-setup/`.
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ il est conseillé de créer un nouveau compte admin, et de **désactiver** le compte admin de base `akadmin`.
|
||||
::
|
||||
|
||||
## Exposer authentik
|
||||
Pour être utilisable hors de chez vous, vous devez exposer authentik.
|
||||
|
||||
::note
|
||||
📋 __Au préalable :__ <br/><br/>
|
||||
Nous partons du principe quer vous avez créé dans votre [zone DNS](/fr/general/networking/dns) un sous domaine du type `auth.mondomaine.fr` avec pour CNAME `mondomaine.fr` et, [à moins que vous utilisiez Cloudflare Zero Trust](/fr/serveex/security/cloudflare), vous avez déjà redirigé le port `443` de votre box vers le `443` de votre serveur dans [les règles NAT](/fr/general/networking/nat).
|
||||
::
|
||||
|
||||
Ouvrez le fichier `authentik-server.conf`.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/fr/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/authentik-server.conf
|
||||
```
|
||||
|
||||
Vérifiez que dans chaque cas les variables ci-dessous sont correctes :
|
||||
|
||||
```nginx [authentik-server.conf]
|
||||
set $upstream_authentik authentik-server;
|
||||
proxy_pass http://$upstream_authentik:9000;
|
||||
```
|
||||
|
||||
Si ce n'est pas le cas, éditez-les, puis enregistrez avec :kbd{value="Ctrl+O"} et :kbd{value="Entrée"}, et quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Créez le fichier `auth.subdomain.conf`
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/proxy-confs/auth.subdomain.conf
|
||||
|
||||
```
|
||||
|
||||
Collez la configuration suivante :
|
||||
|
||||
```nginx [auth.subdomain.conf]
|
||||
## Version 2023/05/31
|
||||
# make sure that your authentik container is named authentik-server
|
||||
# make sure that your dns has a cname set for authentik
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name auth.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
client_max_body_size 0;
|
||||
|
||||
location / {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app authentik-server;
|
||||
set $upstream_port 9000;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
}
|
||||
|
||||
location ~ (/authentik)?/api {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app authentik-server;
|
||||
set $upstream_port 9000;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Rendez-vous dans dockge, et éditez le compose de SWAG en ajoutant le réseau d'Authentik :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Relie le conteneur au réseau custom
|
||||
# ...
|
||||
- authentik # Nom du réseau déclaré dans la stack
|
||||
|
||||
networks: # Définit le réseau custom
|
||||
# ...
|
||||
authentik: # Nom du réseau déclaré dans la stack
|
||||
name: authentik_default # Nom véritable du réseau externe
|
||||
external: true # Précise que c'est un réseau à rechercher en externe
|
||||
```
|
||||
|
||||
Relancez la stack et patientez le temps que SWAG soit complètement opérationnel.
|
||||
|
||||
Et voilà ! Vous pouvez accéder à authentik via `https://auth.mondomaine.fr`
|
||||
|
||||
## Activer le multifacteur
|
||||
Tout l'intérêt de authentik c'est de disposer du multifacteur pour toutes les apps que l'on protègera.
|
||||
|
||||
- Rendez vous sur `https://auth.mondomaine.fr`
|
||||
- Identifiez-vous
|
||||
- Rendez-vous dans _paramètres_
|
||||
- Cliquez sur la section _MFA_
|
||||
- Cliquez sur _s'inscrire_
|
||||
- Choisissez une méthode comme _TOTP device_ ( dans ce cas vous devrez utilisez une app d'authentification telle que Google Authenticator par exemple)
|
||||
- Suivez les étapes
|
||||
|
||||
Et voilà, vous serez invité à saisir un code à usage unique à chaque connexion.
|
||||
|
||||
## Protéger une app native
|
||||
Authentik est compatible nativement avec un certain nombre d'application, vous retrouverez la liste et [le support ici](https://docs.goauthentik.io/integrations/services/)
|
||||
|
||||
## Protéger une app par reverse proxy
|
||||
Swag permet d'intercaler la page d'authentik entre la requête et l'accès à votre service. Pour cela il va falloir :
|
||||
|
||||
- Configurer le service d'authentification dans authentik.
|
||||
- Configurer le fichier proxy du domaine pour que swag puisse intercaler la page.
|
||||
|
||||
Pourquoi le faire alors que Dockge a déjà une page d'authentification ? Tout simplement parce que l'authentification HTTP utilisée par Dockge est faible. Avec Authentik, vous aurez directement une authentification forte par MFA, et vous serez loggé automatiquement à toutes vos apps déjà protégées par authentik. Cela permet de sécuriser l'accès à Dockge et aux autres apps que vous protégerez, sans avoir à passer par un VPN.
|
||||
|
||||
### Configuration de Authentik
|
||||
|
||||
- Rendez vous dans Authentik
|
||||
- Allez dans le panneau d'administration
|
||||
- Sélectionnez _application_ puis _créer avec l'assistant_
|
||||
- Renseignez les champs comme suit :
|
||||
|
||||
|
||||
|
||||
- Puis à l'étape suivante choisissez "Transférer l'authentification (application unique)" et éditez comme suit (attention aux flow, c'est important) :
|
||||
|
||||
|
||||
|
||||
- Ensuite, allez dans le menu à gauche dans _Avant-poste_ et éditez _authentik Embedded Outpost_
|
||||
|
||||
|
||||
|
||||
- Ajoutez l'application `dockge` en la faisant passer à droite et validez.
|
||||
|
||||
### Configuration de SWAG
|
||||
|
||||
Ensuite rendez-vous dans le fichier `dockge.mondomaine.fr`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/proxy-confs/dockge.subdomain.conf
|
||||
```
|
||||
|
||||
Puis enlevez les `#` des deux lignes `#include /config/nginx/authentik-server.conf;`{lang=nginx}.
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Et voilà ! En tapant `https://dockge.mondomaine.fr`, vous tomberez à présent sur la mire d'authentification de authentik.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ dans Dockge, dans les paramètres, vous pouvez désactiver l'authentification de Dockge afin de ne pas avoir à vous identifier deux fois. **Attention**, cela voudra dire que si vous avez exposé un port sur votre réseau local, il n'y aura plus aucune authentification.
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
Vous pouvez répétez l'opération pour chaque application que vous souhaitez protéger (si elle ne dipose pas d'intégration directe avec Authentik).
|
||||
::
|
||||
|
||||
Voilà votre nouvelle architecture :
|
||||
|
||||
|
||||
|
||||
## Protéger un service sur un serveur distant
|
||||
Dans le cas d'une application [native](/fr/serveex/security/authentik#protéger-une-app-native) (via OAuth 2.0 ou autre), rien ne change.
|
||||
|
||||
Dans le cas d'une application non native à protéger derrière un reverse proxy, vous devrez déployer un __avant-poste__. Un avant-poste est un conteneur qui jouera le rôle de proxy local, c'est à dire que c'est vers ce conteneur que les requêtes d'authentification de vos applications seront redirigées. C'est le seul qui est autorisé à dialoguer avec l'API de votre instance authentik.
|
||||
|
||||
::note
|
||||
Pré-requis :
|
||||
|
||||
- Avoir installé [docker](/fr/serveex/core/docker) sur votre machine distante hébergeant le service à protéger.
|
||||
- Si l'application n'a pas d'intégration native, avoir un reverse proxy compatible. Comme partout ici, nous utiliserons [SWAG](/fr/serveex/core/swag).
|
||||
::
|
||||
|
||||
Ce conteneur redirigera ensuite les requetes vers votre instance [Authentik](/fr/serveex/security/authentik#authentik) principale, à travers le web (ou votre réseau local). Le serveur executera les controle et renverra la réponse à l'_avant-poste_, qui bloquera ou non la connexion à l'app protégée.
|
||||
|
||||
|
||||
|
||||
### Configuration d'Authentik
|
||||
|
||||
Créez vos [fournisseurs et applications](/fr/serveex/security/authentik#protéger-une-app-native) comme nous l'avons vu plus haut.
|
||||
|
||||
Puis, dans votre panneau admin, allez dans la rubrique _Applications > Avant-postes_, puis créez un nouvel avant-poste.
|
||||
|
||||
Remplissez comme suit :
|
||||
|
||||
| Champs | Valeur |
|
||||
|----------------|-----------------------------------------------------------------------|
|
||||
| `Nom` | Le nom que vous souhaitez |
|
||||
| `Type` | `Proxy` |
|
||||
| `Intégration` | Laissez vide |
|
||||
| `Applications` | Sélectionnez le ou les applications que vous avez créées précédemment |
|
||||
|
||||
Dans la section `Paramètres avancés`, supprimez l'existant, et complétez comme suit :
|
||||
|
||||
```yaml
|
||||
log_level: info
|
||||
docker_labels: null
|
||||
authentik_host: https://domaine_de_votre_serveur_authentik/
|
||||
object_naming_template: ak-outpost-%(name)s
|
||||
authentik_host_insecure: false
|
||||
container_image:
|
||||
docker_network: null
|
||||
docker_map_ports: true
|
||||
docker_labels: null
|
||||
```
|
||||
|
||||
Enrtegistrez et quittez.
|
||||
|
||||
Sur l'écran affichant les avant-postes créés, vous verrez le nouvel avant-poste que vous venez de créer. A la fin de la ligne, cliquez sur _afficher les informations_, et copiez précieusement le jeton d'accès.
|
||||
|
||||
### Configuration de la machine distante
|
||||
|
||||
Nous partons du principe que vous avez déjà installé [Docker](/fr/serveex/core/docker) et [SWAG](/fr/serveex/core/swag) sur cette machine distante.
|
||||
|
||||
Sur votre machine distante, à l'aide de [Dockge](/fr/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs), créez une stack `authentik-outpost`.
|
||||
|
||||
Si vous n'avez pas installé [Dockge](/fr/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs), créez un dossier `/docker/authentik-outpost`, ou directement en ligne de commande :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -P /docker/authentik-outpost
|
||||
```
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/fr/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
Créez le fichier `compose.yaml` ou copiez la configuration directement dans le champs si vous avez [Dockge](/fr/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs)
|
||||
|
||||
En ligne de commande :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/authentik-outpost/compose.yaml
|
||||
```
|
||||
Collez la configuration suivante, en changeant les chiffres de `{AUTHENTIK_TAG:proxy:2024.2.3}`{lang=properties} par la meme version que celle de votre serveur Authentik.
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
version: "3.5"
|
||||
services:
|
||||
authentik_proxy:
|
||||
container_name: authentik-outpost
|
||||
image: ghcr.io/goauthentik/proxy:2024.2.3
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
restart: unless-stopped
|
||||
env_file:
|
||||
- .env
|
||||
# - foo
|
||||
ports:
|
||||
- 9000:9000
|
||||
- 9443:9443
|
||||
environment:
|
||||
AUTHENTIK_HOST: ${HOST}
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: ${TOKEN}
|
||||
# Starting with 2021.9, you can optionally set this too
|
||||
# when authentik_host for internal communication doesn't match the public URL
|
||||
# AUTHENTIK_HOST_BROWSER: https://external-domain.tld
|
||||
```
|
||||
|
||||
Rendez-vous sur la stack de SWAG de la machine distante (ou remplissez directement si vous avez [Dockge](/fr/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs)) et ajoutez le réseau de authentik-outpost dans le fichier de conf sur ce modele (les champs `networks`) :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/compose.yaml
|
||||
```
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
swag:
|
||||
container_name: #...
|
||||
# ...
|
||||
networks: # Relie le conteneur au réseau custom
|
||||
|
||||
- authentik-outpost # Nom du réseau déclaré dans la stack
|
||||
|
||||
networks: # Définit le réseau custom
|
||||
#...
|
||||
authentik-outpost: # Nom du réseau déclaré dans la stack
|
||||
name: authentik-outpost_default # Nom véritable du réseau externe
|
||||
external: true # Précise que c'est un réseau à rechercher en externe
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
::note
|
||||
|
||||
Ici nous partons du principe que le nom du réseau de dockge est `authentik-outpost_default`.
|
||||
::
|
||||
|
||||
Si vous avez [Dockge](/fr/serveex/core/docker#installer-dockge-pour-g"rer-et-d"ployer-les-conteneurs), relancez SWAG.
|
||||
|
||||
Sinon, via le terminal :
|
||||
|
||||
```bash [Terminal]
|
||||
cd /docker/swag/
|
||||
sudo docker compose up -d
|
||||
```
|
||||
|
||||
Creez (ou remplissez directement si vous avez [Dockge](/fr/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs)) le fichier `.env` dans le dossier de l'avant poste authentik :
|
||||
|
||||
En ligne de commande :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/authentik-outpost/.env
|
||||
```
|
||||
|
||||
Collez la configuration suivante
|
||||
|
||||
```properties [.env]
|
||||
HOST=
|
||||
TOKEN=
|
||||
```
|
||||
Remplissez comme suit
|
||||
|
||||
| Variable | Valeur | Exemple |
|
||||
|-------------------------|---------------------------------------------------------|----------------------------|
|
||||
| `HOST`{lang=properties} | L'url de votre serveur authentik | `https://auth.domaine.fr` |
|
||||
| `TOKEN`{lang=properties} | Le token que vous avez précédemment copié précieusement | `Q2pVEqsTNRkJSO9SkJzU3KZ2` |
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Si vous avez [Dockge](/fr/serveex/core/docker#installer-dockge-pour-g"rer-et-d"ployer-les-conteneurs), déployez la stack.
|
||||
|
||||
Sinon, via le terminal :
|
||||
|
||||
```bash [Terminal]
|
||||
cd /docker/authentik-outpost/
|
||||
sudo docker compose up -d
|
||||
```
|
||||
|
||||
Le conteneur est en route, vous pouvez vérifier son état dans votre panneau admin de votre instance Authentik, section _Applications > Avant-postes_.
|
||||
|
||||
Nous allons a présent configurer SWAG.
|
||||
|
||||
Ouvrez le fichier `authentik-server.conf`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/authentik-server.conf
|
||||
```
|
||||
|
||||
Dans le fichier, changez `authentik-server` par `authentik-outpost` comme suit :
|
||||
|
||||
```nginx [authentik-server.conf]
|
||||
set $upstream_authentik authentik-outpost;
|
||||
proxy_pass http://$upstream_authentik:9000;
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Ensuite, configurez les applications à protéger selon si elles sont [natives](/fr/serveex/security/authentik#protéger-une-app-native) ou par [proxy](/fr/serveex/security/authentik#protéger-une-app-par-reverse-proxy) comme vous l'avez fait sur votre serveur principal.
|
||||
|
||||
## Migrer une base authentik
|
||||
Sur la machine d'origine, dumper la bdd :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker exec authentik-postgres pg_dump -U authentik -F t authentik > /path/to/mydb.tar
|
||||
```
|
||||
|
||||
Puis l'envoyer sur la machine cible. Sur la machine cible, copier le fichier dans le container docker
|
||||
|
||||
```bash [Terminal]
|
||||
cp /path/to/mydb.tar authentik-postgres:/path/to/wherever
|
||||
```
|
||||
|
||||
(Optionnel) Purgez les tables existantes :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'authentik' AND pid <> pg_backend_pid();" && \
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "DROP DATABASE IF EXISTS authentik;" && \
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "CREATE DATABASE authentik;" && \
|
||||
```
|
||||
|
||||
Restaurez la bdd
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker exec authentik-postgresql pg_restore -U authentik -d authentik /path/to/wherever/mydb.tar
|
||||
```
|
||||
+58
-59
@@ -1,26 +1,16 @@
|
||||
---
|
||||
title: Cloudflare Zero Trust
|
||||
description: Utiliser les tunnels Cloudflare et Zero Trust pour exposer des services sans ouvrir de ports — configurer SWAG et gérer plusieurs tunnels.
|
||||
description: Utiliser les tunnels Cloudflare et Zero Trust pour exposer des services sans ouvrir de ports, configurer SWAG et gérer plusieurs tunnels.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
# Cloudflare Zero Trust
|
||||
|
||||
::note
|
||||
🎯 __Objectifs :__
|
||||
|
||||
- Comprendre le principe des Tunnels Cloudflare
|
||||
- Paramétrer son compte cloudflare
|
||||
- Paramétrer SWAG
|
||||
- Gérer plusieurs tunnels
|
||||
::
|
||||
|
||||
|
||||
|
||||
## Introduction
|
||||
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaires récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur l’application du _Zero Trust_ aux services Web que nous hébergeons.
|
||||
|
||||
Les _tunnels Cloudflare_ offrent un moyen simple d'arriver au _Zero Trust_, en s'appuyant sur [SWAG](/fr/serveex/core/swag) et [Authentik](/fr/serveex/security/authentik).
|
||||
Les _tunnels Cloudflare_ offrent un moyen simple d'arriver au _Zero Trust_, en s'appuyant sur [SWAG](/serveex/core/swag) et [Authentik](/serveex/advanced/authentik).
|
||||
|
||||
Pour le dire simplement, les Tunnels Cloudflare permettent notamment de :
|
||||
|
||||
@@ -33,23 +23,22 @@ Pour le dire simplement, les Tunnels Cloudflare permettent notamment de :
|
||||
Ici, nous expliquerons comment associer SWAG aux tunnels Cloudflare.
|
||||
|
||||
::warning
|
||||
|
||||
- __Attention :__
|
||||
__Attention :__
|
||||
- N'utilisez pas les tunnels Cloudflare pour exposer un serveur mail
|
||||
- N'utilisez pas les tunnels Cloudflare pour exposer un service vidéo, comme Plex (si vous avez [suivi ce guide](/fr/serveex/media/plex), Plex n'est pas exposé, c'est donc valide)
|
||||
- N'utilisez pas les tunnels Cloudflare pour utiliser le protocole bittorrent (si vous avez [suivi ce guide](/fr/serveex/media/qbittorrent), tout est bon)
|
||||
- N'utilisez pas les tunnels Cloudflare pour exposer un service vidéo comme Jellyfin. Contrairement à Plex, [Jellyfin n'a pas de relais cloud](/serveex/media/jellyfin) et est exposé directement par SWAG dans ce guide, veillez donc à le laisser derrière une simple redirection de port plutôt que derrière un tunnel Cloudflare
|
||||
- N'utilisez pas les tunnels Cloudflare pour le protocole BitTorrent (si vous avez [suivi ce guide](/serveex/media/qbittorrent), tout est bon)
|
||||
::
|
||||
|
||||
## Configuration Cloudflare
|
||||
### Zone DNS
|
||||
|
||||
Avant toute chose, vous devez définir Cloudflare comme gestionnaire de votre [zone DNS](/fr/general/networking/dns). Si vous avez réservé votre nom de domaine chez Cloudflare, c'est déjà le cas. Sinon, renseignez vous auprès de votre registrar sur comment ajouter des DNS externes. Cloudflare dispose d'[une documentation expliquant pas à pas comment paramétrer une Zone DNS](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/), que vous ayez un domaine externe ou reservé chez Cloudflare.
|
||||
Avant toute chose, vous devez définir Cloudflare comme gestionnaire de votre [zone DNS](/general/networking/dns). Si vous avez réservé votre nom de domaine chez Cloudflare, c'est déjà le cas. Sinon, renseignez vous auprès de votre registrar sur comment ajouter des DNS externes. Cloudflare dispose d'[une documentation expliquant pas à pas comment paramétrer une Zone DNS](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/), que vous ayez un domaine externe ou reservé chez Cloudflare.
|
||||
|
||||
Si vous avez qu'un seul serveur à protéger derrière Cloudflare, vous pouvez supprimer l'ensemble des enregistrement DNS existant, par défaut le domaine et tout ses sous-domaines seront directement redirigés vers le tunnel.
|
||||
|
||||
Si vous avez des sous-domaines à rediriger vers d'autres serveurs, vous pourrez toujours les déclarer dans la zone DNS à l'aide d'un enregistrement A.
|
||||
|
||||
Si vous avez plusieurs serveurs et donc plusieurs tunnels pour un meme domaine principal, [voyez ici](http://192.168.7.80:8005/serveex/cloudflare/#gerer-plusieurs-tunnels-pour-plusieurs-serveurs).
|
||||
Si vous avez plusieurs serveurs et donc plusieurs tunnels pour un meme domaine principal, [voyez ici](#gérer-plusieurs-tunnels-pour-plusieurs-serveurs).
|
||||
|
||||
### Clé API
|
||||
|
||||
@@ -84,16 +73,17 @@ SWAG dispose de deux `Docker Mods` permettant d'y intégrer :
|
||||
|
||||
Ces deux mods, fusionnés dans le conteneur de SWAG, nécessitent un peu de configuration.
|
||||
|
||||
::steps{level="3"}
|
||||
### Configuration du tunnel
|
||||
|
||||
Pour configurer les tunnels, nous aurons besoin de créer un fichier `tunnelconfig.yml` auquel nous ferons appel dans le `compose.yaml` de SWAG.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vous pouvez utiliser [File Browser](/fr/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/tunnelconfig.yml
|
||||
sudo nano /srv/docker/swag/config/tunnelconfig.yml
|
||||
```
|
||||
|
||||
Collez la configuration ci-dessous
|
||||
@@ -118,9 +108,10 @@ A présent, nous allons configurer le bon fonctionnement du mode _Cloudflare Rea
|
||||
Ouvrez le fichier `nginx.conf`
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/nginx.conf
|
||||
sudo nano /srv/docker/swag/config/nginx/nginx.conf
|
||||
```
|
||||
Collez la configuration ci-dessous à la fin de la section `http`
|
||||
|
||||
Collez la configuration ci-dessous à la fin de la section `http` :
|
||||
|
||||
```nginx [nginx.conf]
|
||||
real_ip_header X-Forwarded-For;
|
||||
@@ -128,9 +119,10 @@ real_ip_recursive on;
|
||||
include /config/nginx/cf_real-ip.conf;
|
||||
set_real_ip_from 127.0.0.1;
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
### Docker compose
|
||||
### Déployer la stack SWAG
|
||||
|
||||
Ouvrez Dockge, éditez la stack SWAG avec cette configuration
|
||||
|
||||
@@ -165,25 +157,22 @@ services:
|
||||
ports:
|
||||
- 81:81
|
||||
volumes:
|
||||
- /docker/swag/config:/config
|
||||
- /docker/swag/config/fail2ban/fail2ban.sqlite3:/dashboard/fail2ban.sqlite3:ro
|
||||
- /srv/docker/swag/config:/config
|
||||
- /srv/docker/swag/config/fail2ban/fail2ban.sqlite3:/dashboard/fail2ban.sqlite3:ro
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ ajoutez le label de watchtower dans chaque conteneur afin d'automatiser les mises à jour
|
||||
✨ __Astuce :__ ajoutez un label Watchtower pour automatiser les mises à jour :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
services:
|
||||
swag:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
Et renseignez le `.env` les infos que vous avez trouvées et notées tout au long de ce guide
|
||||
Renseignez votre fichier `.env` :
|
||||
|
||||
```properties [.env]
|
||||
PUID=
|
||||
@@ -213,48 +202,58 @@ TUNNEL_PW=
|
||||
|
||||
Une fois fait, déployez la stack. Cela prendra un peu de temps, vérifiez les logs, vous devriez arriver à `serveur ready`
|
||||
|
||||
Une fois le conteneur en ligne, vérifiez dans cloudflare que votre tunnel est bien présent dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). Par défaut, l'ensemble des sous domaine sont redirigés vers le tunnel, sans avoir besoin de les déclarer [dans votre zone DNS](/fr/general/networking/dns).
|
||||
Une fois le conteneur en ligne, vérifiez dans cloudflare que votre tunnel est bien présent dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). Par défaut, l'ensemble des sous domaine sont redirigés vers le tunnel, sans avoir besoin de les déclarer [dans votre zone DNS](/general/networking/dns).
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce:__ si vous voulez exposer un service sans tunnel, vous pouvez toujours déclarer un enregistrement A [dans votre zone DNS](/fr/general/networking/dns). En cas de problème de résolution, désactivez la fonction _proxy_ pour cet enregistrement. Par exemple pour `sous.mondomaine.fr`
|
||||
::tip{icon="" to="/general/networking/dns"}
|
||||
✨ __Astuce :__ si vous voulez exposer un service sans tunnel, déclarez simplement un enregistrement A **dans votre zone DNS**. En cas de problème de résolution, désactivez la fonction _proxy_ pour cet enregistrement, par exemple pour `sous.mondomaine.fr`.
|
||||
|
||||
::
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Gérer plusieurs tunnels pour plusieurs serveurs
|
||||
Par défaut, l'ensemble des sous domaine de votre nom de domaine pointent vers le tunnel que vous avez créé. Mais si vous avez un second serveur, vous pouvez avoir un second tunnel en changeant seulement le nom de tunnel dans la configuration de l'instance swag de votre serveur.
|
||||
Par défaut, l'ensemble des sous-domaines de votre domaine passent par l'unique tunnel. Mais si vous avez un second serveur, il suffit de changer le nom du tunnel dans cette instance de SWAG, puis de rediriger les sous-domaines vers le bon tunnel dans votre zone DNS.
|
||||
|
||||
Vous devrez ensuite dans votre zone DNS rediriger les sous domaine souhaité vers le bon tunnel. Pour cela, faites comme suit.
|
||||
::steps{level="3"}
|
||||
### Changer le nom du tunnel
|
||||
|
||||
Rendez-vous dans dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/).
|
||||
Dans la stack SWAG du second serveur, mettez un `TUNNEL_NAME` différent dans le fichier `.env`, puis redéployez.
|
||||
|
||||
Notez les deux ID des tunnels
|
||||
### Trouver les ID des tunnels
|
||||
|
||||
Rendez-vous dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/) et notez les ID des tunnels :
|
||||
|
||||
|
||||
|
||||
Rendez-vous à présent dans la section DNS de [cloudflare](https://dash.cloudflare.com/), après avoir cliqué sur le nom de domaine concerné.
|
||||
### Ajouter les enregistrements CNAME
|
||||
|
||||
Cliquez sur `ajouter un enregistrement` et ajoutez deux enregistrements comme suit en ajoutant bien `.cfargotunnel.com` après vos id de tunnels.
|
||||
Dans le [tableau de bord DNS de Cloudflare](https://dash.cloudflare.com/), cliquez sur votre nom de domaine, puis sur `Ajouter un enregistrement` et ajoutez ces deux enregistrements CNAME (en incluant bien `.cfargotunnel.com`) :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sousdomaine1` | `votreiddetunnel1.cfargotunnel.com` |
|
||||
| `CNAME` | `sousdomaine2` | `votreiddetunnel2.cfargotunnel.com` |
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Si vous avez de nombreux sous-domaines, vous pouvez déclarer un seul sous domaine par tunnel comme ci-dessus, puis déclarer vos autres sous domaine en les faisant pointer vers ces sous domaines de référence.
|
||||
|
||||
Ainsi, en cas de changement d'id de tunnel, vous n'aurez qu'à le changer que pour un seul sous-domaine.
|
||||
Ainsi, en cas de changement d'ID de tunnel, vous n'aurez qu'un seul enregistrement DNS à modifier.
|
||||
|
||||
Par exemple :
|
||||
|
||||
- Le serveur de `sousdomaine1` doit egalement etre la cible de sub1, et sub2 :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sub1` | `sousdomaine1` |
|
||||
| `CNAME` | `sub2` | `sousdomaine1` |
|
||||
|
||||
- Le serveur de `sousdomaine2` doit egalement etre la cible de sub3, et sub4 :
|
||||
- `sub1` et `sub2` pointent eux aussi vers le serveur derrière `sousdomaine1` :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sub3` | `sousdomaine2` |
|
||||
| `CNAME` | `sub4` | `sousdomaine2` |
|
||||
| Type | Nom | Cible |
|
||||
|---------|--------|----------------|
|
||||
| `CNAME` | `sub1` | `sousdomaine1` |
|
||||
| `CNAME` | `sub2` | `sousdomaine1` |
|
||||
|
||||
- `sub3` et `sub4` pointent vers le serveur derrière `sousdomaine2` :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|--------|----------------|
|
||||
| `CNAME` | `sub3` | `sousdomaine2` |
|
||||
| `CNAME` | `sub4` | `sousdomaine2` |
|
||||
@@ -0,0 +1,353 @@
|
||||
---
|
||||
title: TinyAuth
|
||||
description: Installer TinyAuth, un proxy de forward-auth léger, et l'associer à Pocket ID pour ajouter une connexion SSO devant vos applications auto-hébergées. Protéger votre application derrière Swag avec le forward-auth.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[TinyAuth](https://tinyauth.app) est un petit proxy de forward-auth : une unique page de connexion que Swag peut insérer devant n'importe quelle application avant de laisser passer une requête, en vérifiant si le visiteur est authentifié avant de le rediriger.
|
||||
|
||||
|
||||
|
||||
Il gère nativement une simple connexion locale identifiant/mot de passe, c'est ce que nous mettrons en place ici. Il peut aussi déléguer la connexion à un fournisseur OIDC externe comme [Pocket ID](/serveex/security/pocket-id), de sorte que quiconque visite une application protégée s'authentifie avec une passkey via Pocket ID puis est redirigé : installez Pocket ID ensuite et suivez [son tutoriel](/serveex/security/pocket-id#connecting-pocket-id-to-tinyauth) pour relier les deux.
|
||||
|
||||
- [Documentation de TinyAuth](https://tinyauth.app/docs)
|
||||
- [TinyAuth sur GitHub](https://github.com/tinyauthapp/tinyauth)
|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
---
|
||||
tree:
|
||||
/:
|
||||
- srv:
|
||||
- docker:
|
||||
- tinyauth:
|
||||
- compose.yaml
|
||||
- .env
|
||||
- data/
|
||||
---
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Créer le dossier de données
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -p /srv/docker/tinyauth/data
|
||||
```
|
||||
|
||||
### Générer un hash de mot de passe
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --interactive
|
||||
```
|
||||
|
||||
::note
|
||||
|
||||
Activez « Format for Docker » quand la question est posée, ainsi le hash généré est déjà échappé pour être utilisé dans un fichier `.env`.
|
||||
::
|
||||
|
||||
### Déployer la stack
|
||||
|
||||
Ouvrez Dockge, cliquez sur `compose`, nommez la stack `tinyauth`, et ajoutez la configuration suivante :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
tinyauth:
|
||||
image: ghcr.io/tinyauthapp/tinyauth:v5
|
||||
container_name: tinyauth
|
||||
restart: unless-stopped
|
||||
env_file:
|
||||
- .env
|
||||
volumes:
|
||||
- /srv/docker/tinyauth/data:/data
|
||||
ports:
|
||||
- 3000:3000
|
||||
```
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Ajoutez le label Watchtower pour automatiser les mises à jour :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
tinyauth:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
### Renseigner vos variables d'environnement
|
||||
|
||||
Remplissez le fichier `.env` :
|
||||
|
||||
```properties [.env]
|
||||
TINYAUTH_APPURL=https://tinyauth.mondomaine.fr
|
||||
TINYAUTH_AUTH_USERS=
|
||||
```
|
||||
|
||||
| Variable | Valeur | Exemple |
|
||||
|----------|-------|---------|
|
||||
| `TINYAUTH_APPURL`{lang=properties} | L'URL publique par laquelle vous joindrez TinyAuth (voir l'exposition plus bas) | `https://tinyauth.mondomaine.fr` |
|
||||
| `TINYAUTH_AUTH_USERS`{lang=properties} | Le hash généré ci-dessus | `user:$$2a$$10$$UdLYoJ5lgPsC0RKq...` |
|
||||
|
||||
Déployez la stack. L'interface locale est disponible sur `http://ipdevotreserveur:3000`.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Activer l'authentification à deux facteurs
|
||||
TinyAuth peut exiger un code TOTP issu d'une application d'authentification (Google Authenticator, Aegis...) en plus du mot de passe local, utilisateur par utilisateur. C'est une propriété de l'entrée utilisateur elle-même, pas une option de l'interface web.
|
||||
|
||||
::steps{level="3"}
|
||||
### Générer un secret TOTP
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 totp generate --interactive
|
||||
```
|
||||
|
||||
Saisissez la paire `username:hash` générée lors de l'installation. TinyAuth affiche un QR code à scanner avec votre application d'authentification, puis produit la chaîne de connexion mise à jour sous la forme `username:hash:secret`.
|
||||
|
||||
::note
|
||||
|
||||
`docker run` comme `docker exec` ont besoin des options `-it` ici : la commande est interactive et affiche le QR code dans le terminal, ce qui nécessite un TTY (et une fenêtre assez large) pour s'afficher correctement.
|
||||
::
|
||||
|
||||
### Mettre à jour votre variable d'environnement
|
||||
|
||||
Remplacez l'entrée de cet utilisateur dans `TINYAUTH_AUTH_USERS` par la nouvelle chaîne `username:hash:secret`, puis redéployez la stack.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vérifiez que tout fonctionne avant de compter dessus :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user verify --interactive
|
||||
```
|
||||
|
||||
Elle redemande l'identifiant, le mot de passe et le code à 6 chiffres du moment.
|
||||
::
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
À partir de maintenant, cet utilisateur a besoin à la fois de son mot de passe et d'un code valide de son application d'authentification pour se connecter.
|
||||
|
||||
## Exposer TinyAuth avec Swag
|
||||
TinyAuth a besoin de son propre sous-domaine : c'est la page sur laquelle les utilisateurs arrivent avant d'être redirigés vers l'application qu'ils veulent réellement.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons du principe que vous avez le sous-domaine `tinyauth.mondomaine.fr` avec un `CNAME` pointant vers `mondomaine.fr` dans votre [zone DNS](/general/networking/dns). Et bien sûr, [à moins d'utiliser Cloudflare Zero Trust](/serveex/security/cloudflare), le port `443` de votre box doit être redirigé vers le port `443` de votre serveur dans les [règles NAT](/general/networking/nat).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Ajouter le réseau de TinyAuth à SWAG
|
||||
|
||||
Allez dans Dockge et modifiez le fichier compose de SWAG en y ajoutant le réseau de TinyAuth :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Rattache le conteneur au réseau personnalisé
|
||||
# ...
|
||||
- tinyauth # Nom du réseau déclaré
|
||||
|
||||
networks: # Définit le réseau personnalisé
|
||||
# ...
|
||||
tinyauth: # Nom du réseau déclaré
|
||||
name: tinyauth_default # Nom réel du réseau externe
|
||||
external: true # Le marque comme défini à l'extérieur
|
||||
```
|
||||
|
||||
Redéployez la stack et attendez que SWAG soit pleinement opérationnel.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons ici du principe que le nom du réseau de TinyAuth est `tinyauth_default`. Vous pouvez vérifier la connexion en visitant le tableau de bord de SWAG sur `http://ipdevotreserveur:81`.
|
||||
::
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `tinyauth.subdomain.conf` :
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier les fichiers plutôt que des commandes dans le terminal.
|
||||
::
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/tinyauth.subdomain.conf
|
||||
```
|
||||
|
||||
Collez la configuration suivante :
|
||||
|
||||
```nginx [tinyauth.subdomain.conf]
|
||||
## Version 2023/12/19
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name tinyauth.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
client_max_body_size 0;
|
||||
|
||||
location / {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app tinyauth;
|
||||
set $upstream_port 3000;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et :kbd{value="Ctrl+X"} pour quitter.
|
||||
|
||||
### Visiter votre nouveau sous-domaine
|
||||
|
||||
Attendez quelques minutes, puis ouvrez `https://tinyauth.mondomaine.fr` dans votre navigateur et connectez-vous avec l'identifiant et le mot de passe créés plus haut.
|
||||
|
||||
::caution
|
||||
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Protéger une application via le reverse proxy
|
||||
Swag ne fournit pas de fichier d'inclusion tout prêt pour TinyAuth, nous ajouterons donc la vérification forward-auth directement dans le `*.subdomain.conf` de l'application. Nous prendrons Dockge en exemple.
|
||||
|
||||
::steps{level="3"}
|
||||
### Ouvrir le fichier subdomain.conf de l'application
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/dockge.subdomain.conf
|
||||
```
|
||||
|
||||
### Ajouter la vérification forward-auth
|
||||
|
||||
Ajoutez un bloc `location /tinyauth` interne, et référencez-le depuis le bloc `location /` de l'application avec `auth_request` :
|
||||
|
||||
```nginx [dockge.subdomain.conf]{9-11,25}
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name dockge.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
client_max_body_size 0;
|
||||
|
||||
location /tinyauth {
|
||||
internal;
|
||||
proxy_pass http://tinyauth:3000/api/auth/nginx;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
proxy_set_header X-Forwarded-Uri $request_uri;
|
||||
}
|
||||
|
||||
location @tinyauth_login {
|
||||
return 302 https://tinyauth.mondomaine.fr/login?redirect_uri=$scheme://$http_host$request_uri;
|
||||
}
|
||||
|
||||
location / {
|
||||
auth_request /tinyauth;
|
||||
error_page 401 = @tinyauth_login;
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app dockge;
|
||||
set $upstream_port 5001;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et :kbd{value="Ctrl+X"} pour quitter.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Et voilà ! Visiter `https://dockge.mondomaine.fr` redirige désormais d'abord vers TinyAuth. Répétez ce motif `location /tinyauth` / `auth_request` dans le `*.subdomain.conf` de n'importe quelle autre application pour la protéger de la même façon.
|
||||
|
||||
::note
|
||||
|
||||
Répétez cette procédure pour chaque application que vous voulez protéger (sauf si elle gère nativement OIDC, auquel cas vous pouvez la pointer directement sur Pocket ID).
|
||||
::
|
||||
|
||||
## Laisser certains chemins publics
|
||||
Il arrive qu'on veuille verrouiller l'essentiel d'une application derrière TinyAuth, mais laisser une poignée de chemins ouverts, par exemple une page de statut publique, ou les endpoints d'API sur lesquels une application mobile s'appuie. Contrairement à Authentik, TinyAuth n'a pas de réglage intégré de « chemins authentifiés » pour ça : c'est un simple problème nginx, et il se résout avec le système de correspondance de `location` de nginx.
|
||||
|
||||
Un bloc `location` en expression régulière est toujours prioritaire sur le bloc `location /` simple, quel que soit celui qui apparaît en premier dans le fichier. Tout chemin correspondant à une location en regex que vous définissez exécute donc son propre `proxy_pass`, sans jamais atteindre la ligne `auth_request /tinyauth;` du `location /`.
|
||||
|
||||
Par exemple, pour laisser ouverte la page de statut publique d'Uptime-Kuma et ses ressources tout en protégeant le reste :
|
||||
|
||||
```nginx [dockge.subdomain.conf]{9-16}
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name stats.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
set $upstream_port 3001;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
|
||||
location /tinyauth {
|
||||
internal;
|
||||
proxy_pass http://tinyauth:3000/api/auth/nginx;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
proxy_set_header X-Forwarded-Uri $request_uri;
|
||||
}
|
||||
|
||||
location @tinyauth_login {
|
||||
return 302 https://tinyauth.mondomaine.fr/login?redirect_uri=$scheme://$http_host$request_uri;
|
||||
}
|
||||
|
||||
location / {
|
||||
auth_request /tinyauth;
|
||||
error_page 401 = @tinyauth_login;
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
set $upstream_port 3001;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::note
|
||||
|
||||
Adaptez la liste des chemins exclus à ce dont l'application que vous protégez a réellement besoin en public. Ne laissez jamais un chemin d'administration ou de réglages dans cette liste, uniquement ce que l'application elle-même documente comme sûr à exposer sans authentification.
|
||||
::
|
||||
@@ -0,0 +1,282 @@
|
||||
---
|
||||
title: Pocket ID
|
||||
description: Installer Pocket ID, un fournisseur OIDC auto-hébergé et léger qui permet de se connecter à vos autres applications avec une passkey plutôt qu'un mot de passe.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[Pocket ID](https://pocket-id.org) est un fournisseur OIDC (OpenID Connect) minimaliste et auto-hébergé, entièrement construit autour des passkeys : au lieu de gérer des mots de passe, vous et vos utilisateurs vous connectez aux applications compatibles avec une **passkey** (empreinte digitale, reconnaissance faciale, ou clé de sécurité matérielle). Il tourne dans un unique conteneur léger, sans base de données externe à gérer, et fait une seule chose, bien : délivrer des connexions OIDC.
|
||||
|
||||
|
||||
|
||||
C'est donc un bon choix si vous voulez simplement un backend SSO simple et rapide, par exemple pour l'associer à [TinyAuth](/serveex/security/tinyauth) en tant que forward-auth léger, ou pour vous connecter directement aux applications qui gèrent nativement OIDC.
|
||||
|
||||
- [Documentation de Pocket ID](https://pocket-id.org/docs)
|
||||
- [Pocket ID sur GitHub](https://github.com/pocket-id/pocket-id)
|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
---
|
||||
tree:
|
||||
/:
|
||||
- srv:
|
||||
- docker:
|
||||
- pocket-id:
|
||||
- compose.yaml
|
||||
- .env
|
||||
- data/
|
||||
---
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Créer le dossier de données
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -p /srv/docker/pocket-id/data
|
||||
```
|
||||
|
||||
### Générer une clé de chiffrement
|
||||
|
||||
```bash [Terminal]
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
Gardez le résultat, vous en aurez besoin pour le fichier `.env` ci-dessous.
|
||||
|
||||
### Déployer la stack
|
||||
|
||||
Ouvrez Dockge, cliquez sur `compose`, nommez la stack `pocket-id`, et ajoutez la configuration suivante :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
pocket-id:
|
||||
image: pocketid/pocket-id:v2
|
||||
container_name: pocket-id
|
||||
restart: unless-stopped
|
||||
env_file:
|
||||
- .env
|
||||
volumes:
|
||||
- /srv/docker/pocket-id/data:/app/data
|
||||
ports:
|
||||
- 1411:1411
|
||||
healthcheck:
|
||||
test: ["CMD", "curl", "-f", "http://localhost:1411/healthz"]
|
||||
interval: 90s
|
||||
timeout: 5s
|
||||
retries: 3
|
||||
```
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Ajoutez le label Watchtower pour automatiser les mises à jour :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
pocket-id:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
### Renseigner vos variables d'environnement
|
||||
|
||||
Remplissez le fichier `.env` :
|
||||
|
||||
```properties [.env]
|
||||
APP_URL=https://id.mondomaine.fr
|
||||
ENCRYPTION_KEY=
|
||||
TRUST_PROXY=true
|
||||
```
|
||||
|
||||
| Variable | Valeur | Exemple |
|
||||
|----------|-------|---------|
|
||||
| `APP_URL`{lang=properties} | L'URL publique par laquelle vous joindrez Pocket ID (voir l'exposition plus bas) | `https://id.mondomaine.fr` |
|
||||
| `ENCRYPTION_KEY`{lang=properties} | La clé générée ci-dessus | `Q2pVEqsTNRkJSO9SkJzU3KZ2...` |
|
||||
| `TRUST_PROXY`{lang=properties} | Nécessaire puisque Pocket ID se trouve derrière Swag | `true` |
|
||||
|
||||
Déployez la stack. L'interface locale est disponible sur `http://ipdevotreserveur:1411`.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Première connexion
|
||||
Pocket ID n'utilise pas de mots de passe : votre premier compte est créé avec une **passkey**, que votre navigateur ou votre système génère pour vous (Windows Hello, Touch ID, un téléphone, ou une clé matérielle comme une YubiKey).
|
||||
|
||||
- Allez sur `http://ipdevotreserveur:1411/setup`
|
||||
- Suivez les instructions pour créer votre compte administrateur et enregistrer votre première passkey
|
||||
|
||||
::note
|
||||
|
||||
Comme `APP_URL` pointe déjà vers votre futur domaine public, l'enregistrement de la passkey peut vous demander d'ouvrir Pocket ID depuis ce domaine. Exposez-le d'abord (voir plus bas) si la configuration ne se termine pas en local.
|
||||
::
|
||||
|
||||
## Exposer Pocket ID avec Swag
|
||||
Les autres applications doivent joindre Pocket ID en HTTPS pour finaliser le processus de connexion OIDC, il doit donc être exposé même si vous ne l'utilisez que depuis chez vous.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons du principe que vous avez le sous-domaine `id.mondomaine.fr` avec un `CNAME` pointant vers `mondomaine.fr` dans votre [zone DNS](/general/networking/dns). Et bien sûr, [à moins d'utiliser Cloudflare Zero Trust](/serveex/security/cloudflare), le port `443` de votre box doit être redirigé vers le port `443` de votre serveur dans les [règles NAT](/general/networking/nat).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Ajouter le réseau de Pocket ID à SWAG
|
||||
|
||||
Allez dans Dockge et modifiez le fichier compose de SWAG en y ajoutant le réseau de Pocket ID :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Rattache le conteneur au réseau personnalisé
|
||||
# ...
|
||||
- pocket-id # Nom du réseau déclaré
|
||||
|
||||
networks: # Définit le réseau personnalisé
|
||||
# ...
|
||||
pocket-id: # Nom du réseau déclaré
|
||||
name: pocket-id_default # Nom réel du réseau externe
|
||||
external: true # Le marque comme défini à l'extérieur
|
||||
```
|
||||
|
||||
Redéployez la stack et attendez que SWAG soit pleinement opérationnel.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons ici du principe que le nom du réseau de Pocket ID est `pocket-id_default`. Vous pouvez vérifier la connexion en visitant le tableau de bord de SWAG sur `http://ipdevotreserveur:81`.
|
||||
::
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `id.subdomain.conf` :
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier les fichiers plutôt que des commandes dans le terminal.
|
||||
::
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/id.subdomain.conf
|
||||
```
|
||||
|
||||
Collez la configuration suivante :
|
||||
|
||||
```nginx [id.subdomain.conf]
|
||||
## Version 2023/12/19
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name id.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
client_max_body_size 0;
|
||||
|
||||
location / {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app pocket-id;
|
||||
set $upstream_port 1411;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::caution
|
||||
|
||||
Ne mettez pas Pocket ID derrière une autre couche d'authentification (TinyAuth, auth HTTP...). C'est le fournisseur d'identité lui-même, le verrouiller empêcherait quiconque, vous compris, de se connecter.
|
||||
::
|
||||
|
||||
Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et :kbd{value="Ctrl+X"} pour quitter.
|
||||
|
||||
### Visiter votre nouveau sous-domaine
|
||||
|
||||
Attendez quelques minutes, puis ouvrez `https://id.mondomaine.fr` dans votre navigateur.
|
||||
|
||||
::caution
|
||||
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Enregistrer un client OIDC
|
||||
Pour qu'une autre application (par exemple [TinyAuth](/serveex/security/tinyauth)) se connecte via Pocket ID, vous devez l'enregistrer comme client OIDC :
|
||||
|
||||
::steps{level="3"}
|
||||
### Se connecter à Pocket ID
|
||||
|
||||
Allez sur `https://id.mondomaine.fr` et connectez-vous avec votre passkey.
|
||||
|
||||
### Créer le client OIDC
|
||||
|
||||
Allez dans _Administration > OIDC Clients_, puis cliquez sur _Add OIDC Client_. Renseignez un nom (par exemple `TinyAuth`) et l'URL de callback de l'application (fournie par l'application que vous protégez).
|
||||
|
||||
### Conserver les identifiants du client
|
||||
|
||||
Enregistrez, puis copiez le __Client ID__ et le __Client Secret__ générés. Vous en aurez besoin dans la configuration de l'autre application.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Connecter Pocket ID à TinyAuth
|
||||
[TinyAuth](/serveex/security/tinyauth) peut déléguer sa connexion à Pocket ID plutôt que (ou en plus de) son identifiant/mot de passe local, de sorte que quiconque visite une application protégée s'authentifie avec une passkey et se retrouve redirigé.
|
||||
|
||||
::steps{level="3"}
|
||||
### Enregistrer TinyAuth comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC](#enregistrer-un-client-oidc) nommé `TinyAuth`, avec cette URL de callback :
|
||||
|
||||
```text
|
||||
https://tinyauth.mondomaine.fr/api/oauth/callback/pocketid
|
||||
```
|
||||
|
||||
### Ajouter le fournisseur Pocket ID dans TinyAuth
|
||||
|
||||
Copiez le __Client ID__ et le __Client Secret__ que Pocket ID vous donne, puis modifiez le fichier `.env` de TinyAuth :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/tinyauth/.env
|
||||
```
|
||||
|
||||
Ajoutez ceci :
|
||||
|
||||
```properties [.env]
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_NAME=Pocket ID
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_CLIENTID=
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_CLIENTSECRET=
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_AUTHURL=https://id.mondomaine.fr/authorize
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_TOKENURL=https://id.mondomaine.fr/api/oidc/token
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_USERINFOURL=https://id.mondomaine.fr/api/oidc/userinfo
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_REDIRECTURL=https://tinyauth.mondomaine.fr/api/oauth/callback/pocketid
|
||||
TINYAUTH_OAUTH_PROVIDERS_POCKETID_SCOPES=openid email profile
|
||||
```
|
||||
|
||||
| Variable | Valeur |
|
||||
|----------|-------|
|
||||
| `CLIENTID`{lang=properties} | Le client ID copié depuis Pocket ID |
|
||||
| `CLIENTSECRET`{lang=properties} | Le client secret copié depuis Pocket ID |
|
||||
| `AUTHURL` / `TOKENURL` / `USERINFOURL`{lang=properties} | L'URL publique de Pocket ID, avec les chemins indiqués ci-dessus |
|
||||
|
||||
Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et :kbd{value="Ctrl+X"} pour quitter.
|
||||
|
||||
### Redéployer la stack
|
||||
|
||||
Redéployez la stack TinyAuth. À votre prochaine visite sur `https://tinyauth.mondomaine.fr`, vous verrez une option « Login with Pocket ID » à côté du formulaire de connexion local.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Pour aller directement sur Pocket ID et masquer le formulaire de connexion local, ajoutez `TINYAUTH_OAUTH_AUTOREDIRECT=pocketid` au même fichier `.env`.
|
||||
::
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Et voilà ! TinyAuth propose désormais une connexion sans mot de passe via Pocket ID pour chaque application qu'il protège.
|
||||
Reference in New Issue
Block a user