Pomerium est un reverse proxy identity-aware open source qui contrôle l’accès à vos applications internes par l’identité de l’utilisateur, sans VPN. Ce guide pose les bases conceptuelles : architecture, composants, flux d’authentification et limites. Aucune installation nécessaire ici — le guide pratique Docker Compose prend le relais ensuite.
Le problème à résoudre
Section intitulée « Le problème à résoudre »Exposer une application interne sans l’ouvrir au monde
Section intitulée « Exposer une application interne sans l’ouvrir au monde »La plupart des équipes ont des applications internes à rendre accessibles : dashboards d’administration, outils d’observabilité, interfaces de CI/CD, applications métier. Deux approches classiques coexistent, et aucune ne satisfait pleinement.
Le VPN crée un tunnel réseau entre l’utilisateur et le réseau interne. Une fois connecté, l’utilisateur accède à tout le réseau, pas seulement à l’application visée. C’est comme donner la clé de l’immeuble entier à quelqu’un qui veut juste entrer dans un bureau. Si le poste de l’utilisateur est compromis, l’attaquant hérite de cet accès large.
Le bastion SSH ou le reverse proxy exposé réduit la surface, mais le contrôle reste rudimentaire. Un reverse proxy classique (Nginx, HAProxy) route le trafic, mais ne sait pas qui fait la requête. Il ne peut pas décider qu’Alice a le droit d’accéder au dashboard Grafana mais pas au panneau d’administration.
Réduire la confiance implicite du réseau
Section intitulée « Réduire la confiance implicite du réseau »Le modèle traditionnel repose sur une hypothèse : « si tu es sur le réseau interne, tu es de confiance ». C’est la confiance implicite, et c’est exactement ce que le modèle zero trust remet en question.
Le principe zero trust se résume à : ne jamais faire confiance, toujours vérifier. Chaque requête est évaluée individuellement, quelle que soit sa provenance réseau. L’identité de l’utilisateur, le contexte de la requête et les politiques définies par l’équipe déterminent si l’accès est accordé.
Passer d’un accès réseau à un accès piloté par identité
Section intitulée « Passer d’un accès réseau à un accès piloté par identité »C’est le changement fondamental : au lieu de contrôler d’où vient la requête (adresse IP, segment réseau), on contrôle qui fait la requête (identité vérifiée par un fournisseur d’identité) et ce qu’il a le droit de faire (politiques d’accès).
Pomerium est conçu exactement pour cela.
Le principe de l’identity-aware proxy
Section intitulée « Le principe de l’identity-aware proxy »Un identity-aware proxy (proxy conscient de l’identité) est un reverse proxy qui ajoute une couche d’authentification et d’autorisation à chaque requête.
Différence avec un reverse proxy classique
Section intitulée « Différence avec un reverse proxy classique »Un reverse proxy classique comme Nginx ou Traefik reçoit une requête et la transmet à un serveur en amont (upstream). Il peut faire du load balancing, de la terminaison TLS, du caching. Mais il ne sait pas qui est l’utilisateur. Si la requête arrive, elle passe.
Un identity-aware proxy intercepte la requête avant de la transmettre. Il vérifie que l’utilisateur est authentifié (connecté via un fournisseur d’identité) et autorisé (ses attributs correspondent à la politique définie pour cette route). Si l’utilisateur n’est pas authentifié, il est redirigé vers la page de connexion. S’il est authentifié mais non autorisé, la requête est refusée.
| Critère | Reverse proxy classique | Identity-aware proxy (Pomerium) |
|---|---|---|
| Sait qui fait la requête | Non | Oui (via OIDC) |
| Vérifie les droits d’accès | Non | Oui (politiques par route) |
| Redirige vers un IdP | Non | Oui |
| Transmet l’identité à l’application | Non | Oui (headers, JWT) |
| Gère le routage réseau | Oui | Oui |
| Terminaison TLS | Oui | Oui |
Différence avec un VPN
Section intitulée « Différence avec un VPN »Un VPN donne un accès réseau. Pomerium donne un accès applicatif. La différence est fondamentale :
- Le VPN ouvre un tunnel vers un réseau entier. Pomerium n’expose que les applications explicitement configurées.
- Le VPN ne sait pas quelle application l’utilisateur veut atteindre. Pomerium sait exactement quelle route est demandée et peut appliquer des règles différentes par application.
- Le VPN authentifie une fois à la connexion. Pomerium vérifie l’identité et les droits à chaque requête.
- Le VPN nécessite un client installé sur le poste. Pomerium fonctionne directement dans le navigateur.
Pourquoi l’identité devient la condition d’accès
Section intitulée « Pourquoi l’identité devient la condition d’accès »Dans un modèle zero trust, la question n’est plus « es-tu sur le bon réseau ? » mais « es-tu la bonne personne, avec les bons droits, pour accéder à cette ressource précise, maintenant ? ».
Pomerium s’appuie sur un fournisseur d’identité (IdP) compatible OIDC (OpenID Connect) pour répondre à cette question. Keycloak, Authentik, Google Workspace, Azure AD, Okta — tout IdP qui parle OIDC peut servir de source de vérité pour l’identité.
Architecture logique de Pomerium
Section intitulée « Architecture logique de Pomerium »Pomerium est composé de 4 services qui peuvent tourner ensemble dans un seul processus (mode all-in-one) ou séparément (mode split).
Rôle du Proxy
Section intitulée « Rôle du Proxy »Le Proxy est le point d’entrée de toutes les requêtes. C’est lui qui écoute sur le port 443 et reçoit les connexions des utilisateurs. Il vérifie auprès du service d’autorisation si la requête peut passer, puis transmet la réponse de l’upstream à l’utilisateur.
En termes simples : le Proxy est le videur à l’entrée. Il vérifie votre identité et regarde si votre nom est sur la liste avant de vous laisser entrer.
Rôle du service Authenticate
Section intitulée « Rôle du service Authenticate »Le service Authenticate gère le flux de connexion avec le fournisseur d’identité. Quand un utilisateur non authentifié arrive, le Proxy le redirige vers le service Authenticate, qui initie le flux OIDC : redirection vers l’IdP, récupération du token, création de la session.
C’est le bureau d’accueil qui vous demande votre pièce d’identité et la vérifie auprès de l’autorité compétente (l’IdP).
Rôle du service Authorize
Section intitulée « Rôle du service Authorize »Le service Authorize prend les décisions d’accès. Pour chaque requête, il reçoit du Proxy les informations sur l’utilisateur (issues de la session) et la route demandée, puis il évalue les politiques d’accès configurées.
La réponse est binaire : autorisé ou refusé. C’est le responsable sécurité qui vérifie que votre badge vous donne bien accès à cet étage précis.
Rôle du Databroker
Section intitulée « Rôle du Databroker »Le Databroker est le service de stockage et de synchronisation des données de session. Il conserve les sessions utilisateur, les données de l’annuaire (utilisateurs, groupes récupérés de l’IdP) et les informations de routage.
En mode all-in-one, il utilise un stockage en mémoire. En production avec plusieurs instances, il peut utiliser PostgreSQL pour partager l’état entre les réplicas.
Flux de communication entre composants
Section intitulée « Flux de communication entre composants »Voici comment les 4 composants interagissent lors d’une requête typique :
- L’utilisateur envoie une requête HTTPS vers
app.example.com - Le Proxy reçoit la requête et demande au Databroker si une session valide existe
- Si pas de session : le Proxy redirige vers le service Authenticate
- Le service Authenticate redirige vers l’IdP (Keycloak, Authentik…)
- L’utilisateur s’authentifie auprès de l’IdP
- L’IdP renvoie un token au service Authenticate
- Le service Authenticate crée une session dans le Databroker
- L’utilisateur est redirigé vers le Proxy avec sa session
- Le Proxy demande au service Authorize si l’accès est permis
- Le service Authorize évalue la politique configurée pour cette route
- Si autorisé : le Proxy transmet la requête à l’application upstream
- La réponse de l’application revient à l’utilisateur via le Proxy
Lors des requêtes suivantes, les étapes 3 à 8 sont sautées tant que la session est valide. Le contrôle d’autorisation (étapes 9-10) est effectué à chaque requête.
All-in-one ou split mode
Section intitulée « All-in-one ou split mode »Pourquoi le mode all-in-one est souvent le meilleur point de départ
Section intitulée « Pourquoi le mode all-in-one est souvent le meilleur point de départ »En mode all-in-one, les 4 services tournent dans un seul conteneur ou processus. C’est la configuration par défaut de Pomerium.
Les avantages :
- Simplicité : un seul conteneur à déployer, un seul fichier de configuration
- Pas de réseau interne à configurer : les services communiquent en local
- Idéal pour les labs, le homelab et les petits déploiements : moins de pièces mobiles
Pour un homelab, une équipe de quelques dizaines de personnes ou un premier déploiement, le mode all-in-one est parfaitement adapté.
Quand envisager le split mode
Section intitulée « Quand envisager le split mode »Le mode split déploie chaque service séparément. Il devient pertinent quand :
- Vous avez besoin de scaler le Proxy indépendamment (beaucoup de requêtes entrantes)
- Vous voulez isoler le service Authenticate pour des raisons de sécurité (il manipule les tokens IdP)
- Vous déployez sur Kubernetes avec des exigences de haute disponibilité
- Vous avez plus de 100 routes ou un volume de trafic élevé
Conséquences opérationnelles
Section intitulée « Conséquences opérationnelles »Le split mode implique :
- Du TLS interne entre les composants (gRPC avec mTLS)
- Un réseau de communication fiable entre les services
- Un Databroker partagé (PostgreSQL) pour que les services partagent l’état
- Un load balancer devant les instances Proxy
Pour la majorité des cas d’usage couverts dans cette série de guides, le mode all-in-one suffit.
Authentification et autorisation
Section intitulée « Authentification et autorisation »Ces deux concepts sont souvent confondus. Pomerium les traite comme deux opérations distinctes et séquentielles.
L’authentification : qui est l’utilisateur
Section intitulée « L’authentification : qui est l’utilisateur »L’authentification répond à la question « Qui es-tu ? ». Pomerium délègue cette vérification à un fournisseur d’identité (IdP) via OIDC. Le résultat est un ensemble d’informations sur l’utilisateur, appelées claims :
- email : l’adresse email vérifiée
- groups : les groupes auxquels l’utilisateur appartient dans l’IdP
- name : le nom affiché
- sub : l’identifiant unique de l’utilisateur
Ces claims sont stockées dans la session et disponibles pour les décisions d’autorisation.
L’autorisation : a-t-il le droit d’entrer
Section intitulée « L’autorisation : a-t-il le droit d’entrer »L’autorisation répond à « As-tu le droit de faire ça ? ». Pomerium évalue les politiques d’accès (policies) configurées pour chaque route.
Une politique peut vérifier :
- L’email de l’utilisateur (accès réservé à
alice@example.com) - Son domaine email (accès à tous les
@monentreprise.com) - Ses groupes (accès aux membres du groupe
devops) - Une combinaison de critères (groupe
adminET domaine@monentreprise.com)
Le rôle des claims et des groupes
Section intitulée « Le rôle des claims et des groupes »Les claims sont les informations que l’IdP transmet à Pomerium après l’authentification. Parmi elles, les groupes sont particulièrement utiles pour structurer les politiques d’accès.
Par exemple, dans Keycloak ou Authentik, vous pouvez créer des groupes
devops, dev, admin, lecture-seule. Chaque utilisateur appartient à un
ou plusieurs groupes. Pomerium peut ensuite utiliser ces groupes pour décider
qui accède à quoi :
- Le dashboard Grafana → groupe
devops - L’interface d’administration → groupe
admin - L’application métier → groupe
dev+ groupedevops
Comment Pomerium prend ses décisions
Section intitulée « Comment Pomerium prend ses décisions »À chaque requête, le service Authorize évalue 4 éléments :
Route demandée
Section intitulée « Route demandée »Quelle URL l’utilisateur tente d’atteindre. Chaque route a sa propre politique.
grafana.example.com et admin.example.com peuvent avoir des règles très
différentes.
Politique appliquée
Section intitulée « Politique appliquée »La politique associée à cette route. Elle définit les critères d’accès : qui peut passer, sous quelles conditions.
Contexte utilisateur
Section intitulée « Contexte utilisateur »Les informations sur l’utilisateur extraites de sa session : email, groupes, claims additionnelles fournies par l’IdP.
Décision finale
Section intitulée « Décision finale »Le service Authorize croise la politique et le contexte utilisateur :
- Si les critères sont satisfaits → accès autorisé, la requête est transmise à l’upstream
- Si les critères ne sont pas satisfaits → accès refusé, l’utilisateur reçoit une erreur 403
- Si l’utilisateur n’est pas authentifié → redirection vers l’IdP
Cette évaluation est effectuée à chaque requête. Même si l’utilisateur était autorisé il y a 5 minutes, un changement de politique ou de groupes peut modifier la décision.
Forces et limites de Pomerium
Section intitulée « Forces et limites de Pomerium »Les cas où il est très pertinent
Section intitulée « Les cas où il est très pertinent »- Publier des applications web internes sans VPN : dashboards, outils DevOps, interfaces d’administration
- Homelab et self-hosting : protéger Grafana, Proxmox, Home Assistant, Nextcloud derrière une authentification centralisée
- Contrôle d’accès fin : différencier les droits par application, par groupe, par utilisateur
- Audit et traçabilité : chaque accès est loggé avec l’identité de l’utilisateur
- Migration progressive : on peut ajouter Pomerium devant des applications existantes sans les modifier
Les limites à connaître
Section intitulée « Les limites à connaître »- Pomerium ne protège que le trafic HTTP/HTTPS (et TCP/SSH via des tunnels dédiés). Il ne remplace pas un pare-feu réseau.
- Il dépend d’un IdP fonctionnel. Si l’IdP est indisponible, aucune nouvelle authentification n’est possible (les sessions existantes continuent de fonctionner temporairement).
- Il ne gère pas les autorisations fines à l’intérieur de l’application. Pomerium contrôle l’accès à l’application, pas les permissions dans l’application.
- Le mode all-in-one stocke les sessions en mémoire. Un redémarrage
déconnecte tous les utilisateurs (sauf si un
COOKIE_SECRETstable est configuré pour la rotation de session persistante).
Ce qu’il faut compléter avec d’autres briques
Section intitulée « Ce qu’il faut compléter avec d’autres briques »Pomerium est une pièce du puzzle, pas la solution complète :
| Besoin | Outil complémentaire |
|---|---|
| Gestion des identités et groupes | IdP (Keycloak, Authentik) |
| Pare-feu réseau | iptables, nftables, Calico |
| Détection d’intrusion | Falco, OSSEC |
| Gestion des secrets | HashiCorp Vault |
| Sécurité des conteneurs | Trivy, admission controllers |
| Accès SSH avancé | Teleport (alternative avec session recording) |
À retenir
Section intitulée « À retenir »- Pomerium est un identity-aware proxy : il contrôle l’accès par l’identité, pas par le réseau
- Il se compose de 4 services (Proxy, Authenticate, Authorize, Databroker) qui tournent ensemble en mode all-in-one ou séparément en mode split
- Chaque requête passe par un cycle authentification → autorisation → transmission vers l’upstream
- Les politiques d’accès s’appuient sur les claims OIDC (email, groupes) fournies par un IdP
- Pomerium ne remplace ni le pare-feu, ni l’IdP, ni les autorisations applicatives — il s’intercale entre l’utilisateur et l’application
- Le mode all-in-one est le bon point de départ pour la majorité des cas
- Structurez vos politiques autour des groupes pour simplifier la maintenance