Cert-manager: Make spec.acme.email optional

[ramnes]

Is your feature request related to a problem? Please describe.
To set up an ACME issuer, I'm forced to specify an email address while Let's Encrypt (or potentially another future ACME provider) doesn't have it required.

Describe the solution you'd like
Make the email field optional.

/kind feature

[munnerz]

I wasn't actually aware this field is optional, but from some reading around I see that it is the case.

certbot gates this behind an extra flag, but that's awkward for us to replicate given our declarative resource model.

I'd be keen to hear from those at Let's Encrypt to see how they feel about this... I know this field has been very helpful in the past when tracking down abusive traffic patterns 😄

cc @jsha @cpu

[cpu]

I'd be keen to hear from those at Let's Encrypt to see how they feel about this... I know this field has been very helpful in the past when tracking down abusive traffic patterns

We strongly recommend that folks provide one or more contact addresses for this reason and for others. For example it's very helpful if we need to contact an organization because of a security incident or during a deprecation (e.g. users of the TLS-SNI-01 challenge type).

Similarly by not providing an email address you opt out of receiving certificate expiration warnings. We often hear that this is a useful line of last defence that can catch broken automation before relying parties do.

I think its fair to choose not to provide a contact and our ACME server does support that use case. If you think cert-manager users will benefit from being able to create an account without an email I think the best idea would be to document the trade-offs and make it explicit that not providing an email address will be accepting some additional risks.

[jsha]

I agree with @cpu. As an idea, you could have a config field like "UnsafelyRegisterWithoutEmail: true", and config parsing would require that either the user provides an email, or that they provide this extra field indicating they really want to go out of their way to omit an email. The thing I want to avoid is that "no email" becomes the default because it winds up in example configs and tutorials and so on. It definitely has been useful in contact the owners of clients with abusive traffic patterns.

@ramnes as an FYI, if you omit the email, you are not just missing out on expiration notices, but you will also miss the opportunity to be notified if your client starts sending too much traffic. This could lead to us blocking your client without notice if it becomes necessary.

[ramnes]

Thanks for making it clear @jsha.

Something like "UnsafelyRegisterWithoutEmail: true", with the according documentation, would be perfectly fine to me.

[jsha]

I've emailed with the maintainers, but I wanted to document this publicly as well: Since the v0.8.0 release, which made email addresses optional, we've seen a huge increase in cert-manager clients that don't provide an email address. And many of these clients are acting in problematic ways due to cert-manager bugs, which means we need to reach their owners.

It's my belief that this isn't related to a spike in people worried about sharing their email address with Let's Encrypt, but simply that not providing one is the simplest path - while, as discussed above, we'd like the simple path be the one where users provide an email address.

Given that we're still seeing problems with excessive traffic from cert-manager clients, I'd like to see email become mandatory again, at least until the excessive traffic problems are resolved. This doesn't have to be a breaking change for users who already have accounts, since their accounts will keep working. But if cert-manager adds code at account creation time to reject configs with no email, that will at least ensure we have a contact path for new users.