第 2 章 CertificateSigningRequest [certificates.k8s.io/v1]
- 描述
CertificateSigningRequest 对象提供了一种机制,用于通过提交证书签名请求来获取 x509 证书,并使其异步批准并发布。
kubelet 使用这个 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 定义对象的这个表示法的版本化的 schema。服务器应该将识别的模式转换为最新的内部值,并可拒绝未识别的值。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources |
|
| kind 是一个字符串值,代表此对象所代表的 REST 资源。服务器可以从客户端向其提交请求的端点推断。无法更新。采用驼峰拼写法 (CamelCase)。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
| ||
|
| CertificateSigningRequestSpec 包含证书请求。 |
|
| CertificateSigningRequestStatus 包含用于指示请求批准/拒绝/失败状态以及发布的证书的条件。 |
2.1.1. .spec
- 描述
- CertificateSigningRequestSpec 包含证书请求。
- 类型
-
object
- 必填
-
request
-
signerName
-
属性 | 类型 | 描述 |
---|---|---|
|
| expirationSeconds 是签发的证书的请求的持续时间。证书签名者可能会发布具有不同有效期的证书,因此客户端必须检查发布的证书的 notBefore 和 notAfter 字段之间的 delta,以确定实际的持续时间。 只要请求的持续时间没有大于 Kubernetes 控制器管理器的 --cluster-signing-duration CLI 标志,则该字段将遵循这个字段。 证书签名者可能会因为各种原因不遵循此字段: 1. 不了解字段的旧签名者(如 v1.22 之前的树内实现)。配置的最大值少于请求持续时间 3 的签名者。配置的最小值超过请求的持续时间的签名者 expirationSeconds 的最小有效值为 600,即 10 分钟。 |
|
| extra 包含创建 CertificateSigningRequest 的用户的额外属性。创建和不可变时由 API 服务器填充。 |
|
| |
|
| 组包含创建 CertificateSigningRequest 的用户的组成员资格。创建和不可变时由 API 服务器填充。 |
|
| request 包含在 "CERTIFICATE REQUEST" PEM 块中编码的 x509 证书签名请求。当序列化为 JSON 或 YAML 时,数据也是 base64 编码的。 |
|
| signerName 表示请求的签名者,它是合格的名称。 通过 "spec.signerName=NAME" fieldSelector,列出 CertificateSigningRequests 的 list/watch 请求可以在此字段上过滤。 已知的 Kubernetes 符号是:1. "kubernetes.io/kube-apiserver-client": 发布可用于向 kube-apiserver 进行身份验证的客户端证书。对这个 signer 的请求不会被 kube-controller-manager 自动批准,由 kube-controller-manager 中的 "csrsigning" 控制器发出。2. "Kubernetes.io/kube-apiserver-client-kubelet": 发出 kubelet 用来向 kube-apiserver 进行身份验证的客户端证书。此签名人的请求可以由 kube-controller-manager 中的 "csrapproving" 控制器自动批准,并可通过 kube-controller-manager 中的 "csrsigning" 控制器发出。3. "Kubernetes.io/kubelet-serving" 问题提供 kubelet 用来提供 TLS 端点的证书,kube-apiserver 可以安全地连接。对这个 signer 的请求不会被 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.expiration/certificate 生命周期:是否由签名者修复,由管理员配置。6.是否允许对 CA 证书的请求。 |
|
| UID 包含创建 CertificateSigningRequest 的用户的 uid。创建和不可变时由 API 服务器填充。 |
|
| usages 指定一组在签发的证书中请求的密钥使用量。 对 TLS 客户端证书的请求通常请求:"数字签名", "key encipherment", "client auth"。 对 TLS 服务证书的请求通常请求:"key encipherment", "digital signature", "server auth"。 有效值为:"signing", "digital signature", "content commitment", "key encipherment", "key agree", "data encipherment", "cert sign", "crl sign", "encipher only", "decipher only", "any", "server auth", "client auth", "code signing", "code signing", "encipher 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 包含创建 CertificateSigningRequest 的用户的名称。创建和不可变时由 API 服务器填充。 |
2.1.2. .spec.extra
- 描述
- extra 包含创建 CertificateSigningRequest 的用户的额外属性。创建和不可变时由 API 服务器填充。
- 类型
-
对象
2.1.3. .status
- 描述
- CertificateSigningRequestStatus 包含用于指示请求批准/拒绝/失败状态以及发布的证书的条件。
- 类型
-
object
属性 | 类型 | 描述 |
---|---|---|
|
| 证书会在出现 Approved 条件后填充 signer 发布的证书。此字段通过 /status 子资源设置。填充后,此字段不可变。 如果证书签名请求被拒绝,则添加类型为 "Denied" 的条件,此字段仍为空。如果签名者无法发布证书,则添加一个类型为 "Failed" 的条件,此字段仍为空。 验证要求:1. 证书必须包含一个或多个 PEM 块。2.所有 PEM 块都必须具有"CERTIFICATE"标签,不包含标头,编码的数据必须是 BER 编码的 ASN.1 证书结构,如 RFC5280 的第 4 部分所述。3.非PEM 内容可能出现在"CERTIFICATE" PEM 块之前或之后,并允许解释文本,如 RFC7468 第 5.2 节所述。 如果存在多个 PEM 块,并且请求的 spec.signerName 的定义不指明,第一个块是发布的证书,后续的块应被视为中间证书,并在 TLS 握手中显示。 证书以 PEM 格式编码。 当序列化为 JSON 或 YAML 时,数据也是 base64 编码,因此它由以下组成: base64( -----BEGIN CERTIFICATE----- … -----END CERTIFICATE----- ) |
|
| 应用到请求的条件。已知条件为 "Approved", "Denied", 和 "Failed"。 |
|
| CertificateSigningRequestCondition 描述了 CertificateSigningRequest 对象的条件 |
2.1.4. .status.conditions
- 描述
- 应用到请求的条件。已知条件为 "Approved", "Denied", 和 "Failed"。
- 类型
-
array
2.1.5. .status.conditions[]
- 描述
- CertificateSigningRequestCondition 描述了 CertificateSigningRequest 对象的条件
- 类型
-
object
- 必填
-
type
-
status
-
属性 | 类型 | 描述 |
---|---|---|
| lastTransitionTime 是条件最后一次从一个状态转换到另一个状态的时间。如果未设置,当添加新条件类型或现有条件的状态改变时,服务器会把它默认设置为当前时间。 | |
| lastUpdateTime 是最后一次更新到此条件的时间 | |
|
| message 包含人类可读的消息,其中包含有关请求状态的详细信息 |
|
| reason 表示请求状态的简短原因 |
|
| 条件的状态,True, False, Unknown 之一。批准、拒绝和失败条件可能不是"False"或"Unknown"。 |
|
| 条件的类型。已知条件为 "Approved", "Denied", 和 "Failed"。 通过 /approval 子资源添加"Approved"条件,表示请求已批准,应由签名者发布。 通过 /approval 子资源添加 "Denied" 条件,表示请求被拒绝,不应由签名者发出。 一个 "Failed" 条件通过 /status 子资源添加,表示签名者无法发布证书。 批准和拒绝的条件是互斥的。添加后无法删除批准、Denied 和 Failed 条件。 只允许给定类型的一个条件。 |