Does `trust add-certificate` require sudo?

Hello there!

I am working on adding a TLS certificate to the Incus daemon on my laptop. Actually I am just setting up a WebUI to manage it. Here are my key settings:

  • Host: Debian 13 x64
  • Incus package: 6.12-debian13-202505151659 from Zabbly
  • Host user: a normal desktop user without membership of incus-admin group.
  • Incus project: user-1000 set up by Incus automatically.

I look through to the guides in the documents, blogs and posts[1][2], but I got a little confused when I tried them on.

First, I followed the instructions to add the TLS certificate, but I got the error “not authorized”, I also got another “Certificate is restricted” error when I tried to set up the Incus daemon to expose the WebAPI as follows.

$ nano mywebui.crt  # Save certificate
$ incus config trust add-certificate mywebui.crt
Error: not authorized
$ incus config set core.https_address="[::]:8443"
Error: Certificate is restricted

These errors can be mitigated simply by running them as sudo, and the Web UI then run smoothly.

$ sudo incus config set core.https_address="127.0.0.1:8443"
$ sudo incus config trust add-certificate lxconsole.crt

My concern is as follows:

  1. Is such behavior in line with expectations or related to my settings? The docs I referred to did not mention the need to be “sudo” or “incus-admin” to do so. Or am I missing something?
  2. Does the certificates added to trust pool have accesses to all projects or users’ resources? I found that I can switch between projects in WebUI with this certificate.
  3. To be honest, I am a little confused about the role of the certificate. Is this certificate used for the TLS traffic encryption between client and server ONLY? Or does it also indicate the identity of the user?
  4. Further, is it possible to make the certificate as a “user-space” resource? That is, the certificate can be added as a normal user without “sudo” or “incus-admin”, and the certificate grants only accesses to the user’s resources.

I’m not very familiar with this area, and thank you for your patience in responding. :slight_smile:

I have been spending time in writing simple notes on incus for beginners (like myself). Let me know if this image helps to explain the steps involved.

Welcome!

The Error: not authorized error might be related to the general Incus configuration. Youir non-root account probably does not belong to the incus-admin Unix group, but rather to the incus group which is somewhat restricted.

To verify, run

$ groups
.... incus-admin ...

Also, when you run incus info and you are a restricted user, you would get

  1. project: myusername-00x, and not default.
  2. auth_user_method: tls, and not unix (using the Unix group membership).

Therefore, my running sudo in front of the incus command, you have been bypassing the restricted user setup.

Hence, if that’s the case, add your non-root account to the incus-admin group.

Thanks for your reply and your figure! The connection is very clear now! :blush:

1 Like

Thank you for your reply and your detailed, lovely blogs for Incus!

Adding a UNIX user to incus-admin group works perfectly, and it is the ideal solution for daily desktop use.

It might be a bit off-topic, but I am still curious about how Incus deals with the certificate and connection authentication.

My concern is that, by adding the certificate to the trust pool, the client seems to have the same privileges as incus-admin, which might not be what expected especially in a network.

I used to think that certificates were tied to a user’s identity and that accessing the Incus daemon with a key corresponding to a certificate indicated the user’s identity, just like the common SSH setup.

However, it seems that I was mistaken about this in Incus.

So is it possible to allow a client connection (like WebUI) with a trusted certificate, while limiting the connection’s privileges and accesses, e.g. project-specific, just like the non-incus-admin users do in their shell?

Thank you again for your patience in answering.

1 Like

Incus supports several types of authorization.

In general, it’s either full access or restricted access. (Unix socket or TLS).

You can get much more fine-grained authorization through Open Fine-Grained Authorization (OpenFGA) or Scriptlets.

Thanks! Everything is clear now and I will give them a try! :laughing: