SSO Keycloak avec Docker Compose et Nginx

Configuration de Keycloak SSO : utilisation de Docker Compose et de Nginx

• Keycloak est une solution open source fiable de gestion des identités et des accès, compatible avec les principaux protocoles SSO.
• La configuration avec Docker Compose n’est pas compliquée, mais elle n’est pas très intuitive ; un résumé du processus de configuration est donc proposé.

Concept

• Une configuration standard est utilisée, avec Nginx comme reverse proxy central pour acheminer le trafic vers les services individuels via localhost.
• Cela est considéré comme une configuration économique qui partage les ressources d’un hôte unique tout en isolant au maximum les environnements.

Prérequis

• Les outils de base sont nécessaires (SSH, une VM avec Linux installé, un domaine ou un sous-domaine).
• Pour une configuration Docker rootless, il faut créer un nouvel utilisateur non root sans mot de passe nommé keycloak, mettre à jour les plages /etc/subuid et /etc/subgid, installer Docker rootless et configurer le démarrage automatique du service.

Configuration de Keycloak

• Se connecter avec l’utilisateur keycloak nouvellement créé, puis créer les répertoires pour les données persistantes et les fichiers Docker.
• Rédiger le fichier docker-compose.yml en se référant à la documentation officielle, puis saisir dans le fichier .env les informations sensibles et susceptibles de changer.

Test en local

• Tester la stack Docker Compose, créer un tunnel SSH inverse vers la VM, puis vérifier dans le navigateur l’écran d’accueil de Keycloak.

Configuration de Nginx

• Configurer Nginx comme reverse proxy système, puis créer un nouveau fichier .conf Nginx pour le service Keycloak.
• Ajouter un enregistrement A chez le registraire du domaine afin de faire pointer les requêtes DNS vers l’adresse IP de la VM.

Débogage

• Ouvrir .tld.com, se connecter à Keycloak avec l’utilisateur admin, puis consulter les logs Docker Compose ainsi que les logs d’accès et d’erreur de Nginx.
• Vérifier la base de données Keycloak si nécessaire.

Build personnalisé avec Dockerfile

• Au lieu d’utiliser l’image précompilée de quay.io, construire sa propre image avec un Dockerfile.
• Redémarrer Docker Compose afin de construire l’image et de démarrer le service.

Conclusion

• Le service Keycloak fonctionne derrière un reverse proxy Nginx système avec Docker rootless.
• Les prochaines étapes incluent les mises à jour automatiques des conteneurs Docker, l’ajout de connexions et d’e-mails pour le service Keycloak, l’ajout de zones et l’ajout de thèmes.

Avis de GN⁺ :

• Importance de la sécurité : l’état actuel du web rend difficile de suivre toutes les vulnérabilités liées à la sécurité, d’où l’importance d’utiliser une solution fiable comme Keycloak.
• Architecture efficace : la méthode consistant à partager les ressources sur un seul hôte tout en isolant les environnements est rentable et facile à administrer.
• Possibilités de personnalisation : un build personnalisé avec Dockerfile offre la flexibilité d’adapter Keycloak à ses propres besoins.

[GN⁺]

Commentaires Hacker News

• Avis d’un utilisateur ayant choisi Authelia :

  • Keycloak offre beaucoup de fonctionnalités, mais sa configuration est complexe et nécessite des services supplémentaires.
  • Authelia n’a pas d’interface utilisateur et ne prend pas en charge la synchronisation bidirectionnelle avec un serveur LDAP, mais peut être configuré avec des fichiers statiques et des variables d’environnement, ce qui le rend adapté à de nombreux cas.
  • Si vous avez besoin d’une authentification simple et de SSO, il recommande de commencer par Authelia.

• Avis d’un utilisateur partageant son expérience avec JetBrains Hub et Keycloak, puis ayant choisi Dex :

  • JetBrains Hub est très facile à configurer, mais l’absence d’un tag latest pour l’image Docker est gênante.
  • Keycloak est simple en mode développement, mais sa configuration devient difficile en environnement de production réel.
  • Au final, il a choisi Dex, dont la configuration est simple malgré une documentation insuffisante.
  • Il a simplifié la mise en place du SSO en combinant OAuth2 Proxy avec des templates Nginx.
  • Il a ajouté Cloudflare Access et un WAF pour renforcer la sécurité.

• Avis d’un utilisateur ayant créé un tableau comparatif des serveurs OpenID Connect :

  • Il a été surpris par la taille de la base de code de Keycloak.

• Avis d’un utilisateur sur les problèmes de sécurité de Keycloak :

  • En regardant les CVE de Keycloak, il exprime des inquiétudes au sujet de sa sécurité.

• Avis d’un utilisateur ayant partagé son expérience de mise en œuvre de Keycloak sur AWS ECS :

  • Keycloak a connu de nombreux changements sur une longue période.
  • Il y a eu des difficultés avec le clustering, en particulier autour de la découverte DNS et de la découverte de cluster via UDP.
  • Les connexions persistantes n’étaient pas cohérentes entre les serveurs, ce qui compliquait l’équilibrage de charge.

• Avis d’un utilisateur ayant mentionné positivement Keycloakify :

  • Keycloakify semble être une excellente alternative à Keycloak.

• Avis d’un utilisateur comparant Authelia et Keycloak :

  • Authelia paraît séduisant, mais Keycloak fournit un connecteur Angular qui facilite la prise en main.

• Avis d’un utilisateur ayant partagé son expérience avec Keycloak :

  • Keycloak est complexe à configurer et manque de documentation, mais il peut être déployé et administré facilement avec Terraform.

• Avis d’un utilisateur ayant utilisé Zitadel :

  • Keycloak peut être déroutant pour les débutants, et Zitadel est plus facile à utiliser.

• Avis d’un utilisateur évoquant les difficultés d’utilisation de Keycloak :

  • Keycloak ne fournit pas directement de lien de réinitialisation de mot de passe et impose de passer par l’API.
  • La configuration en cluster n’est pas simple, et il existe des limitations au niveau des realms.
  • Construire soi-même un système de connexion sécurisé peut être risqué ou difficile.