User Tools

Site Tools


computing:keycloak

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
computing:keycloak [2026/10/10 04:30] – oemb1905computing:keycloak [2026/10/10 04:51] (current) – oemb1905
Line 95: Line 95:
 systemctl --user start container-keycloak.service systemctl --user start container-keycloak.service
 </code> </code>
- 
  
 ==== 5. Verify ==== ==== 5. Verify ====
 +
 +Once you create the quadlets, you want to start the service/container and make sure everything is in order. To do that, we just check the service and then run ''curl'' against the api endpoint.  
 +
 <code> <code>
 systemctl --user is-active container-keycloak-postgres.service container-keycloak.service systemctl --user is-active container-keycloak-postgres.service container-keycloak.service
Line 105: Line 107:
 </code> </code>
  
-Expect both ''active''. Health may take a minute on first start while Keycloak builds. On 26.x the management health endpoint can be on port 9000 inside the container. If ''curl http://127.0.0.1:8080/'' returns the welcome page, the proxy path is fine.+If everything is alright, we should see ''active''. If you don't, debug and clean up before proceeding. So long as everything is functional, we can pivot to setting up an upgrade script.
  
 ==== 6. Upgrade script ==== ==== 6. Upgrade script ====
-''/usr/local/bin/upgrade-keycloak.sh''. A tag change is an edit to ''Image='' in the matching ''.container'' file before ''daemon-reload''. The script does not recreate the units.+ 
 +OCI Containers aren't worth much without the ability to pull updates and patches quickly and painlessly. For me, a simple shell script gets this job done. Here's and example folks can tweak/edit to their liking:
  
 <code> <code>
 #!/bin/bash #!/bin/bash
 set -euo pipefail set -euo pipefail
 +export XDG_RUNTIME_DIR=/run/user/$(id -u)
 +export DBUS_SESSION_BUS_ADDRESS=unix:path=${XDG_RUNTIME_DIR}/bus
  
 podman pull docker.io/library/postgres:16-alpine podman pull docker.io/library/postgres:16-alpine
Line 128: Line 133:
 </code> </code>
  
-Run it as ''worker'':+Once this runs successfully, you can then move on to setting up a reverse proxy with apache in order to forward url requests to the host/vm upstream to the keycloak service inside the container. 
  
-<code> +==== 7. Apache reverse proxy (root) ====
-su - worker -c '/bin/bash /usr/local/bin/upgrade-keycloak.sh' +
-</code>+
  
-Do not ''sudo -u worker''. That drops the session bus.+Let's make sure the apache proxy/tunnel packages are enabled, as well as tls and location, and the certificate, are all active and ready to go. 
  
-==== 7. Apache reverse proxy (root) ==== 
 <code> <code>
-a2enmod proxy proxy_http proxy_wstunnel headers rewrite ssl+a2enmod proxy proxy_http proxy_wstunnel headers rewrite ssl authz_host 
 +certbot certonly --apache -d auth.haacksnetworking.org
 </code> </code>
  
-''/etc/apache2/sites-available/auth.haacksnetworking.org.conf'':+Create the virtual host for http ''nano /etc/apache2/sites-available/auth.haacksnetworking.org.conf'':
  
 <code> <code>
Line 149: Line 152:
     RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]     RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
 </VirtualHost> </VirtualHost>
 +</code>
 +
 +Likewise, create the virtual host for the tls block. You can optionally drop this underneath the http vhost, but/and I prefer them to be separate.
  
 +<code>
 <VirtualHost *:443> <VirtualHost *:443>
     ServerName auth.haacksnetworking.org     ServerName auth.haacksnetworking.org
Line 168: Line 175:
 </VirtualHost> </VirtualHost>
 </code> </code>
 +
 +Finally, check the configurations, restart the service, then check the endpoint.
  
 <code> <code>
Line 175: Line 184:
 </code> </code>
  
-''KC_PROXY_HEADERS=xforwarded'' matches the ''X-Forwarded-*'' headers. ''KC_HOSTNAME'' must be ''https://auth.haacksnetworking.org''.+Check the output for any errors. In my notes, I had: ''KC_PROXY_HEADERS=xforwarded'' matches the ''X-Forwarded-*'' headers. ''KC_HOSTNAME'' must be ''https://auth.haacksnetworking.org''. I'm not sure these are 100% accurate output parameters, but/and they were in my notes. I can update later if I rebuild the instance. 
  
 ==== 8. First login ==== ==== 8. First login ====
 +
 +When you first open keycloak, you want to remove the temp password and set up the admin account and master realm.
 +
   - Open ''https://auth.haacksnetworking.org''   - Open ''https://auth.haacksnetworking.org''
   - Administration Console   - Administration Console
Line 186: Line 198:
     * Frontend URL: ''https://auth.haacksnetworking.org''     * Frontend URL: ''https://auth.haacksnetworking.org''
     * Require SSL: external requests (or all)     * Require SSL: external requests (or all)
- 
-Do not keep the bootstrap password. 
  
 ==== 9. Incus OIDC ==== ==== 9. Incus OIDC ====
-Stay out of ''master'' for apps. Create a realm. 
  
-**Realm**+We will now create a dedicated real for Incus' Web GUI called "incus". Go to Realms > Add > incus > save. The endpoint should be ''https://auth.haacksnetworking.org/realms/incus''. Once you set it up, test with:
  
-  * Name: ''incus'' +  curl -sI https://auth.haacksnetworking.org/realms/incus/.well-known/openid-configuration
-  * Enabled: on+
  
-Issuer (must match Incus exactly):+**Users** (in realm ''incus'')
  
-''https://auth.haacksnetworking.org/realms/incus'' +Create one user per person using these recommendations:
- +
-<code> +
-curl -sI https://auth.haacksnetworking.org/realms/incus/.well-known/openid-configuration +
-</code> +
- +
-Must be 200. The ''issuer'' value in that JSON is what Incus uses. +
- +
-**Users** (in realm ''incus'')+
  
   * Username for SSO   * Username for SSO
Line 214: Line 214:
   * Credentials → password, Temporary **off**   * Credentials → password, Temporary **off**
  
-Create one user per human. Do not log into Incus as Keycloak ''admin'' unless that user also exists in the ''incus'' realm.+After you create the user account, you create the entry for what keycloak is being associated with:
  
 **Client** **Client**
Line 227: Line 227:
   * Web origins: ''https://<incus-ui-host>''   * Web origins: ''https://<incus-ui-host>''
   * Save   * Save
- 
-No client secret. Incus does not send one. 
  
 **Incus** **Incus**
 +
 +Configure incus on the CLI to accept the issuer:
  
 <code> <code>
Line 237: Line 237:
 incus config set oidc.scopes=openid,email,profile incus config set oidc.scopes=openid,email,profile
 incus config set oidc.claim=preferred_username incus config set oidc.claim=preferred_username
-</code> 
- 
-''oidc.claim'' can be ''email'' instead. 
- 
-<code> 
 incus config show | grep oidc incus config show | grep oidc
 </code> </code>
  
-Open the Incus UI → Login with SSO → Keycloak ''incus'' realm user. +Open the Incus UI → Login with SSO → Keycloak ''incus'' realm user. Then grant that identity. SSO alone is not admin:
- +
-Then grant that identity. SSO alone is not admin:+
  
 <code> <code>
Line 253: Line 246:
 </code> </code>
  
-From the unix socket as root, grant Admin (or project access) to the new ''oidc/'' identity. Until you do, the UI logs in and then shows nothing / 403. +From the unix socket as root, grant Admin (or project access) to the new ''oidc/'' identity. Until you do, the UI logs in and then shows nothing / 403. Alright, some of these are still in "raw note" form and I will be back to edit and update these notes if/when I have to rebuild or do further testing. While this instance is in production and working, some steps are unclear to me until I make it a third time.
- +
-==== Facts ==== +
-  * +
  
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/10/10 04:18//+ --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/10/10 04:30//
computing/keycloak.txt · Last modified: by oemb1905