mirror of
https://github.com/funkypenguin/geek-cookbook/
synced 2026-11-04 14:48:17 +00:00
Improve Keycloak recipe
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
15 files changed
+102
-109
No files matched your search
@@ -1,32 +1,31 @@
|
||||
---
|
||||
title: How to setup OIDC server in Docker with KeyCloak
|
||||
description: Kick-ass OIDC and identity management
|
||||
title: Run Keycloak behind traefik in Docker
|
||||
---
|
||||
|
||||
# KeyCloak
|
||||
# Keycloak (in Docker Swarm)
|
||||
|
||||
[KeyCloak](https://www.keycloak.org/) is "_an open source identity and access management solution_". Using a local database, or a variety of backends (_think [OpenLDAP](/recipes/openldap/)_), you can provide Single Sign-On (SSO) using OpenID, OAuth 2.0, and SAML.
|
||||
[Keycloak](https://www.keycloak.org/) is "_an open source identity and access management solution_". Using a local database, or a variety of backends (_think [OpenLDAP](/recipes/openldap/)_), you can provide Single Sign-On (SSO) using OpenID, OAuth 2.0, and SAML.
|
||||
|
||||
KeyCloak's OpenID provider can also be used in combination with [Traefik Forward Auth](/docker-swarm/traefik-forward-auth/), to protect [vulnerable services](/recipes/autopirate/nzbget/) with an extra layer of authentication.
|
||||
Keycloak's OpenID provider can also be used in combination with [Traefik Forward Auth](/docker-swarm/traefik-forward-auth/), to protect [vulnerable services](/recipes/autopirate/nzbget/) with an extra layer of authentication.
|
||||
|
||||
{ loading=lazy }
|
||||
{ loading=lazy }
|
||||
|
||||
--8<-- "recipe-standard-ingredients.md"
|
||||
|
||||
## Preparation
|
||||
## Setup
|
||||
|
||||
### Setup data locations
|
||||
### Filesystem paths
|
||||
|
||||
We'll need several directories to bind-mount into our container for both runtime and backup data, so create them as per the following example
|
||||
We'll need several directories to bind-mount into our container for both runtime and backup data, so create them as per the following example:
|
||||
|
||||
```bash
|
||||
mkdir -p /var/data/runtime/keycloak/database
|
||||
mkdir -p /var/data/keycloak/database-dump
|
||||
```
|
||||
|
||||
### Prepare environment
|
||||
### Environment vars
|
||||
|
||||
Create `/var/data/config/keycloak/keycloak.env`, and populate with the following variables, customized for your own domain structure.
|
||||
Create `/var/data/config/keycloak/keycloak.env`, and populate with the following example variables, customized for your own domain structure.
|
||||
|
||||
```bash
|
||||
# Technically, this could be auto-detected, but we prefer to be prescriptive
|
||||
@@ -59,9 +58,9 @@ BACKUP_NUM_KEEP=7
|
||||
BACKUP_FREQUENCY=1d
|
||||
```
|
||||
|
||||
### Setup Docker Swarm
|
||||
## Docker compose example
|
||||
|
||||
Create a docker swarm config file in docker-compose syntax (v3), something like this:
|
||||
Create a docker swarm config file in docker-compose syntax (v3), something like this example:
|
||||
|
||||
--8<-- "premix-cta.md"
|
||||
|
||||
@@ -132,14 +131,53 @@ networks:
|
||||
|
||||
--8<-- "reference-networks.md"
|
||||
|
||||
## Serving
|
||||
## Running
|
||||
|
||||
### Launch KeyCloak stack
|
||||
### Launch Keycloak stack
|
||||
|
||||
Launch the KeyCloak stack by running `docker stack deploy keycloak -c <path -to-docker-compose.yml>`
|
||||
Launch the Keycloak stack by running `docker stack deploy keycloak -c <path -to-docker-compose.yml>`
|
||||
|
||||
Log into your new instance at `https://YOUR-FQDN`, and login with the user/password you defined in `keycloak.env`.
|
||||
|
||||
### Create User
|
||||
|
||||
!!! question "Why are we adding a user when I have an admin user already?"
|
||||
Do you keep a spare set of house keys somewhere _other_ than your house? Do you login as `root` onto all your systems? Think of this as the same prinicple - lock the literal `admin` account away somewhere as a "password of last resort", and create a new user for your day-to-day interaction with Keycloak.
|
||||
|
||||
Within the "Master" realm (_no need for more realms yet_), navigate to **Manage** -> **Users**, and then click **Add User** at the top right:
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
Populate your new user's username (it's the only mandatory field)
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
#### Set User Credentials
|
||||
|
||||
Once your user is created, to set their password, click on the "**Credentials**" tab, and procede to reset it. Set the password to non-temporary, unless you like extra work!
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
## Tips
|
||||
|
||||
### Traefik
|
||||
|
||||
Keycloak can be used with Traefik in two ways..
|
||||
|
||||
#### Keycloak behind Traefik
|
||||
|
||||
You'll notice that the docker compose example above includes labels for both Traefik v2 and Traefik v2. You obviously don't need both (*although it wont't hurt*), but make sure you update the example domain in the Traefik labels. Keycloak should work behind Traefik without any further customization.
|
||||
|
||||
#### Keycloak as Traefik middleware
|
||||
|
||||
Irrespective of whether Keycloak itself is behind Traefik, you can secure access to **other** services [behind Traefik using Keycloak][tfa-keycloak], using the [Traefik Forward Auth][tfa] middleware. Other similar middleware solutions are traefik-gatekeeper, and oauth2-proxy.
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
Something didn't work? Try the following:
|
||||
|
||||
1. Confirm that Keycloak did, in fact, start, by looking at the state of the stack, with `docker stack ps keycloak --no-trunc`
|
||||
|
||||
--8<-- "recipe-footer.md"
|
||||
|
||||
[^1]: For more geeky {--pain--}{++fun++}, try integrating KeyCloak with [OpenLDAP][openldap] for an authentication backend!
|
||||
[^1]: For more geeky {--pain--}{++fun++}, try integrating Keycloak with [OpenLDAP][openldap] for an authentication backend!
|
||||
Reference in new issue
Block a user