You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there! New to Incus, and having a great time setting up my first lab cluster. Most recently, I was able to get incus-ui-canonical working, and after getting that all sorted, I started to look into getting certificates cut for it. Found the built in ACME support (awesome!) but discovered that it only supported HTTP-01 validation. I generally prefer to use DNS-01 validation, as I often run services that are not exposed to the Internet, and the Incus management interface would definitely be one of those interfaces I'd prefer to not expose.
Adding support for DNS-01 validation I imagine would be a relatively easy lift, as the lego module already has support to do this. I'm not a well versed Go programmer by any stretch, but I might be willing to give this a shot myself.
The text was updated successfully, but these errors were encountered:
I've started some incredibly preliminary work for this on https://github.com/belthesar/incus/tree/feat/acme-dns-01, where I'm starting to scaffold things out. I'm patterning configuration based off of Traefik's implementation, given that it also leverages lego.
I would love some feedback on what you think about providing secrets for DNS-01 validation. This form of ACME validation requires secrets for a provider to be able to create the DNS records for the ACME certificate issuer to check, and is usually provided either in configuration, or by environment variables. Putting secrets like this into config doesn't seem like a super great idea to me, but neither does shoving them into environment variables in the incusd context. Guidance on how best to store and provide this kind of secret would be very helpful!
Config key should be fine, we already store all kind of secrets in there (OVN access keys, OpenFGA auth tokens, ...).
When accessing Incus as a non-admin user, you can't see the server configuration for that reason, so there is some protection on it. Hopefully DNS providers also have a good way to issue restricted tokens, I know that at least Cloudflare does a good job at that.
Sure! I'd to commit back to the project, since I'm interested in investing further into Incus.
I'll admit, it'll be a bit of a slow burn to getting there with the time I can commit and the fact that I'm new to both Go programming and this project, but since I'm the first person to ask for it, I imagine it'll be okay for me to work on it at my own pace. That said, if there is a desire to knock this out faster, I'm happy to turn this over to someone else. I'm enjoying the experience and would like to be more familiar with the project's internals in general, but I won't hold onto that in lieu of getting the feature available to folks in a more timely fashion.
Given my neophyte Go and Incus Project status though, I imagine I'll be soliciting for more feedback as I go.
Hi there! New to Incus, and having a great time setting up my first lab cluster. Most recently, I was able to get
incus-ui-canonical
working, and after getting that all sorted, I started to look into getting certificates cut for it. Found the built in ACME support (awesome!) but discovered that it only supported HTTP-01 validation. I generally prefer to use DNS-01 validation, as I often run services that are not exposed to the Internet, and the Incus management interface would definitely be one of those interfaces I'd prefer to not expose.Adding support for DNS-01 validation I imagine would be a relatively easy lift, as the
lego
module already has support to do this. I'm not a well versed Go programmer by any stretch, but I might be willing to give this a shot myself.The text was updated successfully, but these errors were encountered: