Automatically provision Domain Validation Records for ACM Certificate object when possible

[jaypz]

Problem:
When provisioning an ACM Certificate object, there does not appear to be a way to automatically create the validation record requiring an additional step to provision the validation records these issues/comments are related

#1904
#482 (comment)
#482 (comment)
#482 (comment)

Solution:
It would be great if were possible to have an option for certificate validation records to be provisioned automatically if a HostedZone exists in the account

[github-actions]

Hello @jaypz 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[a-hilaly]

PTAL at https://github.com/kro-run/kro/tree/main/examples/aws/ingress-triangle - ACK controllers are design to talk to only one service, as in ec2 controllers talks only to EC2, eks controller talks only to ec2 etc... hence why our controllers can't communicate with both ACM and route53. kro is the glue you need to make these cross service things work.

[zcicala]

@a-hilaly Is KRO considered production ready at this point? The docs still say

This project is in active development and not yet intended for production use. The ResourceGraphDefinition CRD and other APIs used in this project are not yet solidified and highly subject to change.

[demikl]

Hi.

I've automated the domain validation records using Kyverno + External-DNS (and not ACK Route53 since we already had external-dns deployed but not ACK route53 controller).

The policy watches pending ACM Certificates and automatically creates an annotated ExternalName Service so ExternalDNS produces the required Route53 CNAME, allowing ACM to finish validation without manual DNS changes.

---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  annotations:
    policies.kyverno.io/description: >-
      Automatically generate an ExternalName Service annotated for ExternalDNS with the CNAME validation record (hostname + target) required for AWS ACM certificate issuance.
    policies.kyverno.io/subject: certificates
  name: acm-generate-service-to-register-cert-cname
spec:
  # During the initial GitOps bootstrap, if this Kyverno policy is created after the ACM Certificate
  # object already exists, we still want to generate the Service so the required Route53 validation
  # record (managed by ExternalDNS) gets created to allow the certificate to be issued.
  generateExisting: true

  # If we later change the generated Service template, existing generated Services should be updated too.
  mutateExistingOnPolicyUpdate: true

  rules:
  - generate:
      apiVersion: v1
      data:
        metadata:
          labels:
            k8s-app: acm-controller
          annotations:
            external-dns.alpha.kubernetes.io/hostname: '{{request.object.status.domainValidations[0].resourceRecord.name}}'
            external-dns.alpha.kubernetes.io/target: '{{request.object.status.domainValidations[0].resourceRecord.value}}'
        spec:
          externalName: not.used
          type: ExternalName
      kind: Service
      name: aws-ack-acm-{{request.object.metadata.name}}
      namespace: '{{request.object.metadata.namespace}}'
    match:
      all:
      - resources:
          kinds:
          - acm.services.k8s.aws/*/Certificate/status
          - acm.services.k8s.aws/*/Certificate
    name: acm-generate-service-to-register-cert-cname
    preconditions:
      all:
      - key: '{{request.object.status.status}}'
        operator: Equals
        value: PENDING_VALIDATION
      - key: '{{request.object.status.domainValidations[0].resourceRecord.type_}}'
        operator: Equals
        value: CNAME
  validationFailureAction: Enforce

It automatically creates the DNS validation record that AWS Certificate Manager (ACM) needs, without any manual copy/paste. It does this by generating a Kubernetes Service with the right ExternalDNS annotations so that ExternalDNS creates the required Route53 CNAME record. Once that DNS record exists, ACM can finish issuing the certificate.

Step-by-step flow

1. You create an ACK ACM Certificate (the custom resource provided by the AWS Controllers for Kubernetes) for a domain using DNS validation.
2. AWS ACM responds (via the ACK controller) by updating the Certificate status. In that status, ACM includes a domainValidations array. Each entry has a resourceRecord (name, type = CNAME, value). This is the DNS challenge ACM expects to see in Route53.
3. Kyverno watches those Certificate resources. When the status shows:

• status.status = PENDING_VALIDATION
• the first domain validation record (index 0) has type = CNAME

then the policy’s preconditions pass.

4. The generate rule then creates (or updates if already present) a Service of type ExternalName in the same namespace.

• Name: aws-ack-acm-<certificate-name>
• Type: ExternalName (the actual externalName value is not important for DNS validation; the annotations are what matter)
• Annotations set:
  • external-dns.alpha.kubernetes.io/hostname = the required CNAME record name (from status.domainValidations[0].resourceRecord.name)
  • external-dns.alpha.kubernetes.io/target = the required CNAME record target/value (from status.domainValidations[0].resourceRecord.value)

5. ExternalDNS sees this Service (it watches Services with these annotations). It then creates the matching CNAME record in Route53: hostname -> target.
6. AWS ACM periodically checks DNS. When it finds the CNAME in Route53, it completes validation and issues the certificate. The Certificate status changes (e.g., to ISSUED), so the preconditions no longer match and the policy doesn’t try to regenerate anything further.
7. The Service can remain; it doesn’t normally break anything. (Optional future enhancement: add a cleanup mechanism after issuance if you want.)