新着：プロジェクトのアップデートをTwitterとMastodonで確認できます。

CertificateRequest リソース

apiVersion: cert-manager.io/v1
kind: CertificateRequest

`CertificateRequest` は、cert-manager内の名前空間付きリソースであり、`Issuer`からX.509証明書を要求するために使用されます。このリソースには、参照されたIssuerに送信されるPEMエンコードされた証明書要求のbase64エンコードされた文字列が含まれています。発行が成功すると、証明書署名要求に基づいて署名された証明書が返されます。`CertificateRequests`は通常、コントローラーまたはその他のシステムによって消費および管理され、特に必要でない限り、人間が使用するべきではありません。

シンプルな`CertificateRequest`は、以下のようになります。

apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  name: my-ca-cr
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQzNqQ0NBY1lDQVFBd2daZ3hDekFKQmdOVkJBWVRBbHBhTVE4d0RRWURWUVFJREFaQmNHOXNiRzh4RFRBTApCZ05WQkFjTUJFMXZiMjR4RVRBUEJnTlZCQW9NQ0VwbGRITjBZV05yTVJVd0V3WURWUVFMREF4alpYSjBMVzFoCmJtRm5aWEl4RVRBUEJnTlZCQU1NQ0dwdmMyaDJZVzVzTVN3d0tnWUpLb1pJaHZjTkFRa0JGaDFxYjNOb2RXRXUKZG1GdWJHVmxkWGRsYmtCcVpYUnpkR0ZqYXk1cGJ6Q0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQwpBUW9DZ2dFQkFLd01tTFhuQkNiRStZdTIvMlFtRGsxalRWQ3BvbHU3TlZmQlVFUWl1bDhFMHI2NFBLcDRZQ0c5Cmx2N2kwOHdFMEdJQUgydnJRQmxVd3p6ZW1SUWZ4YmQvYVNybzRHNUFBYTJsY2NMaFpqUlh2NEVMaER0aVg4N3IKaTQ0MWJ2Y01OM0ZPTlRuczJhRkJYcllLWGxpNG4rc0RzTEVuZmpWdXRiV01Zeis3M3ptaGZzclRJUjRzTXo3cQpmSzM2WFM4UkRjNW5oVVcyYU9BZ3lnbFZSOVVXRkxXNjNXYXVhcHg2QUpBR1RoZnJYdVVHZXlZUUVBSENxZmZmCjhyOEt3YTFYK1NwYm9YK1ppSVE0Nk5jQ043OFZnL2dQVHNLZmphZURoNWcyNlk1dEVidHd3MWdRbWlhK0MyRHIKWHpYNU13RzJGNHN0cG5kUnRQckZrU1VnMW1zd0xuc0NBd0VBQWFBQU1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQgpBUUFXR0JuRnhaZ0gzd0N3TG5IQ0xjb0l5RHJrMUVvYkRjN3BJK1VVWEJIS2JBWk9IWEFhaGJ5RFFLL2RuTHN3CjJkZ0J3bmlJR3kxNElwQlNxaDBJUE03eHk5WjI4VW9oR3piN0FVakRJWHlNdmkvYTJyTVhjWjI1d1NVQmxGc28Kd005dE1QU2JwcEVvRERsa3NsOUIwT1BPdkFyQ0NKNnZGaU1UbS9wMUJIUWJSOExNQW53U0lUYVVNSFByRzJVMgpjTjEvRGNMWjZ2enEyeENjYVoxemh2bzBpY1VIUm9UWmV1ZEp6MkxmR0VHM1VOb2ppbXpBNUZHd0RhS3BySWp3ClVkd1JmZWZ1T29MT1dNVnFNbGRBcTlyT24wNHJaT3Jnak1HSE9tTWxleVdPS1AySllhaDNrVDdKU01zTHhYcFYKV0ExQjRsLzFFQkhWeGlKQi9Zby9JQWVsCi0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  isCA: false
  usages:
  - signing
  - digital signature
  - server auth
  # 90 days
  duration: 2160h
  issuerRef:
    name: ca-issuer
    # We can reference ClusterIssuers by changing the kind here.
    # The default value is Issuer (i.e. a locally namespaced Issuer)
    kind: Issuer
    group: cert-manager.io

この`CertificateRequest`により、cert-managerはデフォルトのIssuerグループ`cert-manager.io`内の`Issuer` `ca-issuer`への証明書要求を試行し、証明書署名要求に基づいた証明書を返します。`issuerRef` 内に他のグループを指定することで、インストール済みの他の外部のサードパーティIssuerにターゲットIssuerを変更できます。

このリソースは、証明書をCAとして指定したり、キーの使用法や要求された有効期間を指定するオプションも提供します。

`CertificateRequest`の`spec`内のすべてのフィールドと、cert-managerによって管理されるアノテーションは、作成後に変更できません（イミュータブルです）。

証明書署名要求の発行が成功すると、リソースが更新され、署名された証明書、証明書のCA（利用可能な場合）、および`Ready`状態が`True`に設定されます。

証明書署名要求の発行が成功したかどうかにかかわらず、発行の再試行は行われません。`CertificateRequests`のロジックとライフサイクルを管理するのは、他のコントローラーの責任です。

状態

`CertificateRequests`には、コントローラーまたはサービスがリソースに対する次のアクションを決定するために使用および依存する必要がある、厳密に定義された状態のセットがあります。

準備完了

各準備完了状態は、`Ready`（ブール値）と`Reason`（文字列）のペアで構成されています。値と意味のセットは以下のとおりです。

準備完了理由状態の意味
False保留中`CertificateRequest`は現在保留中で、他の操作が行われるのを待っています。これは、`Issuer`がまだ存在しないか、`Issuer`が証明書を発行している最中である可能性があります。
False失敗証明書の発行に失敗しました。返された証明書のデコードに失敗したか、署名に使用された参照されたIssuerのインスタンスが失敗しました。コントローラーによって`CertificateRequest`に対してはこれ以上の操作が行われず、最終的に失敗したと見なすことができます。
True発行済み参照された`Issuer`によって署名付き証明書が正常に発行されました。

この状態は、Issuerによって設定される必要があります。

拒否

拒否理由状態の意味
True<承認者の名前>`CertificateRequest`は承認者によって拒否されました。この`CertificateRequest`は、最終的に失敗したと見なすことができます。

この状態は、承認者のみが設定する必要があります。

承認

承認理由状態の意味
True<承認者の名前>`CertificateRequest`は承認者によって承認されました。この`CertificateRequest`は承認されており、Issuerによって発行できます。

この状態は、承認者のみが設定する必要があります。

無効な要求

無効な要求理由状態の意味
True<理由>`CertificateRequest`は無効です。この`CertificateRequest`は、最終的に失敗したと見なすことができます。

ユーザー情報

`CertificateRequests`には、`UserInfo`フィールドのセット（`username`、`groups`、`uid`、`extra`）がspecの一部として含まれています。これらの値には、`CertificateRequest`を作成したユーザーが含まれます。`CertificateRequest`が`Certificate`リソースによって作成された場合、このユーザーはcert-manager自体になり、そうでない場合は、`CertificateRequest`を直接作成したユーザーになります。

警告：これらのフィールドはcert-managerによって管理されており、他のものによって設定または変更されるべきではありません。`CertificateRequest`が作成されると、これらのフィールドは上書きされ、それらを変更しようとするすべての要求は拒否されます。

承認

CertificateRequestsは`Approved`または`Denied`にすることができます。これらの相互に排他的な状態は、管理対象の署名者によってCertificateRequestが署名されることを妨げます。

  • 署名者は、`Approved`状態がない管理対象のCertificateRequestに署名するべきではありません。
  • 署名者は、`Approved`状態の管理対象のCertificateRequestに署名します。
  • 署名者は、`Denied`状態の管理対象のCertificateRequestに署名することはありません。

これらの状態は永続的で、設定後に変更することはできません。

NAMESPACE      NAME                    APPROVED   DENIED   READY   ISSUER       REQUESTOR                                         AGE
istio-system   service-mesh-ca-whh5b   True                True    mesh-ca      system:serviceaccount:istio-system:istiod         16s
istio-system   my-app-fj9sa                       True             mesh-ca      system:serviceaccount:my-app:my-app               4s

動作

`Approved`状態と`Denied`状態は、CertificateRequestの2つの異なる状態タイプです。これらの状態はTrueの状態のみでなければならず、相互に排他的です（つまり、CertificateRequestは同時に`Approved`状態と`Denied`状態を持つことはできません）。この動作は、cert-managerの検証承認Webhookで強制されています。

「承認者」とは、`Approved`/`Denied`状態を設定する責任を負うエンティティです。どのCertificateRequestsがその承認者によって管理されるかは、承認者の実装によって異なります。

`Approved`/`Denied`状態の`Reason`フィールドには、状態を設定したユーザーを設定する必要があります。ユーザーは、承認者の実装にとって意味のあるように解釈できます。たとえば、承認ポリシコントローラーのAPIグループ、または手動リクエストのクライアントエージェントを含めることができます。

`Approved`/`Denied`状態の`Message`フィールドには、状態が設定された理由を設定する必要があります。同様に、理由は、承認者の実装にとって意味のあるように解釈できます。たとえば、この要求を承認するリソースの名前、要求が拒否された原因となった違反、または要求を手動で承認したチームを含めることができます。

承認者コントローラー

デフォルトでは、cert-managerは内部承認コントローラを実行します。これは、任意のネームスペース内のすべての内部発行者タイプを参照するすべてのCertificateRequestを自動的に承認します。 cert-manager.io/Issuer、cert-manager.io/ClusterIssuer。

内部自動承認機能の無効化

このコントローラを無効にするには、HelmチャートでdisableAutoApprovalの値をtrueに設定します。

# ⚠️ This Helm option is only available in cert-manager v1.15.0 and later.
--set disableAutoApproval=true

内部自動承認機能を使用した追加の発行者の承認

あるいは、内部承認コントローラが外部発行者を参照するCertificateRequestを承認するようにするには、HelmチャートでapproveSignerNamesリストに発行者を追加するか、すべての発行者（内部と外部）を承認するためにapproveSignerNamesの値を空リストに設定します。

# ⚠️ This Helm option is only available in cert-manager v1.15.0 and later.
--set approveSignerNames[0]="issuers.cert-manager.io/*" \
--set approveSignerNames[1]="clusterissuers.cert-manager.io/*" \
\
--set approveSignerNames[2]="issuers.my-issuer.example.com/*" \
--set approveSignerNames[3]="clusterissuers.my-issuer.example.com/*"

RBAC構文

ユーザーまたはコントローラがCertificateRequestの承認または拒否を試行すると、cert-manager Webhookは、それを行うための十分な権限を持っているかどうかを評価します。これらの権限は、リクエスト自体、特にリクエストのIssuerRefに基づいています。

apiGroups: ["cert-manager.io"]
resources: ["signers"]
verbs: ["approve"]
resourceNames:
 # namesapced signers
 - "<signer-resource-name>.<signer-group>/<signer-namespace>.<signer-name>"
 # cluster scoped signers
 - "<signer-resource-name>.<signer-group>/<signer-name>"
 # all signers of this resource name
 - "<signer-resource-name>.<signer-group>/*"

クラスタスコープのmyissuers外部発行者を参照するCertificateRequestの承認済みおよび拒否済みの状態を設定するための権限を、グループmy-example.io、名前myappで付与するClusterRoleの例です。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: my-example-io-my-issuer-myapp-approver
rules:
  - apiGroups: ["cert-manager.io"]
    resources: ["signers"]
    verbs: ["approve"]
    resourceNames: ["myissuers.my-example.io/myapp"]

承認者に、上記で定義されている承認済みまたは拒否済みの状態を設定するための十分な権限がない場合、リクエストはcert-manager検証アドミッションWebhookによって拒否されます。

  • RBAC権限は、クラスタスコープで必ず付与する必要があります。
  • 名前空間付き署名は、<signer-resource-name>.<signer-group>/<signer-namespace>.<signer-name>の構文を使用して、名前空間付きリソースとして表されます。
  • クラスタスコープ署名は、<signer-resource-name>.<signer-group>/<signer-name>の構文を使用して表されます。
  • 承認者は、<signer-resource-name>.<signer-group>/*を使用して、すべてのネームスペースに対する承認を付与できます。
  • apiGroupは必ずcert-manager.ioである必要があります。
  • リソースは必ずsignersである必要があります。
  • 動詞は必ずapproveでなければならず、これにより、承認者に承認済みと拒否済みの両方の状態を設定する権限が付与されます。

すべてのネームスペースのすべてのmyissuer署名者、および名前がmyappであるclustermyissuersを、my-example.ioグループで署名する例です。

resourceNames: ["myissuers.my-example.io/*", "clustermyissuers.my-example.io/myapp"]

ネームスペースfooとbarで、名前がmyappであるmyissuerを署名する例です。

resourceNames: ["myissuers.my-example.io/foo.myapp", "myissuers.my-example.io/bar.myapp"]

開発者向け内部動作図