新訊：在Twitter和Mastodon取得專案更新

功能政策

我們樂於收到功能請求和 PR，它們可以增加和改進 cert-manager；社群是我們工作的核心！

如果您正在考慮新增功能，我們建議您閱讀本文檔，以最大限度地提高您的貢獻獲得應有重視的機會，並希望能夠快速合併！

我們建議您先建立一個 issue，以便與 cert-manager 維護者討論。另一種可能性是在社群會議上提出，以公開討論實作方式。

功能大小：讓您的變更被接受

我們會根據新功能和 PR 的大小及其重要性來評估它們；它們可能是小的或大的。

較小的功能

許多貢獻都很小。這通常（但並非總是）意味著實作它們不需要新增或變更許多程式碼行，而且無論如何它們應該很容易讓維護者審查。PR 很小是一件好事；如果您可以縮小您的功能範圍使其更小，我們不會抱怨！

如果您認為您的功能很小，請隨時直接提出 PR，並選擇性地在 cert-manager-dev slack 頻道中發布您的 PR 連結。通常，一個足夠小的 PR 可以不用太多流程就被合併。如果我們認為它實際上是一項較大的工作，我們會通知您。

較大的功能

如果您不確定您的 PR 是否很小，或者您知道它比較大，您會在提出 PR 之前先與我們討論。這將有助於確保您的 PR 是我們可能合併的內容，以避免浪費您的時間。它也會讓我們更容易進行設計過程。

設計文件

較大的功能開發通常應從設計討論開始。若要開始討論，您可以使用設計文件針對 cert-manager/cert-manager/design 提出 PR。這讓我們可以在開始實作工作之前討論擬議的功能，並作為記錄決策及其背後原因的一種方式。理想情況下，一個好的設計文件應透過提供一個回答所有潛在疑慮和問題的單一位置，來實現更快、更一致的功能開發和實作流程。

我們有一個 設計範本，概述了文件的結構。（這是 Kubernetes 增強功能 KEP 範本的簡化版本）。如果您在設計方面需要協助，請與我們聯絡。

討論設計文件過程的一部分也可能包括與您進行視訊通話！這有助於我們規劃功能的實作方式和方法。這會相當非正式且隨意；我們只是想確保我們都在同一頁上。此通話可能會是雙週會議的一部分。

在較大的功能上取得進展

具有設計文件的較大功能更有可能被接受，反之，我們更有可能讓一位指定的 cert-manager 維護者致力於協助 PR 成功。該維護者可能無法回答您的所有問題，但他們肯定應該能夠為您指引正確的方向。

若要聯繫討論功能，請在 cert-manager-dev slack 頻道上與我們聯絡，或加入 cert-manager 公開會議來討論您的提案。

如果您有一個具有設計文件的公開 PR（或對如何進行設計有一些疑問），您絕對可以自由地將您的設計 PR 或相關 GitHub issue 的連結新增至我們下次雙週會議的會議記錄中並參與其中，以便我們肯定會討論它，並且您可以為討論做出貢獻！

大型功能生命週期

  1. 在 slack 或公開會議中非正式地詢問功能
  2. 使用 設計範本建立包含簡要設計文件的 PR，以供討論
  3. 審查設計文件 PR - 可能包括會議或在雙週會議中討論
  4. 在指定的 cert-manager 維護者的協助和審查下，實作您的功能

我們可能拒絕的功能請求

在某些情況下，人們會請求我們之前拒絕過或因某些原因我們必須拒絕的功能。

這不是針對個人的；有時我們必須做出艱難的選擇，尤其是在安全性和可維護性方面，我們必須拒絕某些提案。如果您的功能請求在下面列出，我們很有可能必須拒絕它。

也就是說，如果您認為我們犯了錯誤，並且我們應該重新考慮，我們很樂意與您聊天 - 請考慮加入我們的 雙週會議與我們討論！

不建議供應也供應 k8s.io/apimachinery 的專案 API，例如 OpenShift、Contour 或 Velero，因為 Kubernetes 相依性可能會與 cert-manager 的執行個體衝突。也可能會導致使用不同 Kubernetes 用戶端版本時發生衝突。

如果需要這樣做，建議使用「動態用戶端」將物件轉換為複製到 cert-manager 程式碼庫中的內部結構。

Helm 圖表的其他組態選項

cert-manager 的 Helm 圖表旨在允許建立具有基本組態選項（例如，能夠為 cert-manager 組件提供旗標、標籤資源等）的標準、最佳實務 cert-manager 安裝。我們不打算在圖表建立的資源中包含所有可能的組態選項，以避免維護負擔，並且因為我們沒有所有圖表組態選項的自動化測試。因此，我們很可能不會接受在 Helm 圖表中新增進階或特殊組態選項的 PR - 我們建議需要該組態的使用者使用其他機制，例如 Helm 的安裝後 Hook。

Helm + CRD

Helm 建議將 CRD 包含在圖表的 crds/ 子目錄中，並包含 crd-install 註釋。這樣做的不幸副作用是，如果 CRD 在稍後的版本中變更，則不會升級。

在不移除和重新安裝的情況下升級 CRD 對於 cert-manager 的進展至關重要。

先前已在 Helm 社群中討論過此問題。

cert-manager 透過在範本中傳送 CRD 來解決此限制。

Helm 子圖表功能

cert-manager 現在具備以子圖表形式安裝的功能。

但將其新增至您的總括圖表時需要小心。

這是因為 cert-manager 安裝會建立叢集範圍的資源，例如 admission webhooks 和自訂資源定義。cert-manager 應被視為您叢集的一部分，並且在安裝時應如此對待。與其他 Kubernetes 元件的恰當比較可以是 LoadBalancer 控制器或 PV provisioner。

您有責任確保 cert-manager 在您的叢集中只安裝一次。這可以透過您的 Chart.yaml 中依賴項的 condition 參數來管理，這允許使用者停用子圖表的安裝。當使用 cert-manager 作為子圖表時，必須新增 condition 參數，以允許使用者停用您的依賴項。

apiVersion: v2
name: example_chart
description: A Helm chart with cert-manager as subchart
type: application
version: 0.1.0
appVersion: "0.1.0"
dependencies:
  - name: cert-manager
    version: v1.16.1
    repository: https://charts.jetstack.io
    alias: cert-manager
    condition: cert-manager.enabled

Secret 注入或複製

cert-manager 處理非常敏感的資訊（您所有服務的 TLS 憑證），並具有對 secret 資源的叢集級別存取權。因此，在設計功能時，我們需要考慮所有可能濫用這些 secret 來提升權限的方式。

Secret 資料旨在安全地儲存在 Secret 資源中，並為未經授權的使用者設定狹窄範圍的存取權限。因此，我們通常不會新增任何允許將此資料複製/注入到 Kubernetes Secret 以外的任何資源中的功能。

cainjector

cainjector 元件是此規則的一個特殊例外，因為它處理的是非敏感資訊（CA，而不是憑證/金鑰對）。此元件能夠將 ca.crt 檔案從憑證資源注入到 ValidatingWebhookConfiguration、MutatingWebhookConfiguration 和 CustomResourceDefinition 資源的預定義欄位中。

這 3 個元件已經僅限於特權使用者使用，並且已經提供您叢集範圍的資源存取權。

如果您正在設計需要 CA 憑證或 TLS 金鑰對的資源，強烈建議您使用對 secret 的參考，而不是將其嵌入到資源中。

跨命名空間資源

Kubernetes 中的命名空間邊界為存取範圍提供了屏障。應用程式或使用者可以被限制為僅存取特定命名空間中的資源。

然而，cert-manager 是一個對叢集範圍資源進行操作的控制器，雖然允許複製或寫入從一個命名空間到另一個命名空間的憑證資料似乎很有趣，但這可能會繞過所有使用者的命名空間安全模型，這通常不是故意的，並且可能是一個重大的安全問題。

我們不支援此行為；如果您認為您需要它，並且它是針對您的使用案例，那麼還有其他 Kubernetes 控制器可以做到這一點，儘管我們建議您格外小心。

使用 Kubernetes CA 簽署憑證

Kubernetes 具有憑證簽署請求 API 和 kubectl certificates 命令，這允許您核准憑證簽署請求，並使其由 Kubernetes 叢集的憑證授權單位 (CA) 簽署。此 CA 通常用於您的節點。

這個 API 和 CLI 偶爾會被濫用來簽署在控制平面之外的 pod 使用的憑證；我們認為這是一個錯誤。

為了 Kubernetes 叢集的安全，限制對 Kubernetes 憑證授權單位的存取非常重要；此類憑證會增加 Kubernetes API 伺服器的攻擊面，因為此 CA 會簽署用於針對 API 伺服器進行授權的憑證。如果 cert-manager 使用此憑證，則可能允許任何具有建立 cert-manager 資源許可權的使用者透過簽署用於 API 存取的信任憑證來提升權限。

請參閱我們的常見問題以了解更多詳細資訊。

與第三方基礎架構提供者的整合

我們嘗試不將涉及呼叫我們沒有基礎架構來測試（或維護人員不具備使用技能）的第三方 API 的新功能包含在核心 cert-manager 中。

相反，我們嘗試建置介面，例如外部 DNS webhook 求解器，可以實作以將 cert-manager 與特定的第三方實作搭配使用。我們認為這是一種更永續的方法，因為這樣一來，擁有使用特定基礎架構的知識和技能的人員可以擁有與其互動的專案，並且它讓我們避免將可能未經測試的程式碼合併到核心 cert-manager 中。一個可能被拒絕的 PR 範例是新增一種新的外部 DNS 求解器類型，請參閱 https://github.com/cert-manager/cert-manager/pull/1088