Cert-manager: Error getting hosted zone name ... for ClusterIssuer without hostedZoneName defined.

[hetii]

Hello dear.
I use such ClusterIssuer.
Note here that clientID is set to: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
and hostedZoneName is not defined:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - dns01:
        azuredns:
          # Service principal client id
          clientID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
          tenantID: ...
          subscriptionID: ...
          # Secret with the password
          clientSecretSecretRef:
            key: password
            name: secret-azuredns-config
          # Name of the DNS Zone
          # https://github.com/jetstack/cert-manager/issues/1459
          # hostedZoneName: example.com
          # Resource group where the DNS Zone is located
          resourceGroupName: aks-cluster-dev

The clientID "xxxxxxxx..." have service principals created by terraform and access only for exactly given set of domains, let say (example.com, foo.com, bar.com etc).

When I apply it I got errors like:

Error getting hosted zone name for: 
 _acme-challenge.example.com., Zone com. not found in AzureDNS for domain
 _acme-challenge.example.com.. Err: dns.ZonesClient#Get: 
Failure responding to request: StatusCode=403 -- Original Error: autorest/azure:
Service returned an error. Status=403 Code="AuthorizationFailed"
Message="The client 'bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb' 
with object id 'bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb' 
does not have authorization to perform action
 'Microsoft.Network/dnsZones/read' over scope 
'/subscriptions/<my subscription here>/resourceGroups/aks-cluster-dev/providers/Microsoft.Network/dnsZones/com' 
or the scope is invalid.

As we can see there is two issue, first no clue why errors talk about client "bbbbbbbb" as I use "xxxxxxxx" and when change clientID to let say fake "yyyyyy" then got proper message, that such principal don't exist in my azure tenatID.

The second issue is that without hostedZoneName defined in ClusterIssuer, the cert-manager trying to read zones one level up, so in this case starting from .com ("Microsoft.Network/dnsZones/com'") and of course raise above errors as I don't manage primary zones :)

On other hand when I set hostedZoneName and clientID back to "xxxxxxxx..." then I see proper acme challenge that are set in my zone.

So lets say that now that I need to manage 100 different zones, do I need to create then 100 ClusterIssuers for them with only different hostedZoneName?

cert-manager version: v0.15.0-alpha.0
Kubernetes: v1.16.7
Best Regards.

[wallrj]

@hetii I don't know why the client-id should be mis-reported in the errors.
The empty hostedZone bug #1459 (reported by @tommy-dk) has been fixed in https://github.com/jetstack/cert-manager/pull/1466 by @logicfox since March 2019.

Perhaps one of them can comment on whether this is the same issue.

[wallrj]

/help

[jetstack-bot]

@wallrj:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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]

/priority backlog

[yves-vogl]

Maybe there's another issue you are not aware of.
Lets image you have 3 zones in a resource group.

root.example.com
a.root.example.com
b.root.example.com

As "a" and "b" are delegated from root.example.com they should be used for certificates e.g. (host.b.root.example.com in b.root.example.com). When not specifying the hostZoneName the cert-manager chooses root.example.com to set b.root.example.com TXT record which leads to an unresolvable record.

When specifying more than one hostedZoneName in a single issuer (e.g. a.root.example.com and b.root.example.com) and it's not able to figure out the correct zone.