7 articles tagués avec « Sécurité »

Sur un cluster Kubernetes, chaque application exposée par l'ingress controller pose la même question d'authentification : certaines n'en ont aucune (tableau de bord, interface de supervision, outil interne), d'autres gèrent leurs propres comptes et ignorent ceux des autres. Un fournisseur d'identité unique, interrogé par Traefik en forward-auth pour les premières et en OpenID Connect par les secondes, ramène ces décisions à un seul annuaire. Authentik remplit ce rôle avec deux capacités absentes d'une configuration minimale : l'inscription en libre-service et les connexions par fournisseur externe (GitHub, LDAP, SAML). Son déploiement sur Kubernetes ajoute des pièges propres à Traefik en mode CRD : priorité des routers, références entre namespaces et route de callback de l'outpost.

Un forward-auth décide au niveau du reverse proxy si une requête peut atteindre un service, mais l'application protégée n'en apprend rien : elle affiche son propre formulaire de connexion, gère ses propres comptes et ignore les groupes définis dans l'annuaire central. OpenID Connect (OIDC) résout ce problème au niveau applicatif. L'application délègue l'authentification à un fournisseur d'identité, reçoit en retour un jeton signé qui décrit l'utilisateur et ses groupes, et crée sa session locale à partir de ces informations. Authelia peut jouer ce rôle de fournisseur pour toute application compatible.

Chaque application web auto-hébergée embarque sa propre gestion des comptes, ou n'en embarque aucune : un tableau de bord d'administration, une interface de supervision ou un outil interne se retrouvent exposés avec autant de formulaires de connexion, de politiques de mot de passe et de bases d'utilisateurs que de services. Le forward-auth déplace cette décision au niveau du reverse proxy : avant de transmettre une requête à l'application, le proxy interroge un service d'authentification central et ne laisse passer que les requêtes que ce dernier valide. Authelia implémente ce rôle, et Traefik le consomme via son middleware forwardAuth.

Un dépôt d'infrastructure décrit tout ce qu'il faut pour reconstruire un service, sauf les secrets (mots de passe, jetons d'API, clés privées), qui restent dans un .env ignoré par Git, copié à la main d'une machine à l'autre, rarement sauvegardé. Les versionner en clair n'est pas envisageable ; les laisser hors du dépôt casse la promesse "le dépôt suffit à tout reconstruire". git-crypt comble cet écart : certains fichiers sont chiffrés au moment du commit et déchiffrés au checkout, de façon transparente pour qui possède la clé.

TLS chiffre les communications entre client et serveur, vérifie l'identité du serveur via un certificat signé par une autorité de certification (CA), et garantit l'intégrité des données échangées. Comprendre la chaîne de certification et le handshake TLS est nécessaire pour configurer correctement HTTPS et diagnostiquer les erreurs de certificat en production.

Un dépôt Ansible décrit l'intégralité d'une infrastructure, y compris les mots de passe de bases de données, les clés d'API et les certificats nécessaires aux services. Ansible Vault chiffre ces données sensibles pour qu'elles puissent être versionnées avec le reste du code, puis les déchiffre en mémoire au moment de l'exécution des playbooks.

Une image Docker doit être identique entre les environnements : dev, staging, prod. Ce qui change entre environnements, c'est la configuration : URL de base de données, niveau de log, clés API. Kubernetes fournit deux ressources pour externaliser cette configuration, en complément des composants de base : ConfigMap pour les données non sensibles, Secret pour les credentials.