Azure DNS 搭配 Let's Encrypt 與 K8s cert-manager：打造自動化 HTTPS 的終極指南

  • Post by
  • Jun 26, 2025
post-thumb

哈囉，各位雲端探險家和 Kubernetes 魔法師們！今天我們要來聊一個超酷的話題：如何讓你的應用程式在 Azure 上，既能享受 Let’s Encrypt 提供的免費 SSL/TLS 憑證，又能透過 Kubernetes 的 cert-manager 實現憑證的自動化管理。聽起來是不是很誘人？想像一下，從此告別手動更新憑證的惡夢，讓你的網站永遠保持 HTTPS 的安全光環，是不是覺得人生都亮了起來？

在這個數位時代，HTTPS 已經不再是可有可無的選項，而是網站安全的標配。Google 爸爸都說了，沒有 HTTPS 的網站，搜尋排名會受影響喔！而 Let’s Encrypt 就像是我們的超級英雄，提供免費、自動化的憑證，讓大家都能輕鬆實現 HTTPS。但問題來了，當你的應用程式部署在 Kubernetes 上，而且 DNS 服務又在 Azure 時，該怎麼把這些好東西串起來呢？別擔心，這篇文章就是你的武功秘笈，我將手把手帶你走過這趟奇幻旅程，從 Azure DNS 的設定，到 cert-manager 的部署與配置，保證讓你功力大增！

Buy Me a Coffee

準備好了嗎？繫好安全帶，我們即將啟程！

為什麼要用 Azure DNS、Let’s Encrypt 和 cert-manager？

在深入技術細節之前，讓我們先來了解一下，為什麼這三位主角會是天作之合：

Azure DNS：微軟爸爸的 DNS 服務

如果你已經是 Azure 的忠實用戶，那麼 Azure DNS 絕對是你的不二之選。它提供了高可用、高擴展性的 DNS 託管服務，與 Azure 生態系統完美整合。對於在 Azure 上部署應用程式的你來說，使用 Azure DNS 可以省去許多跨平台配置的麻煩，管理起來也更加方便。

Let’s Encrypt：免費、自動化的 SSL/TLS 憑證

Let’s Encrypt 的出現，徹底改變了 SSL/TLS 憑證的生態。它由非營利組織 Internet Security Research Group (ISRG) 營運，旨在推動全網路的 HTTPS 化。它的最大優勢就是免費、自動化，並且廣受瀏覽器信任。這意味著你不再需要花大錢購買憑證，也不用擔心憑證過期後手忙腳亂地更新。

cert-manager：Kubernetes 憑證管理大師

對於 Kubernetes 用戶來說，cert-manager 簡直是神一般的存在。它是一個原生的 Kubernetes 憑證管理工具，可以自動從各種憑證頒發機構（包括 Let’s Encrypt）獲取、續訂和使用 SSL/TLS 憑證。有了它，你只需要簡單的配置，就能讓你的 Kubernetes 服務自動擁有 HTTPS，大大簡化了憑證管理的複雜性。

當這三者結合起來，你就能擁有一個全自動、高效率、低成本的 HTTPS 解決方案，讓你的應用程式在 Azure Kubernetes Service (AKS) 上跑得又快又穩，還能讓使用者安心瀏覽。是不是很棒？

接下來，我們就來看看如何一步步實現這個夢幻組合吧！

Azure DNS 設定：為憑證自動化鋪路

在我們讓 cert-manager 能夠自動管理憑證之前，首先要確保它有權限在你的 Azure DNS 區域中操作。這就像是給 cert-manager 一把鑰匙，讓它可以自由進出你的 DNS 區域，幫你自動新增或刪除 DNS 記錄來完成 Let’s Encrypt 的驗證。這裡我們將使用 Azure AD Workload Identity (工作負載身分識別) 的方式來進行身份驗證，這是目前最推薦且最安全的方式。

步驟一：建立 Azure AD Workload Identity

首先，我們需要為 cert-manager 建立一個 Azure AD Workload Identity。這個身分識別將會被 Kubernetes 中的 Service Account 所使用，讓 cert-manager 能夠以這個身分去操作 Azure 資源。

# 設定環境變數
export IDENTITY_NAME="cert-manager-identity" # 給你的身分識別取個名字
export RESOURCE_GROUP_NAME="rg-integrations" # 你的 DNS Zone 所在的資源群組名稱

# 建立 Azure AD Workload Identity
az identity create --name "${IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP_NAME}"

執行成功後，你會看到類似以下的輸出，其中 clientId 和 principalId 是我們稍後會用到的重要資訊：

{
  "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/rg-integrations/providers/Microsoft.ManagedIdentity/userAssignedIdentities/cert-manager-identity",
  "location": "eastus",
  "name": "cert-manager-identity",
  "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "resourceGroup": "rg-integrations",
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

步驟二：賦予 Workload Identity DNS Zone Contributor 權限

接下來，我們需要賦予這個新建立的 Workload Identity 在你的 Azure DNS 區域中修改記錄的權限。這裡我們給予 DNS Zone Contributor 角色，這個角色擁有管理 DNS 區域中記錄集的權限，但無法管理 DNS 區域本身。

# 設定環境變數 (如果上一步沒有設定)
export IDENTITY_CLIENT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 上一步驟得到的 clientId
export DNS_ZONE_NAME="vitalext.com" # 你的 DNS 區域名稱
export SUBSCRIPTION_ID="0d9d91d9-b251-4f1b-ac5e-39d20d2f52c0" # 你的 Azure 訂閱 ID

# 賦予權限
az role assignment create \
    --role "DNS Zone Contributor" \
    --assignee "${IDENTITY_CLIENT_ID}" \
    --scope "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP_NAME}/providers/Microsoft.Network/dnszones/${DNS_ZONE_NAME}"

小提醒： 在實際操作中，請將上述命令中的 IDENTITY_CLIENT_ID、DNS_ZONE_NAME、SUBSCRIPTION_ID 和 RESOURCE_GROUP_NAME 替換成你自己的實際值喔！

步驟三：啟用 AKS 的 OIDC Issuer 和 Workload Identity

如果你的 Kubernetes 叢集是 Azure Kubernetes Service (AKS)，你需要確保你的 AKS 叢集已經啟用了 OIDC Issuer 和 Workload Identity 功能。這兩個功能是 Workload Identity 運作的基礎。

# 設定環境變數
export AKS_CLUSTER_NAME="your-aks-cluster-name" # 你的 AKS 叢集名稱
export AKS_RESOURCE_GROUP="your-aks-resource-group" # 你的 AKS 叢集所在的資源群組名稱

# 啟用 OIDC Issuer 和 Workload Identity
az aks update \
    --name "${AKS_CLUSTER_NAME}" \
    --resource-group "${AKS_RESOURCE_GROUP}" \
    --enable-oidc-issuer \
    --enable-workload-identity

注意： 如果你的 AKS 叢集已經啟用了這些功能，再次執行此命令不會有任何影響。如果你的 Kubernetes 叢集不是 AKS，或者你使用的是自建的 Kubernetes 叢集，你需要參考相關文件來配置 Workload Identity Federation。

步驟四：建立 Federated Credential (聯邦憑證)

聯邦憑證是將 Azure AD Workload Identity 與 Kubernetes Service Account 連結起來的關鍵。它允許 Kubernetes Service Account 使用其自身的令牌 (token) 來交換 Azure AD Workload Identity 的憑證，進而獲得操作 Azure 資源的權限。

# 設定環境變數
export SERVICE_ACCOUNT_NAME="cert-manager" # cert-manager 將使用的 Service Account 名稱
export SERVICE_ACCOUNT_NAMESPACE="cert-manager" # cert-manager 將部署的 Namespace
export IDENTITY_NAME="cert-manager-identity" # 之前建立的 Workload Identity 名稱

# 獲取 AKS 叢集的 OIDC Issuer URL
export SERVICE_ACCOUNT_ISSUER=$(az aks show --resource-group "${AKS_RESOURCE_GROUP}" --name "${AKS_CLUSTER_NAME}" --query "oidcIssuerProfile.issuerUrl" -o tsv)

# 建立聯邦憑證
az identity federated-credential create \
  --name "cert-manager-federated-credential" \
  --identity-name "${IDENTITY_NAME}" \
  --resource-group "${RESOURCE_GROUP_NAME}" \
  --issuer "${SERVICE_ACCOUNT_ISSUER}" \
  --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}"

到這裡，我們已經完成了 Azure DNS 端的準備工作。現在，cert-manager 已經擁有了在你的 Azure DNS 區域中操作的權限，接下來我們就可以開始部署 cert-manager 並配置 Let’s Encrypt 了！

Let’s Encrypt：免費憑證的魔法

Let’s Encrypt 憑證的申請過程，主要是透過 ACME (Automated Certificate Management Environment) 協定來完成。為了證明你對域名擁有控制權，Let’s Encrypt 會要求你完成一個「挑戰」(Challenge)。目前最常用的挑戰方式有兩種：HTTP-01 和 DNS-01。由於我們需要為 Kubernetes 服務提供憑證，並且要自動化這個過程，DNS-01 挑戰會是更好的選擇，因為它不需要你的服務暴露在公網上，也不會受到防火牆或負載均衡器的影響。

DNS-01 挑戰原理

DNS-01 挑戰的原理很簡單：當你向 Let’s Encrypt 申請憑證時，它會給你一個特定的字串。你需要將這個字串作為一個 TXT 記錄，新增到你域名下的 DNS 區域中。Let’s Encrypt 的伺服器會去查詢這個 TXT 記錄，如果查詢到的值與它給你的字串相符，就表示你確實擁有這個域名的控制權，然後它就會頒發憑證給你。

而 cert-manager 的作用，就是自動化這個 TXT 記錄的增刪過程。當它收到憑證申請時，會自動與 Let’s Encrypt 進行溝通，獲取挑戰字串，然後利用我們之前設定好的 Azure AD Workload Identity，在 Azure DNS 中新增 TXT 記錄。一旦驗證成功，它會自動刪除這個 TXT 記錄，並將憑證儲存在 Kubernetes 的 Secret 中。

Let’s Encrypt 環境

Let’s Encrypt 提供了兩個環境：

  • Staging (測試環境)：用於測試和開發，不會受到速率限制，但頒發的憑證不會被瀏覽器信任。非常適合在正式部署前進行測試。
  • Production (生產環境)：用於正式部署，頒發的憑證會被所有主流瀏覽器信任，但有嚴格的速率限制。在測試無誤後，才應該切換到生產環境。

在接下來的配置中，我們會先使用 Staging 環境進行測試，確保一切運作正常後，再切換到 Production 環境。

cert-manager：Kubernetes 憑證管理大師的部署與配置

cert-manager 是 Kubernetes 生態系中不可或缺的一員，它讓憑證管理變得前所未有的簡單。接下來，我們將一步步部署 cert-manager，並配置它與 Let’s Encrypt 和 Azure DNS 協同工作。

步驟一：部署 cert-manager

部署 cert-manager 最推薦的方式是使用 Helm。Helm 是 Kubernetes 的套件管理工具，可以幫助我們輕鬆部署和管理應用程式。

首先，添加 cert-manager 的 Helm repository：

helm repo add jetstack https://charts.jetstack.io
helm repo update

接著，安裝 cert-manager。在安裝時，我們需要啟用 podLabels 和 serviceAccount.labels，以便 Azure AD Workload Identity 能夠正確地將 Service Account 令牌注入到 cert-manager 的 Pod 中。

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.14.5 \
  --set installCRDs=true \
  --set podLabels."azure.workload.identity/use"="true" \
  --set serviceAccount.labels."azure.workload.identity/use"="true"

小提示： 請務必確認你使用的 cert-manager 版本，並將 --version 參數替換為最新的穩定版本。--set installCRDs=true 會自動安裝 cert-manager 所需的 Custom Resource Definitions (CRDs)。

部署完成後，你可以檢查 cert-manager 的 Pod 是否正常運行：

kubectl get pods -n cert-manager

如果一切順利，你應該會看到 cert-manager、cert-manager-cainjector 和 cert-manager-webhook 這三個 Pod 都處於 Running 狀態。

步驟二：創建 ClusterIssuer 或 Issuer

cert-manager 透過 Issuer 或 ClusterIssuer 資源來定義憑證的頒發者。Issuer 只能在特定的 Namespace 中使用，而 ClusterIssuer 則可以在整個叢集中使用。由於我們希望憑證可以在任何 Namespace 中被申請，因此我們將創建一個 ClusterIssuer。

這裡我們將配置一個使用 Azure DNS DNS-01 挑戰的 ClusterIssuer，並指向 Let’s Encrypt 的 Staging 環境。

創建一個名為 letsencrypt-staging-clusterissuer.yaml 的檔案，內容如下：

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    email: your-email@example.com # 請替換為你的電子郵件地址，用於接收憑證過期通知
    server: https://acme-staging-v02.api.letsencrypt.org/directory # Let's Encrypt Staging 環境
    privateKeySecretRef:
      name: letsencrypt-staging-private-key # 儲存 ACME 帳戶私鑰的 Secret 名稱
    solvers:
    - dns01:
        azureDNS:
          clientID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 之前建立的 Workload Identity 的 clientID
          subscriptionID: "0d9d91d9-b251-4f1b-ac5e-39d20d2f52c0" # 你的 Azure 訂閱 ID
          resourceGroupName: "rg-integrations" # 你的 DNS Zone 所在的資源群組名稱
          hostedZoneName: "vitalext.com" # 你的 DNS 區域名稱
          environment: AzurePublicCloud
          managedIdentity: {}

重要： 請務必將 email、clientID、subscriptionID、resourceGroupName 和 hostedZoneName 替換為你的實際值！

這裡的 managedIdentity: {} 表示 cert-manager 將會使用我們之前設定的 Azure AD Workload Identity 來進行身份驗證。它會自動從 Pod 的環境變數中獲取相關資訊。

應用這個 ClusterIssuer：

kubectl apply -f letsencrypt-staging-clusterissuer.yaml

你可以檢查 ClusterIssuer 的狀態：

kubectl get clusterissuer letsencrypt-staging -o yaml

如果一切正常，你應該會看到 status.conditions 中有一條 type: Ready 且 `status:

True的條件，表示ClusterIssuer` 已經準備就緒。

步驟三：創建 Certificate 資源

有了 ClusterIssuer 之後，我們就可以開始申請憑證了！cert-manager 透過 Certificate 資源來定義你想要申請的憑證。當你創建一個 Certificate 資源時，cert-manager 會自動與 ClusterIssuer 協同工作，向 Let’s Encrypt 申請憑證，並將其儲存在 Kubernetes 的 Secret 中。

創建一個名為 example-certificate.yaml 的檔案，內容如下：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default # 憑證將會儲存在這個 Namespace 中
spec:
  secretName: example-com-tls-secret # 憑證將會儲存為這個 Secret
  issuerRef:
    name: letsencrypt-staging # 引用我們之前創建的 ClusterIssuer
    kind: ClusterIssuer
  dnsNames:
    - example.com # 請替換為你的域名
    - www.example.com # 如果需要多個域名，可以在這裡添加

重要： 請務必將 dnsNames 替換為你自己的實際域名！

應用這個 Certificate：

kubectl apply -f example-certificate.yaml

你可以檢查 Certificate 的狀態：

kubectl get certificate example-com-tls -n default -o yaml

如果一切順利，你應該會看到 status.conditions 中有一條 type: Ready 且 status: True 的條件，表示憑證已經成功頒發並儲存在 example-com-tls-secret 這個 Secret 中了！

你也可以檢查 Secret 是否存在：

kubectl get secret example-com-tls-secret -n default

這個 Secret 中包含了 tls.crt (憑證)、tls.key (私鑰) 和 ca.crt (CA 憑證鏈)。你可以將這個 Secret 掛載到你的 Ingress 或其他需要 HTTPS 的服務中。

步驟四：切換到 Production 環境

當你在 Staging 環境中測試一切正常後，就可以切換到 Production 環境來獲取受信任的憑證了。這只需要修改 ClusterIssuer 的 server 地址即可。

編輯 letsencrypt-staging-clusterissuer.yaml 檔案，將 server 地址修改為 Let’s Encrypt 的 Production 環境地址：

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production # 建議將名稱也改為 production，方便識別
spec:
  acme:
    email: your-email@example.com
    server: https://acme-v02.api.letsencrypt.org/directory # Let's Encrypt Production 環境
    privateKeySecretRef:
      name: letsencrypt-production-private-key # 建議也修改 Secret 名稱
    solvers:
    - dns01:
        azureDNS:
          clientID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
          subscriptionID: "0d9d91d9-b251-4f1b-ac5e-39d20d2f52c0"
          resourceGroupName: "rg-integrations"
          hostedZoneName: "vitalext.com"
          environment: AzurePublicCloud
          managedIdentity: {}

然後重新應用這個 ClusterIssuer：

kubectl apply -f letsencrypt-production-clusterissuer.yaml

注意： 如果你修改了 ClusterIssuer 的名稱，那麼你之前創建的 Certificate 資源也需要更新 issuerRef 來指向新的 ClusterIssuer。最簡單的方式是刪除舊的 Certificate 資源，然後創建一個新的，這樣 cert-manager 會自動重新申請憑證。

kubectl delete certificate example-com-tls -n default
# 修改 example-certificate.yaml 中的 issuerRef.name 為 letsencrypt-production
kubectl apply -f example-certificate.yaml

這樣，你的應用程式就能夠使用 Let’s Encrypt 頒發的、受信任的 SSL/TLS 憑證了！

憑證整合：讓你的服務安全上線

憑證已經躺在 Kubernetes 的 Secret 裡了，接下來就是如何讓你的應用程式使用這些憑證，實現 HTTPS 加密。最常見的方式就是透過 Kubernetes 的 Ingress 資源來配置 TLS。

什麼是 Ingress？

Ingress 是 Kubernetes 中一個非常重要的資源，它負責管理對叢集內部服務的外部訪問。你可以把它想像成一個智慧型的流量管理員，根據你定義的規則，將外部請求路由到正確的內部服務。Ingress 通常會搭配一個 Ingress Controller (例如 Nginx Ingress Controller、Azure Application Gateway Ingress Controller 等) 來實現其功能。

配置 Ingress 使用憑證

當你有了 cert-manager 頒發的憑證 Secret 後，配置 Ingress 使用它就非常簡單了。你只需要在 Ingress 資源的 tls 部分引用這個 Secret 即可。

以下是一個使用 Nginx Ingress Controller 的 Ingress 範例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx # 指定 Ingress Controller
    cert-manager.io/cluster-issuer: letsencrypt-production # 指定 cert-manager 的 ClusterIssuer
spec:
  tls:
  - hosts:
    - example.com # 你的域名
    - www.example.com # 你的域名
    secretName: example-com-tls-secret # 引用 cert-manager 創建的 Secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: your-service-name # 你的服務名稱
            port:
              number: 80 # 你的服務端口
  - host: www.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: your-service-name
            port:
              number: 80

重要：

  • 將 example.com 和 www.example.com 替換為你的實際域名。
  • 將 your-service-name 和 80 替換為你的服務名稱和端口。
  • kubernetes.io/ingress.class: nginx 註解用於指定 Ingress Controller。如果你使用的是其他 Ingress Controller，請根據其文檔進行修改。
  • cert-manager.io/cluster-issuer: letsencrypt-production 這個註解非常重要，它告訴 cert-manager 當這個 Ingress 被創建時，自動為其申請憑證。如果憑證不存在或即將過期，cert-manager 會自動處理申請和續訂。

應用這個 Ingress 資源：

kubectl apply -f example-ingress.yaml

當這個 Ingress 資源被創建後，cert-manager 會自動監聽它，並根據 cert-manager.io/cluster-issuer 註解指定的 ClusterIssuer 來為 tls.hosts 中列出的域名申請憑證。一旦憑證成功頒發並儲存在 secretName 指定的 Secret 中，Ingress Controller 就會自動加載這些憑證，為你的服務啟用 HTTPS。

憑證自動續訂

cert-manager 最棒的功能之一就是憑證的自動續訂。Let’s Encrypt 頒發的憑證有效期通常為 90 天。cert-manager 會在憑證過期前自動觸發續訂流程，確保你的服務始終擁有有效的憑證，讓你高枕無憂。

這個續訂過程完全是自動化的，你不需要手動介入。cert-manager 會在憑證過期前的一段時間（通常是 30 天）自動發起新的 ACME 挑戰，獲取新的憑證，並更新 Kubernetes Secret 中的內容。Ingress Controller 會自動檢測到 Secret 的更新，並重新加載憑證，整個過程對用戶來說是無感的。

完整流程圖解

為了讓大家更直觀地理解整個流程，我準備了一個流程圖。這個圖將展示從憑證申請到自動續訂的整個生命週期。

Syntax error in textmermaid version 10.9.3

流程說明：

  1. 使用者創建 Ingress 資源：使用者定義一個 Ingress 資源，其中包含需要 HTTPS 的域名，並指定 cert-manager.io/cluster-issuer 註解。
  2. Ingress Controller 監聽 Ingress：Ingress Controller 檢測到新的 Ingress 資源，並根據其規則配置流量路由。
  3. cert-manager 監聽 Ingress：cert-manager 也會監聽 Ingress 資源，當它發現有 cert-manager.io/cluster-issuer 註解時，就會為其自動創建或管理憑證。
  4. cert-manager 創建 Certificate 資源：cert-manager 會根據 Ingress 的配置，自動創建一個對應的 Certificate 資源。
  5. cert-manager 觸發 ACME 挑戰 (DNS-01)：Certificate 資源被創建後，cert-manager 會向 Let’s Encrypt 發起憑證申請，並選擇 DNS-01 挑戰方式。
  6. cert-manager 使用 Azure AD Workload Identity：cert-manager 利用之前設定的 Azure AD Workload Identity，獲得操作 Azure DNS 的權限。
  7. 在 Azure DNS 中創建 TXT 記錄：cert-manager 會在你的 Azure DNS 區域中，為挑戰域名創建一個包含特定字串的 TXT 記錄。
  8. Let’s Encrypt 驗證 TXT 記錄：Let’s Encrypt 的伺服器會查詢這個 TXT 記錄，以驗證你對域名的所有權。
  9. Let’s Encrypt 頒發憑證：如果驗證成功，Let’s Encrypt 會頒發 SSL/TLS 憑證。
  10. cert-manager 將憑證儲存為 Kubernetes Secret：cert-manager 接收到憑證後，會將其儲存在 Kubernetes 的 Secret 中。
  11. Ingress Controller 加載 Secret 中的憑證：Ingress Controller 會自動加載這個 Secret 中的憑證，並將其應用到對應的服務上。
  12. 服務啟用 HTTPS：你的應用程式現在可以透過 HTTPS 安全地訪問了！
  13. 憑證即將過期：當憑證即將過期時，cert-manager 會自動重複步驟 5 到 10，實現憑證的自動續訂。

這個流程圖清晰地展示了各個組件之間的協同工作，以及憑證從申請到續訂的整個自動化過程。

總結：讓 HTTPS 成為你的超能力

恭喜你！透過這篇文章的引導，你已經掌握了如何在 Azure DNS 上設定 Let’s Encrypt，並利用 Kubernetes 的 cert-manager 實現憑證的自動化管理。這不僅讓你的應用程式更加安全，也大大減輕了你手動管理憑證的負擔。從此以後，你可以把更多的精力放在應用程式的開發和創新上，而不是被憑證過期這種小事困擾。

回顧一下我們今天學到的：

  • Azure DNS 提供了穩定可靠的 DNS 服務，與 Azure 生態系統無縫整合。
  • Let’s Encrypt 讓免費、自動化的 SSL/TLS 憑證成為可能，推動了全網路的 HTTPS 化。
  • cert-manager 則是 Kubernetes 憑證管理的利器，它自動化了憑證的獲取、續訂和部署，讓你高枕無憂。
  • Azure AD Workload Identity 提供了安全且推薦的身份驗證方式，讓 cert-manager 能夠安全地操作 Azure 資源。

這三者的結合，為你的 Kubernetes 應用程式提供了一個強大、高效且自動化的 HTTPS 解決方案。無論你是開發者、維運工程師，還是雲端架構師，掌握這些技能都將讓你在雲原生時代如虎添翼。

當然，技術的世界日新月異，Let’s Encrypt、cert-manager 和 Azure 的功能也會不斷更新。因此，保持學習的熱情，持續關注官方文檔和最新動態，才能讓你的知識庫永遠保持在最新狀態。

希望這篇文章對你有所幫助！如果你在實踐過程中遇到任何問題，歡迎留言討論。讓我們一起，讓 HTTPS 成為你的超能力，為網路世界帶來更多的安全與信任！

參考資料

  1. cert-manager Documentation - AzureDNS
  2. Deploy cert-manager on Azure Kubernetes Service (AKS) and use Let’s Encrypt
  3. Azure AD Workload Identity for Kubernetes
  4. Let’s Encrypt
  5. Azure DNS documentation
LATEST POST
TAG
CATEGORIES