| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| computing:incus [2026/03/30 16:50] – oemb1905 | computing:incus [2026/10/10 01:36] (current) – oemb1905 |
|---|
| You've now cut the cert and key, bound them together in a .pem file that apache can use, and then trusted the cert portion of that .pem inside Incus so that it can trust apache. At the end, we optionally removed the crt and key after they served their purpose. So long as you don't revoke Incus' trust over the certificate, you will be good to go and Incus' web GUI and service will remain accessible to apache's reverse proxy. We also established https as default listener in Incus, so that apache's upstream requests will honor that and use/trust the .pem we just established as part of that handshake and exchange. | You've now cut the cert and key, bound them together in a .pem file that apache can use, and then trusted the cert portion of that .pem inside Incus so that it can trust apache. At the end, we optionally removed the crt and key after they served their purpose. So long as you don't revoke Incus' trust over the certificate, you will be good to go and Incus' web GUI and service will remain accessible to apache's reverse proxy. We also established https as default listener in Incus, so that apache's upstream requests will honor that and use/trust the .pem we just established as part of that handshake and exchange. |
| |
| -------------------------------------------------------------- | === Keycloak OIDC === |
| |
| === What needs to be considered? === | The above default method is a bit risky. The RP and cert forward all requests to Incus and the public has root access to the web GUI unless you use ufw or apache source location rules to stop them. If any of those break or fail to turn on, it's wide open. It's far better to setup a Keycloak instance and use it to lock down Incus Web GUI. You can and should still use source IP rules w/ apache's location blocks. To set up Keycloak, review [[https://wiki.haacksnetworking.org/doku.php?id=computing:keycloak|Keycloak]]. Once Keycloak is running, let's set up a realm for Incus Web GUI. |
| The Zably Incus web GUI, and by extension including any reverse proxy you build in front of it, //has no built-in auth mechanism//. In other words, the general public will be able to access your machine and build containers for it by simply visiting incus.domain.com. Since you probably don't want to grant the general public access to your underlying machine and/or to make/edit/destroy containers, you will need to do something else to restrict access. Some suggestions are to spin up supported third-party auth tools / instances such as but not limited to Keycloak. I am currently still testing some of those approaches and will update folks here when I finish. | |
| |
| === Bare Metal Incus Host === | * Type: OpenID Connect |
| On the **bare metal Incus host** covered here [[https://wiki.haacksnetworking.org/doku.php?id=computing:vmserver|VM Server]] I put Incus (and Cockpit) behind ssh (port 22), meaning only port 22 is open on the host. One has to ''ssh -4 -D 8080 root@domain.com'' first and then pass that network traffic to Firefox with SOCKS5 either internally or w/ FoxyProxy. Every 30 days or so, I open port 80 for the certbot renewal, and then close it again when it completes. The Let's Encrypt tutorial makes the Incus GUI play nice with your web browser (no warnings, etc.), and it's good to have to TLS on the instance by default in case something goes wrong or you open 80/443 by accident. The Incus instance is also protected by apache's ''<Location>'' functionality, which restricts remote access to static and trusted IPs. | * Client ID: ''incus'' |
| | * Client authentication: **Off** (public / PKCE) |
| | * Standard flow: **On** |
| | * Valid redirect URIs: ''https://services.haacksnetworking.org/*'' (or the exact URL you use for the Incus UI, including port if any) |
| | * Web origins: ''https://services.haacksnetworking.org'' |
| | * Save |
| |
| === Nested VM Incus Host === | No client secret. Incus does not send one. |
| On the **nested VM Incus host**, which runs as a VM inside the bare metal host described above, I **need** port 80/443 to be open //in order to run containers// (incus and podman). For this reason, I chose to use apache's built in ''<Location>'' functionality, which restricts the web GUI remote access to static and trusted IPs. This ensures that users from other locations will get a "Forbidden" notice when visiting the page. And by leaving 80/443 open on the nested VM Incus host itself, bridged and nested virtual containers - both podman and incus - are accessible with the configuration of a simple reverse proxy dedicated for the target container. This setup balances security with convenience and is designed for media hosting, music, static resources, etc. I would not, however, recommend putting anything sensitive inside Incus under this setup. For secure services, whether you use bare metal or a nested VM, you should open 80/443 on the container only and leave the management panel behind ssh. | |
| | |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/03/30 15:44// | On the Incus host: |
| | |
| | <code> |
| | incus config set oidc.issuer=https://auth.haacksnetworking.org/realms/incusgui |
| | incus config set oidc.client.id=incus |
| | incus config set oidc.scopes=openid,offline_access,profile,email |
| | </code> |
| | |
| | Confirm: |
| | |
| | <code> |
| | incus config show | grep oidc |
| | curl -sI https://auth.haacksnetworking.org/realms/incusgui/.well-known/openid-configuration |
| | </code> |
| | |
| | The ''issuer'' value in the JSON must match what you set. Trailing slash and the realm name both matter. |
| | |
| | Open the Incus UI and log in with SSO as the ''admin'' user. Then grant the identity. SSO alone is not admin: |
| | |
| | <code> |
| | incus auth identity list |
| | incus auth identity grant oidc/admin admin |
| | </code> |
| | |
| | Until you grant it, the UI authenticates and then shows nothing / 403. |
| | |
| | ''oidc.claim'' defaults to the subject. If you change the claim after the first login, Incus stores the old identity. Switch back or delete the old identity and grant the new one. |
| | |
| | === Bare Metal Incus Host Considerations === |
| | I no longer use Incus or Cockpit/Podman on bare metal, but instead put it in a VM. But/and, if you do use the bare metal, then I reocmmend this setup: |
| | |
| | On the **bare metal Incus host** covered here [[https://wiki.haacksnetworking.org/doku.php?id=computing:vmserver|VM Server]] I put Incus (and Cockpit) behind ssh (port 22), meaning only port 22 is open on the host. One has to ''ssh -4 -D 8080 root@domain.com'' first and then pass that network traffic to Firefox with SOCKS5 either internally or w/ FoxyProxy. Every 30 days or so, I open port 80 for the certbot renewal, and then close it again when it completes. The Let's Encrypt tutorial makes the Incus GUI play nice with your web browser (no warnings, etc.), and it's good to have to TLS on the instance by default in case something goes wrong or you open 80/443 by accident. The Incus instance is also protected by apache's ''<Location>'' functionality, which restricts remote access to static and trusted IPs. If I ever returned to running Cockpit/Podman and Incus on the bare metal, I would keep 80/443 closed and use a SOCKS proxy like this for access. |
| | |
| | --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/10/10 01:31// |
