From fdfa669e72f31ccd1076506a296a13fdfd7faed6 Mon Sep 17 00:00:00 2001 From: chenxuc Date: Sat, 4 Dec 2021 20:30:26 +0800 Subject: [PATCH] [zh] sync auth for 1.22 --- .../reference/access-authn-authz/_index.md | 4 +- .../certificate-signing-requests.md | 130 +++++++++++------- .../extensible-admission-controllers.md | 4 +- 3 files changed, 87 insertions(+), 51 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/_index.md b/content/zh/docs/reference/access-authn-authz/_index.md index 4a67bd9440..24df472264 100644 --- a/content/zh/docs/reference/access-authn-authz/_index.md +++ b/content/zh/docs/reference/access-authn-authz/_index.md @@ -1,12 +1,12 @@ --- title: 访问 API -weight: 20 +weight: 15 no_list: true --- diff --git a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md index e9d5e62c65..cd82025d19 100644 --- a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -8,6 +8,7 @@ reviewers: - liggitt - mikedanese - munnerz +- enj title: Certificate Signing Requests content_type: concept weight: 20 @@ -50,6 +51,9 @@ The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing requ the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the recipient that the request is being made to) using the `spec.signerName` field. Note that `spec.signerName` is a required key after api version `certificates.k8s.io/v1`. +In Kubernetes v1.22 and later, clients may optionally set the `spec.expirationSeconds` +field to request a particular lifetime for the issued certificate. The minimum valid +value for this field is `600`, i.e. ten minutes. --> ## 请求签名流程 {#request-signing-process} @@ -57,6 +61,8 @@ CertificateSigningRequest 资源类型允许客户使用它申请发放 X.509 CertificateSigningRequest 对象 在 `spec.request` 中包含一个 PEM 编码的 PKCS#10 签名请求。 CertificateSigningRequest 使用 `spec.signerName` 字段标示 _签名者_（请求的接收方）。 注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。 +在 Kubernetes v1.22 和以后的版本，客户可以可选地设置 `spec.expirationSeconds` +字段来为颁发的证书设定一个特定的有效期。该字段的最小有效值是 `600`，也就是 10 分钟。 为了减少集群中遗留的过时的 CertificateSigningRequest 资源的数量， 一个垃圾收集控制器将会周期性地运行。 @@ -121,7 +129,9 @@ state for some duration: * 已批准的请求：1小时后自动删除 * 已拒绝的请求：1小时后自动删除 -* 挂起的请求：1小时后自动删除 +* 已失败的请求：1小时后自动删除 +* 挂起的请求：24小时后自动删除 +* 所有请求：在颁发的证书过期后自动删除 @@ -159,8 +167,8 @@ This includes: Email subjectAltNames、URI subjectAltNames 等，请求一个受限制的扩展项时的应对手段。 4. **许可的密钥用途/扩展的密钥用途**：当用途和签名者在 CSR 中指定的用途不同时， 相应的限制和应对手段。 -5. **过期时间/证书有效期**：过期时间由签名者确定、由管理员配置，还是由 CSR 对象指定等， - 以及过期时间与签名者在 CSR 中指定过期时间不同时的应对手段。 +5. **过期时间/证书有效期**：过期时间由签名者确定、由管理员配置、还是由 CSR `spec.expirationSeconds` 字段指定等， + 以及签名者决定的过期时间与 CSR `spec.expirationSeconds` 字段不同时的应对手段。 6. **允许/不允许 CA 位**：当 CSR 包含一个签名者并不允许的 CA 证书的请求时，相应的应对手段。 -PKCS#10 签名请求格式不允许设置证书的过期时间或者生命期。因此，证书的过期 -时间或者生命期必须通过类似 CSR 对象的注解字段这种形式来设置。 -尽管让签名者使用过期日期从理论上来讲也是可行的，目前还不存在哪个实现这样做了。 -（内置的签名者都是用相同的 `ClusterSigningDuration` 配置选项，而该选项 -中将生命期的默认值设为 1 年，且可通过 kube-controller-manager 的命令行选项 -`--cluster-signing-duration` 来更改。） +PKCS#10 签名请求格式并没有一种标准的方法去设置证书的过期时间或者生命期。 +因此，证书的过期时间或者生命期必须通过 CSR 对象的 `spec.expirationSeconds` 字段来设置。 +当 `spec.expirationSeconds` 没有被指定时，内置的签名者默认使用 `ClusterSigningDuration` 配置选项 +（kube-controller-manager 的命令行选项 `--cluster-signing-duration`），该选项的默认值设为 1 年。 +当 `spec.expirationSeconds` 被指定时，`spec.expirationSeconds` 和 `ClusterSigningDuration` +中的最小值会被使用。 + +{{< note >}} + +`spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。 +v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。 +{{< /note >}} 1. `kubernetes.io/kube-apiserver-client`：签名的证书将被 API 服务器视为客户证书。 @@ -229,8 +246,8 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 扩展，弃用其他扩展。 1. 许可的密钥用途：必须包含 `["client auth"]`，但不能包含 `["digital signature", "key encipherment", "client auth"]` 之外的键。 - 1. 过期时间/证书有效期：通过 kube-controller-manager 中 `--cluster-signing-duration` - 标志来设置，由其中的签名者实施。 + 1. 过期时间/证书有效期：对于 kube-controller-manager 实现的签名者， + 设置为 `--cluster-signing-duration` 选项和 CSR 对象的 `spec.expirationSeconds` 字段（如有设置该字段）中的最小值。 1. 允许/不允许 CA 位：不允许。 2. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。 @@ -253,8 +270,8 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知 1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头 1. 许可的 x509 扩展：允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` - 1. 过期时间/证书有效期：通过 kube-controller-manager 中签名者的实现所对应的标志 - `--cluster-signing-duration` 来设置。 + 1. 过期时间/证书有效期：对于 kube-controller-manager 实现的签名者， + 设置为 `--cluster-signing-duration` 选项和 CSR 对象的 `spec.expirationSeconds` 字段（如有设置该字段）中的最小值。 1. 允许/不允许 CA 位：不允许。 3. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 API 服务器视为有效的 kubelet 服务证书， @@ -277,8 +295,8 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知 禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。 至少有一个 DNS 或 IP 的 SubjectAltName 存在。 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` - 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 - `--cluster-signing-duration` 来设置。 + 1. 过期时间/证书有效期：对于 kube-controller-manager 实现的签名者， + 设置为 `--cluster-signing-duration` 选项和 CSR 对象的 `spec.expirationSeconds` 字段（如有设置该字段）中的最小值。 1. 允许/不允许 CA 位：不允许。 4. `kubernetes.io/legacy-unknown`: 不保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。 @@ -302,8 +320,8 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知 1. 许可的主体：全部。 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。 1. 许可的密钥用途：全部。 - 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 - `--cluster-signing-duration` 来设置。 + 1. 过期时间/证书有效期：对于 kube-controller-manager 实现的签名者， + 设置为 `--cluster-signing-duration` 选项和 CSR 对象的 `spec.expirationSeconds` 字段（如有设置该字段）中的最小值。 1. 允许/不允许 CA 位 - 不允许。 {{< note >}} @@ -313,6 +331,15 @@ Failures for all of these are only reported in kube-controller-manager logs. 注意：所有这些故障仅在 kube-controller-manager 日志中报告。 {{< /note >}} +{{< note >}} + +`spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。 +v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。 +{{< /note >}} + ## 普通用户 {#normal-user} 为了让普通用户能够通过认证并调用 API，需要执行几个步骤。 首先，该用户必须拥有 Kubernetes 集群签发的证书， -然后将该证书作为 API 调用的 Certificate 头或通过 kubectl 提供。 +然后将该证书提供给 Kubernetes API。 需要注意的几点: - `usage` 字段必须是 '`client auth`' +- `expirationSeconds` 可以设置为更长（例如 `864000` 是十天）或者更短（例如 `3600` 是一个小时） - `request` 字段是 CSR 文件内容的 base64 编码值。 要得到该值，可以执行命令 `cat myuser.csr | base64 | tr -d "\n"`。 @@ -522,19 +549,19 @@ kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.c ``` ### 创建角色和角色绑定 {#create-role-and-role-binding} 创建了证书之后，为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 Role 和 RoleBinding 了。 -下面是为这个新用户创建 Role 的示例脚本： +下面是为这个新用户创建 Role 的示例命令： ```shell kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods @@ -725,6 +752,15 @@ Kubernetes 控制平面实现了每一个 kube-controller-manager 签名所有标记为 approved 的 CSR。 {{< /note >}} +{{< note >}} + +`spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。 +v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。 +{{< /note >}} + 示例准入 Webhook 服务器置 `ClientAuth` 字段为 -[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)， +[空](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39)， 默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。 如果你需要双向 TLS 或其他方式来验证客户端，请参阅 如何[对 apiservers 进行身份认证](#authenticate-apiservers)。