功能策略

我们很乐意收到功能请求和 PR，它们可以添加和改进 cert-manager；社区是我们工作核心！

如果你想添加一个功能，我们建议你阅读此文档，以最大程度地提高你的贡献获得关注的机会，并希望能够快速合并！

我们建议你先创建一个问题，以便与 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 问题的链接添加到下一次双周会议的会议记录中，并加入讨论，这样我们就能确保讨论它，并且您也能参与讨论！

大型功能的生命周期

非正式地询问 Slack 或公开会议中的功能
使用设计模板创建包含轻量级设计文档的 PR，以供讨论
设计文档 PR 接受审查 - 可能包括双周会议中的会议或讨论
在命名的 cert-manager 维护者的帮助和审查下实施您的功能

我们很可能拒绝的功能请求

在某些情况下，人们会请求我们之前拒绝或由于某种原因必须拒绝的功能。

这与个人无关；有时我们必须做出艰难的决定，尤其是在安全性和可维护性方面，我们必须拒绝某些提案。如果您的功能请求列在下面，我们很可能必须拒绝它。

也就是说，如果您认为我们犯了错误，并且我们应该重新考虑，我们乐意与您聊天 - 考虑加入我们的双周会议与我们讨论！

在 `k8s.io/` 命名空间之外对 Kubernetes 相关 API 进行打包

打包也打包了 k8s.io/apimachinery 的项目 API（例如 OpenShift、Contour 或 Velero）不建议这样做，因为 Kubernetes 依赖项很可能与 cert-manager 的实例发生冲突。它也可能导致使用不同 Kubernetes 客户端版本时发生冲突。

如果需要，建议使用“动态客户端”将对象转换为复制到 cert-manager 代码库中的内部结构。

Helm 图表的附加配置选项

cert-manager 的 Helm 图表旨在允许创建具有基本配置选项的标准、最佳实践 cert-manager 安装，例如能够为 cert-manager 组件提供标志、标记资源等。我们不打算包含图表创建的资源的每个可能的配置选项，以避免维护负担，因为我们没有针对所有图表配置选项进行自动化测试。因此，我们很可能不会接受向 Helm 图表添加高级或利基配置选项的 PR - 我们建议需要该配置的用户使用其他机制，例如 Helm 的安装后钩子。

Helm + CRD

Helm 建议将 CRD 包含在图表中的 crds/ 子目录中，并包含 crd-install 注释。这具有不幸的副作用，即如果 CRD 在以后的版本中发生更改，它们将不会被升级。

CRD 在没有被删除和重新安装的情况下进行升级对于 cert-manager 的发展至关重要。

这之前曾在 Helm 社区中讨论过。

cert-manager 通过在模板中发送 CRD 来解决此限制。

Helm 子图表功能

cert-manager 现在具有作为子图表安装的功能。

但是，在将其添加到伞形图表时需要小心。

这是因为 cert-manager 安装会创建集群范围的资源，例如准入 Webhook 和自定义资源定义。cert-manager 应该被视为集群的一部分，并且应该像安装其他 Kubernetes 组件一样进行处理。一个合适的比较是负载均衡器控制器或 PV 配置器。

您有责任确保 cert-manager 仅在您的集群中安装一次。这可以通过 condition 参数在您的 Chart.yaml 中的依赖项中进行管理，该参数允许用户禁用子图表的安装。在将 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

秘密注入或复制

cert-manager 处理非常敏感的信息（您所有服务的 TLS 证书），并对秘密资源具有集群级访问权限。因此，在设计功能时，我们需要考虑所有可能被滥用来提升特权的方式。

机密数据应该安全地存储在 Secret 资源中，并且对于未经授权的用户具有范围狭窄的访问权限。因此，我们通常不会添加任何允许将此数据复制/注入到除 Kubernetes Secret 之外的任何资源的功能。

cainjector

cainjector 组件是此规则的一个特殊例外，因为它处理非敏感信息（CA，而不是证书/密钥对）。该组件能够将 ca.crt 文件注入到 ValidatingWebhookConfiguration、MutatingWebhookConfiguration 和 CustomResourceDefinition 资源上的预定义字段中，这些字段来自证书资源。

这三个组件的范围已经限定为特权用户，并且将为您提供对资源的集群范围访问权限。

如果您正在设计需要 CA 证书或 TLS 密钥对的资源，强烈建议使用对密钥的引用，而不是将其嵌入到资源中。

跨命名空间资源

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 访问的证书来提升权限。

请参阅我们的常见问题解答，以了解有关此问题的更多详细信息。

与第三方基础设施提供商的集成

我们尽量不在 cert-manager 的核心代码中包含涉及调用我们没有基础设施测试的第三方 API（或维护人员没有技能可以处理的 API）的新功能。

相反，我们尝试构建诸如外部 DNS webhook 解決器之类的接口，这些接口可以实现以将 cert-manager 与特定的第三方实现一起使用。我们认为这是一个更可持续的方法，因为这样一来，了解和熟练使用特定基础设施的人就可以拥有一个与之交互的项目，并且可以让我们避免将可能未经测试的代码合并到 cert-manager 的核心代码中。一个可能会被拒绝的 PR 示例是添加新的外部 DNS 解決器类型，请参阅 https://github.com/cert-manager/cert-manager/pull/1088