[GH-ISSUE #277] Add support for reading Kubernetes secrets for stateless deployment #141

New issue

Open

opened 2026-03-13 15:55:31 +03:00 by kerem · 0 comments

kerem commented

2026-03-13 15:55:31 +03:00

Owner

Originally created by @Exagone313 on GitHub (Sep 13, 2021).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/277

Hi,

I've created the project acme-dns-sidecar that reads Kubernetes secrets and write values into the sqlite database. I succeeded to create a "stateless" acme-dns deployment where I don't use any volume, but I can still add or remove users at will without redeploying acme-dns.

I'm willing to port the feature to acme-dns directly, but I wish to discuss the implementation.

The first issue is that it would add a new dependency, that needs to be maintained as Kubernetes is updated (this also means that not all versions of Kubernetes will be supported, as the API changes, for the Kubernetes mode).

Next, a discussion to have is if an sqlite database would still be needed in that case (and only that case, I'm not breaking support for current deployments), or if a Kubernetes mode would imply that registration is disabled (thus, the route for registration is no-op) and that registration and "unregistration" are done by polling secrets.

What do you think? I can still maintain my sidecar for my use-case, it will still work.

Originally created by @Exagone313 on GitHub (Sep 13, 2021). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/277 Hi, I've created the project [acme-dns-sidecar](https://github.com/Exagone313/acme-dns-sidecar) that reads Kubernetes secrets and write values into the sqlite database. I succeeded to create a "stateless" acme-dns deployment where I don't use any volume, but I can still add or remove users at will without redeploying acme-dns. I'm willing to port the feature to acme-dns directly, but I wish to discuss the implementation. The first issue is that it would add a new dependency, that needs to be maintained as Kubernetes is updated (this also means that not all versions of Kubernetes will be supported, as the API changes, for the Kubernetes mode). Next, a discussion to have is if an sqlite database would still be needed in that case (and only that case, I'm not breaking support for current deployments), or if a Kubernetes mode would imply that registration is disabled (thus, the route for registration is no-op) and that registration and "unregistration" are done by polling secrets. What do you think? I can still maintain my sidecar for my use-case, it will still work.