主持人 > 博客 > 管理 > 證書管理器 1.0 發布

證書管理器 1.0 發布

如果你問一位經驗豐富、睿智的工程師他對 cert-manager 的看法以及為什麼每個人都使用它，那麼專家會嘆息，自信地擁抱他並疲倦地說：“每個人都使用它，因為沒有明智的選擇。 我們的老鼠會哭、會刺，但會繼續與這種仙人掌共存。 我們為什麼愛？ 因為它有效。 我們為什麼不愛？ 因為使用新功能的新版本不斷出現。 而且你必須一遍又一遍地更新集群。 舊版本停止工作，因為有一個陰謀和一個偉大的神秘薩滿教。

但開發商聲稱 證書管理器 1.0 一切都會改變。

我們會相信嗎？

證書管理器 1.0 發布

Cert-manager 是原生的 Kubernetes 證書管理控制器。 它可用於頒發來自各種來源的證書：Let's Encrypt、HashiCorp Vault、Venafi、簽名和自簽名密鑰對。 它還允許您在過期日期之前使密鑰保持最新，並嘗試在證書過期前的指定時間自動續訂證書。 Cert-manager 基於 kube-lego 並且還使用了其他類似項目（例如 kube-cert-manager）的一些技巧。

發行說明

在 1.0 版中，我們為 cert-manager 項目三年的開發打上了信任的標記。 在此期間，它在功能和穩定性方面取得了顯著發展，但最重要的是在社區方面。 今天，我們看到許多人使用它來保護他們的 Kubernetes 集群並將其部署到生態系統的各個部分。 在最近的 16 個版本中修復了很多錯誤。 而該破的就破了。 使用 API 的幾次訪問改進了它與用戶的交互。 我們已經解決了 GitHub 上的 1500 個問題以及來自 253 個社區成員的更多拉取請求。

隨著1.0的發布，我們正式宣布cert-manager是一個成熟的項目。 我們還承諾保持我們的 API 兼容 v1.

非常感謝這三年來幫助我們製作 cert-manager 的每一個人！ 讓 1.0 版成為許多重大事件中的第一個。

1.0 版是一個穩定的版本，有幾個優先領域：

  • v1 應用程序接口；

  • 團隊 kubectl cert-manager status, 幫助分析問題；

  • 使用最新穩定的 Kubernetes API；

  • 改進的日誌記錄；

  • ACME 改進。

升級前一定要閱讀升級說明。

API v1

版本 v0.16 使用 API v1beta1. 這增加了一些結構上的變化，也改進了 API 字段文檔。 版本 1.0 在此基礎上使用 API v1. 這個API是我們第一個穩定的API，同時我們已經給出了兼容性保證，但是隨著API v1 我們承諾在未來幾年保持兼容性。

所做的更改（注意：我們的轉換工具會為您處理一切）：

證書：

  • emailSANs 現在叫 emailAddresses

  • uriSANs - uris

這些更改增加了與其他 SAN 的兼容性（主題替代名稱， 約譯員)，以及 Go API。 我們將從我們的 API 中刪除該術語。

更新

如果您使用的是 Kubernetes 1.16+，轉換 webhook 將允許您同時無縫地使用 API 版本 v1alpha2, v1alpha3, v1beta1 и v1. 有了這些，您將能夠使用新版本的 API，而無需更改或重新部署您的舊資源。 我們強烈建議將您的清單升級到 API v1，因為以前的版本很快就會被棄用。 用戶 legacy 證書管理器的版本仍然只能訪問 v1，可以找到升級步驟 這裡.

kubectl 證書管理器狀態命令

隨著我們對擴展的新改進 kubectl 調查與未頒發證書有關的問題變得更加容易。 kubectl cert-manager status 現在提供了有關證書的更多信息，還顯示了證書頒發階段。

安裝擴展後，您可以運行 kubectl cert-manager status certificate <имя-сертификата>，如果使用來自 ACME 的證書，它將查找具有給定名稱的證書和任何相關資源，例如 CertificateRequest、Secret、Issuer、Order 和 Challenges。

調試尚未準備好的證書的示例：

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

該命令還可以幫助您詳細了解證書的內容。 Letsencrypt 頒發的證書的詳細示例：

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

使用最新穩定的 Kubernetes API

Cert-manager 是最早實施 Kubernetes CRD 的公司之一。 這一點，以及我們對 Kubernetes 1.11 版本的支持，意味著我們需要支持遺留的 apiextensions.k8s.io/v1beta1 也適用於我們的 CRD admissionregistration.k8s.io/v1beta1 對於我們的網絡掛鉤。 它們現在已被棄用，並將在 Kubernetes 1.22 版本中刪除。 在我們的 1.0 版本中，我們現在提供全面支持 apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 對於 Kubernetes 1.16（添加它們的地方）和更新版本。 對於之前版本的用戶，我們繼續提供支持 v1beta1 在我們的 legacy 版本。

改進的日誌記錄

在此版本中，我們將日誌庫更新為 klog/v2，用於 Kubernetes 1.19。 我們還會審查我們撰寫的每份期刊，以確保它被分配了適當的級別。 我們以此為指導 來自 Kubernetes 的指導. 有五個（實際上是六個， 約譯員) 日誌級別從 Error （0 級），它只打印重要錯誤，並以 Trace （第 5 級）這將幫助您準確了解正在發生的事情。 通過此更改，如果您在運行 cert-manager 時不需要調試信息，我們會減少日誌數量。

提示：cert-manager 默認運行在 level 2 (Info), 你可以使用 global.logLevel 在頭盔圖中。

注意：查看日誌是進行故障排除時的最後手段。 有關更多信息，請查看我們的 領導.

編者註：要了解更多關於 Kubernetes 的工作原理，從實踐教師那裡獲得寶貴的建議，以及優質的技術支持幫助，您可以參加在線強化 Kubernetes 基地，將於 28 月 30 日至 XNUMX 日舉行，以及 Kubernetes Mega將於 14 月 16 日至 XNUMX 日舉行。

ACME 改進

cert-manager 最常見的用途可能與使用 ACME 從 Let's Encrypt 頒發證書有關。 1.0 版以使用社區反饋為我們的 ACME 發行者添加兩個小但重要的改進而著稱。

禁用帳戶密鑰生成

如果您大量使用 ACME 證書，您很可能在多個集群上使用同一個帳戶，因此您的證書頒發限制將適用於所有這些。 在復制中指定的秘密時，這在 cert-manager 中已經是可能的 privateKeySecretRef. 這個用例有很多問題，因為 cert-manager 試圖提供幫助，如果找不到的話，它會很高興地創建一個新的帳戶密鑰。 這就是為什麼我們添加 disableAccountKeyGeneration如果您將此選項設置為 true - cert-manager 不會生成密鑰，並會警告您尚未為其提供帳戶密鑰。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

優選鏈

29 月 XNUMX 日讓我們加密 將傳遞 到您自己的根 CA ISRG Root. 交叉簽名證書將被替換為 Identrust. 此更改不需要更改證書管理器設置，在此日期之後頒發的所有更新或新證書都將使用新的根 CA。

Let's Encrypt 已經使用此 CA 簽署了證書，並通過 ACME 將它們作為“備用證書鏈”提供。 在此版本的證書管理器中，可以在頒發者設置中設置對這些鏈的訪問。 在參數 preferredChain 您可以指定正在使用的 CA 的名稱，證書將通過該名稱頒發。 如果與請求匹配的 CA 證書可用，它將向您頒發證書。 請注意，這是首選選項，如果未找到任何內容，將頒發默認證書。 這將確保您在刪除 ACME 頒發者端的備用鏈後仍會續訂證書。

今天您已經可以收到由 ISRG Root， 所以：

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

如果你喜歡離開鏈條 IdenTrust - 將此選項設置為 DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

請注意，此根 CA 將很快被棄用，Let's Encrypt 將使此鏈保持活動狀態，直到 29 年 2021 月 XNUMX 日。

來源： www.habr.com

添加評論