cert-manager
Create TLSA records automatically
Is your feature request related to a problem? Please describe.
I'd like to have TLSA records for my cert-manager managed certificates.
Describe the solution you'd like
Cert manager automatically creates TLSA records if configured to do so. Because it already supports DNS01 challenges and a wide range of DNS providers, this could be comparatively easy.
Alternatively, a mutating webhook might work. I'will look into this further, but imho i'd be cleaner if cert-manager does this automatically.
Something related was discussed in #3706
Describe alternatives you've considered
-
Doing it manually is not an option.
-
Using something like Weaveworks watcher (as discussed in https://github.com/cert-manager/cert-manager/issues/3706#issuecomment-786698617) does not scale to hundreds or more certificates, from a maintenance perspective.
-
Building a custom controller would be possible, but might also leave a period of time when the record does not match the certificate.
-
Mutating webhooks.
/kind feature
Agreed. I looked into doing this myself to implement DANE support for SMTP. Using a DNS01 challenge would make this trivially simple.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale
Unless this was implemented in the meantime, IMHO this is still a valid feature request. Especially because there has been 0 arguments against, or any workaround described yet.
I didn't realize this bot needs an explicit command.
/remove-lifecycle stale
FWIW my workaround was to use skater to monitor changes to the TLS secret and reload the postfix pod. On launch, my postfix pod has an initContainer that updates the TLSA record to match the current TLS certificate.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
This is not something we have bandwidth to look at right now, though we would review any contributions if someone wants to have a look themselves.
/priority backlog
Understood, fair enough. This feature request should imho be extended to the new https records, as that is basically the same idea, just a different record type
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
/remove-lifecycle stale
imho as this is a accepted but backlogged feature request, and open to contributions, it should not go stale.
I'd assume that would be lifecycle/frozen, but i don't think i'm allowed to assign that.
I think the first step would be a PR with a proposal, this has a lot of touch points and probably needs nailing down before we have a code contribution.
For example, one thing we are considering is moving provider specific DNS logic into external "official" plugins instead of having them all in-tree. So adding more dependencies on the DNS providers would need to be done carefully in order to not lock us out of that option.
oh, i wasnt even thinking about how to start yet. i just was annoyed that i got another stale notification.
What i had thought about was leveraging external_dns as much as possible, because that also allows us to externalize the state of dns records, while making it very transparent how it works to users
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale