Rather than generating a new cert, is it possible to put an LE certificate somewhere that the (Incus) UI will be able to use it? I looked through the Incus documents and those of, um, the original project and it wasn’t clear where. Or do you insist on a private cert, which I’d rather not do?
You can configure Incus itself to use Let’s Encrypt, see the acme server configuration options.
That would then get you a valid certificate for the web UI.
Yes, I saw that. Unfortunately my hosts are not open to the Internet inbound so I use DNS-01 to generate the LE certs.
If they’re clustered, you can use incus cluster update-certificate to replace the public facing cluster certificate across your cluster with a new one.
If they’re standalone, then you’d want to directly replace /var/lib/incus/server.crt and /var/lib/incus/server.key with your cert and then run systemctl restart incus to reload the API.
Great, thanks. I’ll give it a try.
I don’t cluster because with (UK) energy costs being what they are I bring hosts down when I’m not using them; and I find things that rely on a quorate don’t like that.
Yeah, indeed, you’d need a minimum of 2 systems up at all times.
Thanks, I did (finally …) do this but on first login Incus still wants me to create a new certificate. The (Firefox) browser says my cert is valid. Is this expected behaviour, ie I need to still create and import a browser cert even though I’m using a “proper” site certificate?
don’t mix ssl certificate and client trust certificate, first one used to protect connection between client and server, while second for authorization.
so yes, you need both of them, unless:
- some UI would support OpenConnect ID (OIDC) auth (+flow)
- you have OIDC provider self-hosted (like KeyCloak) or in cloud (Okta)
- incus were configured for OIDC
for me it looks like a pain in the… in the current state
Well, it’s confusing - since the TLS cert is supposed to establish the identity of the server; whereas auth is an entirely separate exercise, the IAP should give the browser a token. I don’t see why there is a need for a separate client cert, it doesn’t improve security in any way.
No response, but in the meantime it’s come up on Reddit where apart from not bothering to read the docs to generate the browser token, someone does have a valid issue putting it behind a reverse proxy.
Is the browser trust requirement really necessary? I struggle to understand its benefit and it’s comparatively unfriendly vs “competing” hypervisors.
Reverse proxies terminate the TLS session, so the client certificate never makes it to Incus, meaning you’ll forever be untrusted and unable to do anything. That’s unless your reverse proxy works at the TCP level (which is what I do for my clusters).
It’s not so much browser trust as it is user authentication.
Incus doesn’t know what a user is, it doesn’t have the concept of usernames and passwords for authentication. What it has is a list of client certificates which are trusted to interact with it.
Adding the client certificate to the web browser and having your browser use it to connect to Incus is how you authenticate.
(All of the above assumes the default TLS authentication. Those using OpenID Connect don’t use any of that TLS stuff and so can handle http reverse proxies and the like.)
Yes, the reverse proxy issue isn’t mine, it’s some Reddit user who admits their knowledge shortcomings. Combined with their not bothering to read any instructions, apparently, unfortunately it’s not terribly appealing to try to help them.
All I’m saying is this client cert requirement is an oddity compared to other hypervisors and adds friction.
It’s the proper way to do things. Similar to using public key authentication with SSH.
Who uses passwords with SSH anymore?
In our lives we do thousands of things in a certain way because it’s convenient, or faster, or easier, even if it’s not the “proper” way to do things. And I would also say your view of the “proper” way could be entirely different from others’, dispassionately you would hopefully agree that it is rare in the world of software to have acceptance of client browser certificates as the entry level requirement to access the GUI.
In software strongly held opinions on the “proper” way to do things can have benefit when talking about functionality and capability, but I’d argue it’s rarely beneficial in UX.
All I’m saying is what you already know - Incus lives in a crowded marketplace full of options and starts years behind the others in terms of adoption and visibility. I think Incus is great and I want it to be a success for all sorts of reasons, so I’m just suggesting that places where there is friction like this which is odd and outside the new users’ experience are worth thinking about.
2 Likes
I could not find much documentation on actually setting up the Incus Web UI and I struggled on how to start. I persevered and I ended up writing this post, How to install and setup the Incus Web UI – Mi blog lah! I feel I have a good initial understanding and I am looking to get more experience with a reverse-proxy setup or using a Let’s Encrypt certificate.
If someone tries to go through my post and gets stuck on a specific step, I am able to provide support. They can get support by themselves because I also tried to add commands in the post to verify most of the steps.
1 Like
Yes, I pointed someone to your post yesterday. Thank you for it!
To take an entirely hypothetical example, let’s say I was responsible for technical strategy (in several areas including security) at a large global entity. Let’s say I think there are usecases where Incus would be a good fit, particularly as (again hypothetically) we are in the middle of getting rid of our existing hypervisor vendor. Let’s also imagine that I work for a highly regulated entity and we recreate the user VDI instance every day at midnight, (purposely) wiping any client certs. You could imagine that at such a hypothetical entity a piece of software that hasn’t been through the 9-18 month official onboarding process is not allowed to connect to our corporate IDAM system. In this scenario being able to properly evaluate Incus and prove its value is a non-starter.
Which, hypothetically, would be a big pity.
If in that hypothetical setup it is possible to use SSH public key authentication, then it would be possible to use user certificates as well. That is, reusing the generated key pairs/certificates after each system rebuild. The ability to generate the user certificate over a web page is a convenience and not a requirement. I cannot tell you the steps off my head but I expect that an evening of investigation would be enough to sort it out.
No, in the hypothetical situation general users don’t have those entitlements.
Can I use OpenID as the auth for Incus-UI? Or keep it simple with no auth?
This post only talks about lxd/incus remote add --auth-type=oidc.
I would like to host Incus-UI with Cloudflare tunnel, after Cloudflare Access. Cloudflare Access is doing the good job on authentication. I host other homelab services without built-in auth - just let Cloudflare Access handle that.
Spent 2 days to finally get it. See this post for details.
1 Like