第2章 CertificateSigningRequest [certificates.k8s.io/v1]


説明

CertificateSigningRequest オブジェクトは、証明書署名要求を送信し、非同期で承認および発行することにより、x509 証明書を取得するメカニズムを提供します。

Kubelets はこの API を使用して以下を取得します。1。kube-apiserver に対して認証するクライアント証明書 ("kubernetes.io/kube-apiserver-client-kubelet" signerName を使用)。2. TLS エンドポイントのサービング証明書 kube-apiserver は安全に接続できます ("kubernetes.io/kubelet-serving" signerName を使用)。

この API を使用して、クライアント証明書に kube-apiserver への認証 ("kubernetes.io/kube-apiserver-client" signerName を使用) を要求したり、カスタムの非 Kubernetes 署名者から証明書を取得したりできます。

タイプ
object
必須
  • spec

2.1. 仕様

プロパティータイプ説明

apiVersion

string

APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。

kind

string

kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。

metadata

ObjectMeta

 

spec

object

CertificateSigningRequestSpec には、証明書要求が含まれています。

status

object

CertificateSigningRequestStatus には、リクエストの承認/拒否/失敗ステータス、および発行された証明書を示すために使用される条件が含まれています。

2.1.1. .spec

説明
CertificateSigningRequestSpec には、証明書要求が含まれています。
タイプ
object
必須
  • request
  • signerName
プロパティータイプ説明

expirationSeconds

integer

expirationSeconds は、発行された証明書の要求された有効期間です。証明書の署名者は、有効期間が異なる証明書を発行する場合があるため、クライアントは、発行された証明書の notBefore フィールドと notAfter フィールドの間のデルタをチェックして、実際の期間を決定する必要があります。

有名な Kubernetes 署名者の v1.22+ ツリー内実装は、要求された期間が、Kubernetes への --cluster-signing-duration CLI フラグに従って尊重する最大期間を超えない限り、このフィールドを尊重します。コントローラーマネージャー。

証明書の署名者は、さまざまな理由でこのフィールドを尊重しない場合があります。

1.フィールドを認識しない古い署名者 (v1.22 より前のツリー内実装など)2。設定された最大値が要求された期間より短い署名者 3。設定された最小値が要求された期間よりも長い署名者

expirationSeconds の有効な最小値は 600、つまり 10 分です。

extra

object

extra には、CertificateSigningRequest を作成したユーザーの追加属性が含まれます。作成時に API サーバーによって入力され、不変です。

extra{}

array (string)

 

groups

array (string)

groups には、CertificateSigningRequest を作成したユーザーのグループメンバーシップが含まれます。作成時に API サーバーによって入力され、不変です。

request

string

要求には、"CERTIFICATE REQUEST" PEM ブロックにエンコードされた x509 証明書署名要求が含まれています。JSON または YAML としてシリアル化される場合、データはさらに base64 でエンコードされます。

signerName

string

signerName は、要求された署名者を示し、修飾された名前です。

CertificateSigningRequests のリスト/ウォッチリクエストは、"spec.signerName=NAME" fieldSelector を使用してこのフィールドでフィルタリングできます。

よく知られている Kubernetes 署名者は次のとおりです。1. "kubernetes.io/kube-apiserver-client": kube-apiserver への認証に使用できるクライアント証明書を発行します。この署名者のリクエストは、kube-controller-manager によって自動承認されることはなく、kube-controller-manager の "csrsigning" コントローラーによって発行できます。2. "kubernetes.io/kube-apiserver-client-kubelet": kubelets が kube-apiserver への認証に使用するクライアント証明書を発行します。この署名者のリクエストは、kube-controller-manager の "csrapproving" コントローラーによって自動承認され、kube-controller-manager の "csrsigning" コントローラーによって発行されます。3. "kubernetes.io/kubelet-serving" は、kubelet が TLS エンドポイントを提供するのに使用する証明書の提供を発行します。これは、kube-apiserver が安全に接続できます。この署名者のリクエストは、kube-controller-manager によって自動承認されることはなく、kube-controller-manager の "csrsigning" コントローラーによって発行できます。

詳細は、https://k8s.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers を参照してください。

カスタム signerNames も指定できます。署名者は次のように定義します:1。信頼の配布: 信頼 (CA バンドル) の配布方法。2.許可された対象: および許可されていない対象が要求された場合の動作。3.要求内の必須、許可、または禁止されている x509 拡張 (subjectAltNames が許可されているかどうか、どのタイプ、許可されている値の制限を含む)、および許可されていない拡張が要求された場合の動作。4.必須、許可、または禁止されているキーの使用法/拡張キーの使用法。5.有効期限/証明書の有効期間: 署名者によって修正されたかどうか、管理者によって設定可能かどうか。6.CA 証明書の要求が許可されるかどうか。

uid

string

uid には、CertificateSigningRequest を作成したユーザーの uid が含まれます。作成時に API サーバーによって入力され、不変です。

usages

array (string)

使用法は、発行された証明書で要求された一連の主要な使用法を指定します。

TLS クライアント証明書の要求は通常、"デジタル署名"、"キー暗号化"、"クライアント認証" を要求します。

TLS サービング証明書の要求は通常、"キー暗号化"、"デジタル署名"、"サーバー認証" を要求します。

有効な値は、"signing"、"digital signature"、"content commitment"、"key encipherment"、"key agreement"、"data encipherment"、"cert sign"、"crl sign"、"encipher only"、"decipher only"、"any"、"server auth"、"client auth"、"code signing"、"email protection"、"s/mime"、"ipsec end system"、"ipsec tunnel"、"ipsec user"、"timestamping"、"ocsp signing"、"microsoft sgc"、"netscape sgc" です。

username

string

username には、CertificateSigningRequest を作成したユーザーの名前が含まれます。作成時に API サーバーによって入力され、不変です。

2.1.2. .spec.extra

説明
extra には、CertificateSigningRequest を作成したユーザーの追加属性が含まれます。作成時に API サーバーによって入力され、不変です。
タイプ
object

2.1.3. .status

説明
CertificateSigningRequestStatus には、リクエストの承認/拒否/失敗ステータス、および発行された証明書を示すために使用される条件が含まれています。
タイプ
object
プロパティータイプ説明

certificate

string

証明書には、承認済み条件が存在した後、署名者によって発行された証明書が入力されます。このフィールドは、/status サブリソースを介して設定されます。一度入力されると、このフィールドは不変です。

証明書署名要求が拒否された場合、タイプ "Denied" の条件が追加され、このフィールドは空のままになります。署名者が証明書を発行できない場合は、タイプ "Failed" の条件が追加され、このフィールドは空のままになります。

検証要件:1. 証明書には 1 つ以上の PEM ブロックが含まれている必要があります。2. すべての PEM ブロックには、"CERTIFICATE" ラベルが付いていて、ヘッダーが含まれていない必要があります。また、エンコードされたデータは、RFC5280 のセクション 4 で説明されている BER エンコードされた ASN.1 証明書構造である必要があります。3. 非 PEM コンテンツは、"CERTIFICATE" PEM ブロックの前または後に表示される場合があり、RFC7468 のセクション 5.2 で説明されている説明テキストを許可するために、検証されていません。

複数の PEM ブロックが存在し、要求された spec.signerName の定義がそれ以外を示さない場合、最初のブロックは発行された証明書であり、後続のブロックは中間証明書として扱われ、TLS ハンドシェイクで提示される必要があります。

証明書は PEM 形式でエンコードされています。

JSON または YAML としてシリアル化される場合、データはさらに base64 でエンコードされるため、次のもので構成されます。

base64( -----BEGIN CERTIFICATE----- …​ -----END CERTIFICATE----- )

conditions

array

リクエストに適用される条件。既知の条件は、"Approved"、"Denied"、および "Failed" です。

conditions[]

object

CertificateSigningRequestCondition は、CertificateSigningRequest オブジェクトの条件を記述します

2.1.4. .status.conditions

説明
リクエストに適用される条件。既知の条件は、"Approved"、"Denied"、および "Failed" です。
タイプ
array

2.1.5. .status.conditions[]

説明
CertificateSigningRequestCondition は、CertificateSigningRequest オブジェクトの条件を記述します
タイプ
object
必須
  • type
  • status
プロパティータイプ説明

lastTransitionTime

Time

lastTransitionTime は、ある状態から別の状態に最後に遷移した時間です。設定されていない場合、新しい条件タイプが追加されるか、既存の条件のステータスが変更されると、サーバーはこれを現在の時刻にデフォルト設定します。

lastUpdateTime

Time

lastUpdateTime は、この条件が最後に更新された時刻です。

message

string

メッセージには、リクエストの状態に関する詳細を含む人間が読めるメッセージが含まれています

reason

string

reason は、リクエスト状態の簡単な理由を示します

status

string

条件のステータス、True、False、Unknown のいずれか。承認、拒否、および失敗の条件は、"False" または "Unknown" ではない場合があります。

type

string

条件の型。既知の条件は、"Approved"、"Denied"、および "Failed" です。

"Approved" 条件は /approval サブリソースを介して追加され、要求が承認され、署名者が発行する必要があることを示します。

"Denied" は /approval サブリソースを介して追加され、要求が拒否されたため、署名者が発行してはならないことを示します。

"Failed" 条件が /status サブリソースを介して追加され、署名者が証明書の発行に失敗したことを示します。

承認された条件と拒否された条件は相互に排他的です。承認済み、拒否済み、および失敗した条件は、一度追加すると削除できません。

特定のタイプの条件は 1 つだけ許可されます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.