azure - 我的域的 DNS 记录未通过 dns-01 质询在 azure-dns 上传播

Question

我正在尝试使用 cert-manager 为我的 istio-ingress-gateway 订购证书。为此，我在 AKS 上的 kubernetes 集群 (1.13.7) 上安装了 istio (1.2.2)，包括证书管理器。设置集群颁发者并针对我的 azure-dns 区域订购具有 dns-01 挑战的证书后，我在我的 cert-manager pod 中收到以下错误消息。此消息在日志中每十秒就会收到一次垃圾邮件:

I0813 14:48:10.597656       1 controller.go:213] cert-manager/controller/challenges "level"=0 "msg"="syncing resource" "key"="istio-system/controller-certificate-531021094-0"
I0813 14:48:10.597940       1 dns.go:112] Checking DNS propagation for "<myurl>.westeurope.cloudapp.azure.com" using name servers: [10.0.0.10:53]
E0813 14:48:10.616908       1 sync.go:180] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"<myurl>.westeurope.cloudapp.a
zure.com\" not yet propagated" "dnsName"="<myurl>.westeurope.cloudapp.azure.com" "resource_kind"="Challenge" "resource_name"="controller-certificate-531021094-0" "res
ource_namespace"="istio-system" "type"="dns-01"
I0813 14:48:10.616976       1 controller.go:219] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="istio-system/controller-certificate-53102
1094-0"

我使用以下命令安装了 istio:

helm install install/kubernetes/helm/istio --name istio --namespace istio-system \
  --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml \
  --set gateways.istio-ingressgateway.sds.enabled=true \
  --set gateways.istio-egressgateway.enabled=false \
  --set certmanager.enabled=true \
  --set certmanager.email=<myemail> \
  --set certmanager.tag=v0.8.1 

我也尝试了其他证书管理器版本(6 + 8)，但得到了相同的结果。单独的证书管理器安装给了我相同的结果。

这是我的发行人的 yaml 文件...

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: istio-system
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <myEmail>
    privateKeySecretRef:
      name: istio-ingressgateway-certs-private-key
    dns01:
      providers:
      - name: azure-dns
        azuredns:
          clientID: <myappID>
          clientSecretSecretRef:
            key: client-secret
            name: azuredns-config
          hostedZoneName: <myurl>.westeurope.cloudapp.azure.com
          resourceGroupName: <myresourcegroup> 
          subscriptionID: <mysubID> 
          tenantID: <mytenantID> 

...以及证书:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: controller-certificate
  namespace: istio-system
spec:
  secretName: istio-ingressgateway-certs
  issuerRef:
    name: letsencrypt-staging 
  commonName: <myUrl>.westeurope.cloudapp.azure.com
  dnsNames:
  - <myUrl>.westeurope.cloudapp.azure.com
  acme:
    config:
    - dns01:
        provider: azure-dns
      domains:
      - <myUrl>.westeurope.cloudapp.azure.com

在azure中，我创建了一个名为<myurl>.westeurope.cloudapp.azure.com的dns区域。然后我创建了一条 A 记录，指向集群 LoadBalancer 公开的 istio-ingress-ip。以下命令使 cert-manager 能够在 LetsEncrypt 所需的 dns 区域中添加 TXT 条目。第一个为颁发者创建一个 secret ，第二个创建一个主体来访问 dns 区域。

kubectl create secret generic azuredns-config -n istio-system --from-literal=client-secret=<myPW>

az ad sp create-for-rbac --name <myPrincipal>--role="DNS Zone Contributor" --scopes="/subscriptions/<mysubID>/resourceGroups/<myresourcegroup>"

随后在 dns 区域中成功创建 TXT 条目，但未创建证书，如上面的证书管理器日志所示。

我正在使用https://digwebinterface.com调试 dns 区域。当我使用dig TXT _acme-challenge.myurl.westeurope.cloudapp.azure.com. @mygivennameserver时我能够检索 acme token 。当我在没有名称服务器的情况下尝试此操作时，它不起作用。据我正确理解，当传播结束时这也应该起作用，对吗？

我了解到 Azure 最多需要 24 小时才能更新 DNS 记录。这也适用于 TXT 记录吗？

我尝试通过以下安装为 dns 区域的名称服务器启用 cert-manager。除了证书管理器日志中列出了其他名称服务器之外，这给了我相同的结果。安装过程中是否有错误？

helm install \
  --name cert-manager \
  --namespace istio-system \
  --version v0.9.1 \
  --set webhook.enabled=false \
  --set extraArgs='{--dns01-recursive-nameservers-only,--dns01-self-check-nameservers=8.8.8.8:53\,1.1.1.1:53\,<mynameserver>}' \
  jetstack/cert-manager

正在运行kubectl describe challenge -n istio-system结果:

Name:         controller-certificate-531021094-0
Namespace:    istio-system
Labels:       acme.cert-manager.io/order-name=controller-certificate-531021094
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Challenge
Metadata:
  Creation Timestamp:  2019-08-13T14:43:57Z
  Finalizers:
    finalizer.acme.cert-manager.io
  Generation:  4
  Owner References:
    API Version:           certmanager.k8s.io/v1alpha1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Order
    Name:                  controller-certificate-531021094
    UID:                   c740fea3-bdd8-11e9-80fd-0a58ac1f0fb7
  Resource Version:        31205901
  Self Link:               /apis/certmanager.k8s.io/v1alpha1/namespaces/istio-system/challenges/controller-certificate-531021094-0
  UID:                     c7d72ecf-bdd8-11e9-80fd-0a58ac1f0fb7
Spec:
  Authz URL:  https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/3805423
  Config:
    Dns 01:
      Provider:  azure-dns
  Dns Name:      <myurl>.westeurope.cloudapp.azure.com
  Issuer Ref:
    Name:    letsencrypt-staging
  Key:       bSjnfaFTApp6gPNsHc9-dPdmwsTwQJAd73CXmBrVc84
  Token:     Vn5Z7tBKajxnq1KrOBywP016VauoibCPcYsOESXhV4Q
  Type:      dns-01
  URL:       https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/3805423/RTxciA
  Wildcard:  false
Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for dns-01 challenge propagation: DNS record for "<myurl>.westeurope.cloudapp.azure.com" not yet propagated
  State:       pending
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Started    52m   cert-manager  Challenge scheduled for processing
  Normal  Presented  52m   cert-manager  Presented challenge using dns-01 challenge mechanism

Answer 1

我有一段时间被这个同样的问题困扰了。首先，我从来不需要自己显式创建证书资源，这就是cert-manager将尝试做的事情。

最重要的是，向入口添加以下注释解决了我的问题:

cert-manager.io/cluster-issuer: hydrantid
kubernetes.io/tls-acme: 'true'

在我的例子中，我使用 Hydrantid 作为发行者，但在给定的示例中，它将是 letsencrypt。