dns-cloudflare: Support credentials in environment variable

[sinofool]

I would like to use environment variables for email and/or api token.

This is supported by the underlying Cloudflare library:
https://github.com/cloudflare/python-cloudflare#using-shell-environment-variables

[mahtin]

Additionally, the version number of the cloudflare python libraries could be updated in the following file - https://github.com/certbot/certbot/blob/master/certbot-dns-cloudflare/setup.py

This would allow for more authentication modes (including API Tokens).

[Tugzrida]

Environment variables are supported by the underlying CloudFlare library, yes, however certbot currently provides creds to that library from the file provided to certbot with the --dns-cloudflare-credentials flag. These creds override CloudFlare looking for environment variables, and hence to allow environment variables, changes to the certbot-dns-cloudflare plugin would be required. This isn't likely to happen soon, as the DNS plugins are earmarked to be significantly rewritten - any extra features added now simply complicates the rewriting process.

@mahtin as for updating the library, the reason that hasn't happened is due to the maximum versions supplied by some OS's that are supported by certbot. I implemented Tokens in #7583 and #8015 which made it into certbot v1.2.0 and 1.6.0. The easiest way to get Token support in certbot is to install from snap, as the newest versions of certbot and the cloudflare library are used.

[JustinLex]

This is a really important feature for using certbot in "infrastructure as code" environments. Many container orchestration tools only support passing sensitive data as environment variables, requiring users to use config files encourages users to store their cloudflare credentials unsecured, which lowers security for everyone.

Is there still a plan to rewrite these plugins? Can this feature be reconsidered for development?

[mac2000]

If I understand correct, for environment variables to work all we need is to wrap this few lines of code with additional attempt to get values from corresponding environment variables, aka:

token = os.getenv("CLOUDFLARE_API_TOKEN", default = credentials.conf('api-token'))
email = os.getenv("CLOUDFLARE_EMAIL",     default = credentials.conf('email'))
key   = os.getenv("CLOUDFLARE_API_KEY",   default = credentials.conf('api-key'))

so it will be backward compatible and solve the main issue

[alexzorin]

This is supported by the underlying Cloudflare library

I have some pretty big misgivings about letting libraries implicitly look for credentials, because it sets us up for pain when these libraries decide to make breaking changes to how they locate credentials (including changing the search order). We would be eventually forced to inherit these breaking changes. Or even worse, as in the case of the Google plugin, we had to change libraries entirely because the old one was abandoned.

That said, we do support this pattern already with Route53 and Google.

An appropriate design for this change would be to permit all three parameters (api-token, email and api-key) to be absent. In that case, the Cloudflare library can try automatically locate the credentials on the system.

_validate_credentials and _CloudflareClient.__init__ would need to be updated in order to allow every option to be absent, and to construct a default CloudFlare.CloudFlare instance, respectively.

I think it is otherwise unlikely that we would add broad support for environment variables to DNS plugins. On a mutable system, where Certbot is mostly used, getting environment variables to persist (so that the certbot renew scheduled task inherits them) is hard, non-obvious and a likely footgun for our users.

[github-actions]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[mahtin]

The original issue (opened by @sinofool four years ago) is still valid. The code simply has to accept the pass on of no email/token or key and let the underlying library use environment variables. Presently, the higher level code is not allowing this.

Hope that helps summarize all this.