Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACME - Add support for DNS-01 validation #1364

Open
belthesar opened this issue Nov 9, 2024 · 4 comments
Open

ACME - Add support for DNS-01 validation #1364

belthesar opened this issue Nov 9, 2024 · 4 comments
Assignees
Labels
API Changes to the REST API Easy Good for new contributors Feature New feature, not a bug
Milestone

Comments

@belthesar
Copy link

belthesar commented Nov 9, 2024

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.

@stgraber stgraber added Feature New feature, not a bug Easy Good for new contributors API Changes to the REST API labels Nov 14, 2024
@stgraber stgraber added this to the soon milestone Nov 14, 2024
@belthesar
Copy link
Author

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!

@stgraber
Copy link
Member

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.

@breml
Copy link
Collaborator

breml commented Nov 21, 2024

@belthesar will you continue to work on this issue? If so, I would like to assign it to you.

@belthesar
Copy link
Author

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.

Thanks for reaching out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Changes to the REST API Easy Good for new contributors Feature New feature, not a bug
Development

No branches or pull requests

3 participants