带有基于 Cloudflare 的 DNS 解析器的 ClusterIssuer

Question

我正在尝试在 AKS 上安装 cert-manager ClusterIssuer，并且因为集群位于 Azure 应用程序网关之后，所以我选择了使用 DNS 解析器而不是 HTTP。但是，挑战失败并出现调用 Cloudflare API 的错误。我已经通过代码片段编辑了电子邮件和域，kubectl describe challenge rabt-cert-tls-g4mcl-1991965707-2468967546 的输出是：

Events:
  Type     Reason        Age               From          Message
  ----     ------        ----              ----          -------
  Normal   Started       72s               cert-manager  Challenge scheduled for processing
  Warning  PresentError  3s (x5 over 71s)  cert-manager  Error presenting challenge: Cloudflare API Error for GET "/zones?name=<domain>"
            Error: 6003: Invalid request headers<- 6103: Invalid format for X-Auth-Key header

我已按照 https://blog.darkedges.com/2020/05/04/cert-manager-kubernetes-cloudflare-dns-update/ and the issues at https://github.com/jetstack/cert-manager/issues/3021 and https://github.com/jetstack/cert-manager/issues/2384 上的指南进行操作，但看不到发行者的 apiVersion 之外的任何差异。我已根据官方文档对此进行了检查，这些指南中显示的内容没有任何变化。

ingress 和 cluster issuer 之间的关系似乎很好；如果我删除并重新创建入口，则会创建一个新证书、订单和挑战。我已验证密钥已填充并且我可以将其打印到控制台，因此它不应该在 header 中发送空白字符串。令牌有效，我可以使用来自 CloudFlare 的示例 CURL 请求来检查其有效性。

有什么地方可以查看日志并准确找出发送的内容吗？

集群发行者

apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-token-secret
  namespace: cert-manager
type: Opaque
stringData:
  api-token: ${CLOUDFLARE_API_TOKEN}
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: rabt-letsencrypt
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: <email>
    # ACME server URL for Let’s Encrypt’s staging environment.
    # The staging environment will not issue trusted certificates but is
    # used to ensure that the verification process is working properly
    # before moving to production
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource used to store the account's private key.
      name: rabt-letsencrypt-key
    # Enable the HTTP-01 challenge provider
    # you prove ownership of a domain by ensuring that a particular
    # file is present at the domain
    solvers:
    - dns01:
         cloudflare:
           email: <email>
           apiTokenSecretRef:
             name: cloudflare-api-token-secret
             key: api-key

入口

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rabt-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-protocol: https
    appgw.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: rabt-letsencrypt
    cert-manager.io/acme-challenge-type: dns01
    appgw.ingress.kubernetes.io/backend-path-prefix: "/"
spec:
  tls:
  - hosts:
    - "*.rabt.<domain>"
    secretName: rabt-cert-tls
  rules:
  - host: "mq.rabt.<domain>"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: rabt-mq
            port:
              number: 15672
  - host: es.rabt.<domain>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: rabt-db-es-http
            port:
              number: 9200
  - host: "kibana.rabt.<domain>"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: rabt-kb-http
            port:
              number: 5601

Answer 1

As Harsh Manvar guessed, it was an issue with the secret. I wasn't running the kubectl apply command through envsubst 所以它正在编码文字字符串“${CLOUDFLARE_API_TOKEN}”

带有基于 Cloudflare 的 DNS 解析器的 ClusterIssuer

ClusterIssuer with Cloudflare based DNS solver

cloudflare

kubernetes

cert-manager