-
-
Notifications
You must be signed in to change notification settings - Fork 978
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
Support passing a cloudflare zone id instead of a zone read key #2048
Comments
Hello, the fact of not restricting the zone ID is an advantage: like that it's possible to handle several zones. |
What is the most frequent count of zones updated in a single acme flow? |
We don't have telemetry, so we cannot provide that information. lego is not only a CLI, it's also a library, and in this context, hundreds of domains are handled by lego for one user. |
More of a hypothetical question than one seeking actual numbers. Solving my initial question though, it turns out that you can use the same API key for both settings if you give that key read Zone access on the Zone(s) you care about. You don't need Zone:read on the entire account for this. E.g.: |
Welcome
How do you use lego?
Through Traefik
Detailed Description
The acme.sh configuration for Cloudflare takes a zone scoped API key and the zone id. Ref: https://github.com/acmesh-official/acme.sh/wiki/dnsapi#i-single-dns-zone
Lego takes a zone scoped API key and another key with read across all zones. It's unclear why adding a second API key is necessary and contrary to the lego docs, this is a bit shy of least-privilege. It would be nice to add a CF_ZONE_ID environment variable for this.
I'm not sure if there's something I'm missing in understanding how the lego implementation differs from ACME on this.
ref: #984 (comment)
The text was updated successfully, but these errors were encountered: