Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8754

Integration between cert-manager Operator and External DNS Operator

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • cert-manager
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      Integration between cert-manager Operator and External DNS Operator

       

      2. What is the nature and description of the request?

      The request is to develop a supported integration that allows the cert-manager Operator for Red Hat OpenShift to utilize the External DNS Operator as a backend solver for ACME DNS-01 challenges.

      Currently, these two operators exist as silos. If a customer uses a DNS provider not natively included in the cert-manager Operator's "Issuer" spec, they are forced to use unsupported community webhooks, or write their own. However, the External DNS Operator may already support these providers.

      When a Certificate is requested, cert-manager should be able to create a custom resource (or a similar internal trigger) that the External DNS Operator can then use to propagate the TXT record to the target DNS provider.

      3. Why does the customer need this? (List the business requirements here)

      • Support for On-Prem Infrastructure (Infoblox): The customer utilizes Infoblox as their DNS Provider. While the External DNS Operator provides a supported path to manage Infoblox records, which is already in use, the cert-manager Operator does not. This forces the customer to choose between an automated-but-unsupported community webhook or manual certificate management, neither of which is acceptable for enterprise production.
      • Restricted Networking: In the customer's air-gapped environment, HTTP-01 challenges (Port 80) are prohibited, as HTTP (without S) shall be prohibited everywhere and also having clusters in multiple Network-Segments would require to open port 80 in multiple firewalls. DNS-01 is the mandatory path for certificate automation.
      • Wildcard Certificates: To support Hosted Control Planes (HCP) and multi-tenant ingress, wildcard certificates are required. Since ACME mandates DNS-01 for wildcards, a supported DNS integration is a hard prerequisite for their architectural rollout.
      • Standardization: By leveraging the External DNS Operator as the single point of entry for DNS changes, the customer has a single point of configuration for their DNS integration. They do not need to provide credentials with DNS access to multiple Operators / namespaces.
      • Extensibility Value: Beyond the immediate need for Infoblox for this customer, this integration would enhance the possible DNS integrations for cert-manager. As the External DNS Operator adds support for more providers (e.g., specialized on-prem appliances or niche cloud providers), those providers would automatically become available as valid ACME challenge targets for cert-manager without requiring individual code updates to the cert-manager Operator.

      4. List any affected packages or components.

      cert-manager-operator

      external-dns-operator

              rh-ee-npng Nick Png
              sluetzen Steffen Lützenkirchen
              None
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                None
                None