Support configuration via operator subscription

[jawnsy]

Is your feature request related to a problem? Please describe.

The OpenShift installer configures split-horizon DNS with internal (private) and external (public) parts. After configuring the DNS01 challenge, cert-manager checks the default DNS to wait for the record to propagate, which happens to be the internal DNS, and the DNS is never resolvable, since cert-manager added the entry to the external (public) DNS records.

cert-manager added a command-line option the DNS server to use for this check, but this can only be set from Helm, and not the Operator Subscription that installs cert-manager.

Describe the solution you'd like

It appears that the operator framework provides a facility for passing configuration settings to operators, so it would be nice if the DNS server list could be set there.

Describe alternatives you've considered

• cert-manager appears to add records to a single matching zone for DNS01 challenges (i.e. it cannot add records to both the public and private DNS zones), which might be a potential solution to this. By adding it to both zones, the internal resolver would also be able to detect the record and proceed, though it's not exactly testing what cert-manager needs to test (that things are resolvable externally)
• Manually modify the cert-manager deployment (the Operator seems to undo these customizations, and any changes are not preserved across upgrades)
• Might be able to configure the cluster to use external DNS exclusively (rather than the internal cluster DNS), but I don't know how to do this

Additional context

Environment details (remove if not applicable):

• Kubernetes version:

  Client Version: 4.7.0-0.okd-2021-06-19-191547
  Server Version: 4.7.0-0.okd-2021-08-22-163618
  Kubernetes Version: v1.20.0-1093+4593a24e8fd58d-dirty

• Cloud-provider/provisioner: Google Cloud
• cert-manager version: 1.4.3
• Install method: Operator Hub

/kind feature

[lousyd]

I, too, have this issue. I'm running on AWS with same versions as above, and I installed by OperatorHub. In my own troubleshooting I only got as far as determining that the Challenge is stuck in pending because it's "Waiting for dns-01 challenge propagation". It's querying a nameserver that's in my private zone, not the public one. The actual acme TXT record is publicly available. It seems like if cert-manager skipped the propagation check, the challenge would be satisfied and the acme cert would be issued. So it's just that propagation check that's holding things up.

@jawnsy added a lot of detail I wasn't aware of. Thank you, sir!

[niklashagman]

Setting Nameservers for DNS01 Self Check is still not possible when installing cert-manager from built in OperatorHub in OpenShift.

Environment details

• Kubernetes version:
  • Client Version: 4.8.17
  • Server Version: 4.8.17
  • Kubernetes Version: v1.21.2
• Cloud-provider/provisioner: user-provisioned cluster on bare metal
• cert-manager version: 1.6.0
• Install method: OperatorHub built into OpenShift

[bdurrow]

I believe that this issue is related: cert-manager/cert-manager-olm#22

[bdurrow]

Here is my current workaround in GCP: https://gist.github.com/bdurrow/e90bf7949b56476d955f489a0ef605fb

[jetstack-bot]

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

[jetstack-bot]

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.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[EagleIJoe]

/remove-lifecycle rotten

[wallrj]

I've attempted to document the configuration options available to users of the existing OLM package:

• Document how to configure cert-manager via OLM website#983

Please review and comment.

[jetstack-bot]

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

[jetstack-bot]

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.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[wallrj]

/reopen

[jetstack-bot]

@wallrj: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[wallrj]

This came up again on Slack: https://kubernetes.slack.com/archives/C4NV3DWUC/p1698923865622489

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.