Tidak dapat membuat Sertifikat wildcard (*) dengan Kubernetes dan Letsencrypt menggunakan zona Azure DNS

Saya cukup baru mengenal Kubernetes. Namun sejauh ini dapat mengonfigurasi kluster AKS (Azure Kubernetes Services). Saya memiliki beberapa ruang nama untuk layanan saya (Dev, stage, prod). Dan mengonfigurasi layanan Ingress menggunakan nginx (ke dalam namespacenya sendiri 'ingress-nginx'). Penyiapannya berfungsi sempurna dengan HTTP.

Masalah saya dimulai ketika saya mencoba menggunakan HTTPS. Pertama kali menginstal cert-manager dengan menggunakan skrip ini. Ia telah membuat namespacenya sendiri lagi: 'cert-manager' Saya tidak menggunakan HELM hanya manifes biasa. Juga mengikuti MS Azure Konfigurasi DNS .

Semuanya tampak benar Saya memiliki layanan, rahasia, clusterIssuer, dll. Bahkan tantangan dibuat di Azure DNS Zone. Anda dapat melihatnya di portal Microsoft Azure. Tapi saya tidak mendapatkan sertifikat apa pun.

masukkan deskripsi gambar di sini

Konfigurasi ClusterIssuer:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: 8b3s-org-letsencrypt
spec:
  acme:
    #server: https://acme-v02.api.letsencrypt.org/directory
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <[email protected]>
    privateKeySecretRef:
      name: 8b3s-org-letsencrypt-key
    solvers:
    - selector:
      dns01:
        azuredns:
          clientID: ....
          clientSecretSecretRef:
          # The following is the secret we created in Kubernetes. Issuer will use this to present challenge to Azure DNS.
            name: azuredns-config
            key: client-secret
          subscriptionID: ....
          tenantID: "...."
          resourceGroupName: Web
          hostedZoneName: 8b3s.org
          # Azure Cloud Environment, default to AzurePublicCloud
          environment: AzurePublicCloud

Konfigurasi masuk:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: 8b3s-virtual-host-ingress
  namespace: ingress-nginx
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: "8b3s-org-letsencrypt"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/tls-acme: "true"
spec:
  tls:
  - hosts:
     - '*.8b3s.org'
    secretName: 8b3s-org-letsencrypt-tls
  rules:
  - host: dev.8b3s.org
    http:
      paths:
      - path: /
        backend:
          serviceName: the8b3swebsite-development-ext
          servicePort: 8080

Jadi masalahnya adalah setiap konfigurasi tampak OK tetapi tidak ada Sertifikat sama sekali. Saya hanya mendapatkan 'Opaque' ' tls.key: 1679 bytes' sebagai '8b3s-org-letsencrypt-key' di namespace 'cert-manager'.

masukkan deskripsi gambar di sini

Sertifikat dibuat untuk namespace 'ingress-nginx' '8b3s-org-letsencrypt-tls' dengan tipe 'kubernetes.io/tls'. Tapi 'ca.crt: 0 byte' dan 'tls.crt: 0 byte'.

masukkan deskripsi gambar di sini

Saya juga melihat keluaran pod cert-manager. Merasa 2 log itu aneh (jika perlu saya memiliki log lengkap):

I0222 22:51:00.067791       1 acme.go:201] cert-manager/controller/certificaterequests-issuer-acme/sign "msg"="acme Order resource is not in a ready state, waiting..." "related_resource_kind"="Order" "related_resource_name"="8b3s-org-letsencrypt-tls-1807766204-3808299645" "related_resource_namespace"="ingress-nginx" "resource_kind"="CertificateRequest" "resource_name"="8b3s-org-letsencrypt-tls-1807766204" "resource_namespace"="ingress-nginx" 

I0222 22:51:00.068069       1 sync.go:129] cert-manager/controller/orders "msg"="Creating additional Challenge resources to complete Order" "resource_kind"="Order" "resource_name"="8b3s-org-letsencrypt-tls-1807766204-3808299645" "resource_namespace"="ingress-nginx" 

E0222 22:51:01.876182       1 sync.go:184] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"8b3s.org\" not yet propagated" "dnsName"="8b3s.org" "resource_kind"="Challenge" "resource_name"="8b3s-org-letsencrypt-tls-1807766204-3808299645-481622463" "resource_namespace"="ingress-nginx" "type"="dns-01" 

Adakah yang tahu apa masalahnya?

PEMBARUAN: Menambahkan data Azure NS ke DNS domain saya seperti yang disarankan. Menunggu sekitar satu jam tetapi tidak ada efeknya... Menghapus rahasia CA yang ada, memulai ulang semua Nginx, Pod manajer-sertifikat. Dan perhatikan kesalahan berikut:

E0225 10:14:03.671099       1 util.go:71] cert-manager/controller/certificaterequests/handleOwnedResource "msg"="error getting order referenced by resource" "error"="certificaterequest.cert-manager.io \"8b3s-org-letsencrypt-tls-1807766204\" not found" "related_resource_kind"="CertificateRequest" "related_resource_name"="8b3s-org-letsencrypt-tls-1807766204" "related_resource_namespace"="ingress-nginx" "resource_kind"="Order" "resource_name"="8b3s-org-letsencrypt-tls-1807766204-3808299645" "resource_namespace"="ingress-nginx" 
E0225 10:14:03.674679       1 util.go:71] cert-manager/controller/certificates/handleOwnedResource "msg"="error getting order referenced by resource" "error"="certificate.cert-manager.io \"8b3s-org-letsencrypt-tls\" not found" "related_resource_kind"="Certificate" "related_resource_name"="8b3s-org-letsencrypt-tls" "related_resource_namespace"="ingress-nginx" "resource_kind"="CertificateRequest" "resource_name"="8b3s-org-letsencrypt-tls-1807766204" "resource_namespace"="ingress-nginx" 

person Major    schedule 24.02.2020    source sumber


Jawaban (1)


catatan whois untuk domain Anda menunjukkan bahwa domain tersebut masih mengarah ke NS57.DOMAINCONTROL.COM dan bukan ke 4 Azure DNS penyelesai yang Anda tampilkan di tangkapan layar Anda. Jadi, Let's Encrypt tidak tahu bahwa mereka harus menggunakan Azure untuk mencari catatan _acme-challenge itu, dan gagal.

person mdaniel    schedule 25.02.2020
comment
Terima kasih atas jawaban Anda. Saya diblokir untuk sementara waktu...Oke jadi itu berarti konfigurasi AKS sudah benar tetapi saya harus mengubah DNS domain saya? Tapi sebenarnya apa? Maaf saya bukan ahli jaringan hanya seorang pengembang. Saat ini sedang melihat catatan DNS domain saya di GoDaddy. Apa yang Anda sebutkan NS57.DOMAINCONTROL.COM tidak dapat diubah. Menambahkan catatan NS baru yang menunjuk ke Azure seperti 30 menit yang lalu. Sejauh ini tidak berpengaruh. - person Major; 25.02.2020
comment
Seperti yang ditunjukkan oleh suara terbanyak, ini adalah situs untuk pertanyaan pemrograman, bukan untuk bagaimana cara kerja DNS. Anda mungkin lebih beruntung di serverfault.com atau dengan sedikit membaca, karena masalah yang Anda coba selesaikan bukanlah masalah baru. - person mdaniel; 25.02.2020
comment
Saya harus menunjukkan bahwa saya baru mulai bekerja dengan Kubernetes dan Docker secara umum seminggu yang lalu. Dan mengonfigurasi setiap komponen setidaknya membuat kewalahan... Atau bolehkah saya mengatakan gila :) Jadi pertanyaan awal menurut saya relevan. Senang mengetahui bahwa saya melakukan segalanya dengan benar pada pertama kalinya. :) Anda juga benar. Sekarang saya mengubah NS di GoDaddy. Atau katakanlah mencoba mengubahnya tetapi situs mereka malah mogok karena kesalahan JS... Jadi saya harus menghubungi dukungan dan meminta seseorang untuk memperbaruinya. Seluruh cerita ini gila. Setelah menunggu propagasi dan menghapus kunci lama + Daur ulang Pod berhasil! Terima kasih kamu menyelamatkanku beberapa hari :) - person Major; 25.02.2020