新着情報: プロジェクトの最新情報を入手TwitterとMastodon

機能ポリシー

私たちは、cert-managerの機能追加や改善に貢献する機能リクエストとPRの両方を歓迎します。コミュニティは私たちの活動の中心です！

機能追加を検討されている場合は、あなたの貢献が相応の注目を集め、うまくいけば迅速にマージされる可能性を最大限に高めるために、このドキュメントを読むことをお勧めします！

まず、cert-managerのメンテナーと議論するために、Issueを作成することをお勧めします。もう一つの可能性は、実装に関するオープンな議論のために、コミュニティミーティングで提起することです。

機能の規模：変更を受け入れてもらうには

私たちは、新しい機能やPRを、その規模と重要度に基づいて評価します。それらは、小さいか大きいかのどちらかです。

小規模な機能

多くの貢献は小規模です。通常 - 必ずしもそうではありませんが - それらを実装するには、多くのコードを追加または変更する必要はなく、いずれにしてもメンテナーがレビューするのは簡単であるはずです。PRが小さいことは良いことです。もしあなたの機能を縮小して小さくすることができるなら、私たちは文句は言いません！

もしあなたの機能が小さいと思われる場合は、PRを提出し、オプションでcert-manager-dev slackチャンネルにあなたのPRへのリンクを投稿してください。通常、十分に小さいPRは、あまり手間をかけずにマージできます。もしそれが実際にはより大きな作業であると判断した場合は、お知らせします。

大規模な機能

あなたのPRが小さいかどうかわからない場合や、大きいことがわかっている場合は、PRを提出する前に私たちに相談してください。これは、あなたのPRが私たちのマージ対象になる可能性が高いことを保証し、あなたの時間を無駄にしないようにするのに役立ちます。また、設計プロセスも容易になります。

設計ドキュメント

大規模な機能開発は通常、設計に関する議論から始める必要があります。それを始めるには、cert-manager/cert-manager/designに対して、設計ドキュメントを含むPRを提出します。これにより、実装作業を開始する前に提案された機能について議論し、決定とそれらの背後にある理由を文書化する方法として機能します。理想的には、優れた設計ドキュメントは、潜在的な懸念や質問がすべて回答される単一の場所を提供することにより、より迅速かつ一貫性のある機能開発と実装プロセスを可能にする必要があります。

ドキュメントの構成を概説した設計テンプレートがあります。（これは、Kubernetes拡張機能KEPテンプレートの簡略化されたバージョンです）。設計について助けが必要な場合は、お問い合わせください。

設計ドキュメントの議論プロセスには、あなたを含めたビデオ通話が含まれる場合があります！それは、機能がどのように実装され、アプローチされるべきかを計画するのに役立ちます。それはかなり非公式でカジュアルでしょう。私たちは、みんなが同じ認識を持っていることを確認したいだけです。この通話は、隔週のミーティングの一部になる可能性があります。

大規模な機能の進捗状況

設計ドキュメント付きの大規模な機能は、受け入れられる可能性がはるかに高く、結果として、PRを成功させるために、単一の指名されたcert-managerメンテナーが努力することを約束する可能性もはるかに高くなります。そのメンテナーはあなたのすべての質問に答えられないかもしれませんが、正しい方向を示すことができるはずです。

機能について議論するために連絡を取るには、cert-manager-dev slackチャンネルに連絡するか、cert-managerの公開ミーティングに参加して提案について話し合ってください。

設計ドキュメントを含むオープンなPRをお持ちの場合（または、設計の進め方について質問がある場合）、設計を含むPRまたは関連するGitHub Issueへのリンクを、次回の隔週ミーティングのミーティングノートに追加して、議論に貢献できるように、ぜひ参加してください。

大規模な機能のライフサイクル

  1. Slackまたは公開ミーティングで機能について非公式に質問する
  2. 議論のために、設計テンプレートを使用して、軽量な設計ドキュメントを含むPRを作成する
  3. 設計ドキュメントPRがレビューされる - 隔週のミーティングでのミーティングまたは議論が含まれる可能性がある
  4. 指名されたcert-managerメンテナーの支援とレビューを受けながら、機能を実装する

私たちが却下する可能性の高い機能リクエスト

場合によっては、以前に却下した機能や、何らかの理由で却下する必要がある機能を要求する人がいます。

個人的なことではありません。時として、難しい選択をしなければならないことがあり、特にセキュリティと保守性に関しては、特定の提案を却下する必要があります。あなたの機能リクエストが以下にリストされている場合、それを却下しなければならない可能性が高くなります。

そうは言っても、もし私たちが間違いを犯していて、再検討すべきだとお考えの場合は、喜んでお話しします。私たちの隔週のミーティングに参加して、私たちと話し合ってみてください！

OpenShift、Contour、またはVeleroなど、k8s.io/apimachineryもベンダーリングするプロジェクトAPIのベンダーリングは、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のインストールが、アドミッションWebhooksやカスタムリソース定義のようなクラスタースコープのリソースを作成するためです。cert-managerは、クラスタの一部として認識されるべきであり、インストールについても同様に扱う必要があります。他のKubernetesコンポーネントとの適切な比較対象としては、ロードバランサーコントローラーやPVプロビジョナーが挙げられます。

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ファイルを、CertificateリソースからValidatingWebhookConfiguration、MutatingWebhookConfiguration、およびCustomResourceDefinitionリソースの定義済みフィールドに注入できます。

これらの3つのコンポーネントは、すでに特権ユーザーのみにスコープが限定されており、リソースへのクラスタースコープのアクセスを許可します。

CA証明書またはTLSキーペアが必要なリソースを設計している場合は、リソースに埋め込むのではなく、Secretへの参照を使用することを強くお勧めします。

クロスネームスペースリソース

Kubernetesのネームスペース境界は、アクセススコープの障壁を提供します。アプリまたはユーザーは、特定のネームスペースのリソースにのみアクセスするように制限できます。

cert-managerはクラスタ全体のresourceで動作するコントローラーです。そのため、あるネームスペースから別のネームスペースに証明書データをコピーまたは書き込むことを許可するのは興味深く思えるかもしれませんが、これはすべてのユーザーに対してネームスペースセキュリティモデルをバイパスさせる可能性があり、通常は意図されておらず、重大なセキュリティ問題となる可能性があります。

私たちはこの動作をサポートしていません。もしあなたがそれを必要とし、それがあなたのユースケースに意図されていると信じるなら、他のKubernetesコントローラーがこれを実行できますが、非常に注意することをお勧めします。

Kubernetes CAを使用した証明書の署名

Kubernetesには、証明書署名要求APIと、Kubernetesクラスターの認証局（CA）によって証明書署名要求を承認および署名できるkubectl certificatesコマンドがあります。このCAは、通常ノードに使用されます。

このAPIとCLIは、コントロールプレーンの外部のポッドで使用する証明書に署名するために誤用されることがあります。私たちはこれが間違いだと考えています。

Kubernetesクラスターのセキュリティのために、Kubernetes認証局へのアクセスを制限することが重要です。そのような証明書は、Kubernetes APIサーバーに対する攻撃面を増やします。なぜなら、このCAはAPIサーバーに対する認証のための証明書に署名するためです。もしcert-managerがこの証明書を使用した場合、cert-managerリソースを作成する権限を持つユーザーが、APIアクセスで信頼される証明書に署名することで、特権を昇格させることが可能になります。

詳細については、FAQを参照してください。

サードパーティインフラプロバイダーとの統合

私たちは、テストするインフラを持たない（またはメンテナーが作業するスキルを持たない）サードパーティAPIを呼び出す新しい機能を、コアcert-managerに含めないように努めています。

代わりに、特定のサードパーティ実装でcert-managerを使用するために実装できる、外部DNS Webhookソルバーなどのインターフェースを構築しようとしています。特定のインフラストラクチャを操作する知識とスキルを持つ人が、それと対話するプロジェクトを所有でき、テストされていない可能性のあるコードをコアcert-managerにマージすることを回避できるため、これがより持続可能なアプローチだと考えています。拒否される可能性のあるPRの例としては、新しい外部DNSソルバーの種類の追加があります。https://github.com/cert-manager/cert-manager/pull/1088を参照してください。