最新消息：在Twitter和Mastodon取得專案更新

RFC-2136

本文檔的目標是提供部署 cert-manager 對抗符合 RFC2136 規範的 DNS 伺服器 (例如 BIND named) 所需的各種設施之配置概觀。此功能也俗稱「動態 DNS」。

與其他 cert-manager DNS 整合的同類產品不同，named 比較像是網域名稱伺服器的「瑞士刀」。多年來，它經過高度最佳化，可為單一節點提供最大的垂直延展性，以及透過服務提供者介面提供水平延展性。這種彈性使得無法深入探討使用者可能會遇到的每一種可能的 named 部署。相反地，本文檔將嘗試確保您的伺服器準備好接受來自 cert-manager 的請求 (使用命令列工具)，然後讓兩者協同運作。

交易簽章 ⇒ TSIG

動態 DNS 更新本質上是伺服器查詢，否則可能會傳回資源記錄 (RR)。由於 DNS 伺服器通常會暴露在公共網際網路上，因此如果能夠將未經身份驗證的更新推送到任何回應查詢的伺服器，將立即變得難以接受。

在 named 架構師眼中，此問題空間的通用解決方案有兩個方面。第一個是在區域層級 (例如 example.com) 要求手動啟用更新。在單純的網路中，不要求區域更新具有任何安全性，並且可以設定用戶端，使其能夠在無需任何驗證的情況下提供更新。其中一個有用的例子是使用 DHCP 開機的機器，在這種情況下，機器會知道自己，並且可以設定 DNS 伺服器以接受來自正在設定之位址的更新。

這在 cert-manager 和 DNS01 挑戰等情況下顯然有限制。在此環境中，必須在與 ACME 伺服器協調後建立 TXT RR。在與 ACME 伺服器協商後，網域上發佈的 TXT RR 會驗證該網域是否合法參與建立憑證的程序。在更大的 DNS 環境中，這表示任意參與者 (在此情況下為 cert-manager) 必須能夠將其中一個 KV 對應新增至網域，並在發出憑證後將其刪除。cert-manager 沒有方便的實體特性 (例如 DHCP 配置) 來驗證其請求。

對於這種情況，我們需要能夠簽署傳送到 DNS 伺服器的請求。我們透過 TSIG 或交易簽章來執行此操作。

配置步驟 1 - 設定您的 DNS 伺服器以進行安全動態更新

網路上有許多優良的教學課程，逐步說明如何準備基本 named 伺服器以進行動態更新

更複雜的 name 部署不會使用文字檔，而是可以使用 LDAP 或 SQL 來作為資源記錄的資料庫。另一個問題是中繼資料組態，例如區域中繼資料 (如啟用動態更新或區域的存取控制清單 (ACL)) 的組態。組態太多而無法在此處詳細說明，但您應該能夠找到執行此操作的文件。

無論您的部署為何，此階段的目標與 cert-manager 無關，而是與名為 nsupdate 的工具相關，該工具會產生使用 TSIG 簽署的更新。一旦解決此問題，您就可以更有信心地處理 cert-manager 組態。

使用 nsupdate

大多數配置 BIND named 的路徑都會使用 dnssec-keygen。此命令列工具會產生用於簽署 TSIG 請求的具名私密金鑰。簽署請求時，簽章和私密金鑰的名稱會以未加密的形式附加到請求中。如此一來，當收到請求時，收件者可以使用私密金鑰的名稱來尋找私密金鑰本身、使用它建立新的簽章，並比較兩者以進行接受。

由於有數十種方法可以錯誤配置您的 named 伺服器，我們將使用 nsupdate 來測試伺服器是否按預期運作，然後再開始。 https://debian-administration.org/article/591/Using_the_dynamic_DNS_editor_nsupdate 提供了如何使用此工具的完整分解。

若要開始，我們只需執行 nsupdate -k <keyID>，其中 keyID 是從 dnssec-keygen 傳回的值。這會從磁碟讀取金鑰，並提供命令提示字元來發出命令。一般而言，我們要寫入一個簡單的 TXT RR，並確保我們可以將其刪除。

$ nsupdate -k <keyID>
update add www1.example.com 60 txt testing
send
… test here with `nslookup`
update delete www1.example.com txt
send
… test here with `nslookup`

任何寫入、讀取或刪除記錄的失敗都表示 cert-manager 也無法執行此操作，無論其配置有多完善。

配置步驟 2 - 設定 cert-manager

現在我們可以開始進行有趣的事情了，看看一切是否運作。請記住，我們需要設定 ACME DNS01 發行者和挑戰機制，以及 rfc2136 提供者。由於文件充分涵蓋了其他部分，因此讓我們將重點放在此處的提供者上。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
spec:
  acme:
    ...
    solvers:
    - dns01:
        rfc2136:
          nameserver: <address of authoritative nameserver configured above>
          tsigKeyName: <key name used in `dnssec-keygen`, use something semantically meaningful in both environments>
          tsigAlgorithm: HMACSHA512 // should be matched to the algo you chose in `dnssec-keygen`
          tsigSecretSecretRef:
            name: <the name of the k8s secret holding the TSIG key.. not the key itself!>
            key: <name of the key *inside* the secret>

例如

rfc2136:
         nameserver: 1.2.3.4:53
         tsigKeyName: example-com-secret
         tsigAlgorithm: HMACSHA512
         tsigSecretSecretRef:
           name: tsig-secret
           key: tsig-secret-key

對於此範例配置，我們需要以下兩個命令。第一個命令會在您的 named 伺服器上產生金鑰。請注意，上述 tsigKeyName 和以下 dnssec-keygen 命令中都使用了 example-com-secret。

$ dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n HOST example-com-secret

另請注意，組態和 keygen 命令中都提供了 tsigAlgorithm。它們列在 https://github.com/miekg/dns/blob/v1.0.12/tsig.go#L18-L23。

您在 Kubernetes 端需要的第二個組態位是建立祕密。從上述產生的 <key>.private 檔案中提取秘密金鑰字串，並在以下預留位置中使用該秘密。

$ kubectl -n cert-manager create secret generic tsig-secret --from-literal=tsig-secret-key=<somesecret>

請注意，tsig-secret 和 tsig-secret-key 符合上述 tsigSecretSecretRef 中的組態。

速率限制

在您網域的 SOA RR 中，rfc2136 提供者會等到所有名稱伺服器都回應相同結果後，才會聯絡 Let's Encrypt 以完成挑戰程序。這是因為挑戰伺服器會聯絡執行遞迴查詢 (查詢其未在本機維護的記錄) 的非授權 DNS 伺服器。如果 SOA 中的伺服器不包含正確的值，則非授權伺服器也可能具有錯誤的資訊，導致請求違反速率限制，並最終將程序鎖定。

此程序是為了保護使用者，使其免於伺服器錯誤配置而造成更細微的鎖定，此鎖定會在修復伺服器配置後仍然存在。

如其他位置所述，在正式使用生產伺服器之前，使用 ACME 測試伺服器完整偵錯配置是謹慎的做法。測試伺服器的速率限制較不嚴格，但它們發出的憑證並非使用瀏覽器信任的根憑證進行簽署。

下一步是什麼？

到目前為止，這個設定實際上不會做任何事情。您仍然必須按照這裡的說明請求憑證。一旦請求憑證，提供者將開始處理請求。

疑難排解

  • 請務必先使用 nsupdate 完全測試 DNS 伺服器更新。理想情況下，這應該從與 rfc2136 提供者位於相同命名空間的 Pod 中完成，以確保沒有防火牆問題。
  • cert-manager Pod 的日誌對您很有幫助。可以透過將 --v=5 引數新增至容器啟動來產生其他日誌。
  • TSIG 金鑰以 base64 編碼，但 Kubernetes API 伺服器也期望金鑰字面值在儲存之前被解碼。在某些情況下，金鑰必須被雙重編碼。（如果您已使用 nsupdate 進行測試，當您遇到此問題時很容易發現。）
  • 請注意您正在使用的區域的重新整理時間。對於流量較低的區域，在取得初始憑證時，將重新整理時間縮短到約五分鐘並不會產生顯著差異。一旦流程正常運作，cert-manager 的優點是，由於重新整理時間，即使續訂需要數小時也沒關係，一切都是自動化的！
  • 與其他經常使用 REST API 修改 DNS RR 的提供者相比，此提供者可能需要稍長的時間。您可以 watch kubectl certificate yourcert 來顯示正在發生的情況。整個過程需要五分鐘並不罕見。