From 692550eef3e7dcfe79ac6cade511d509ace20a60 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Sat, 18 Nov 2023 19:59:45 +0800 Subject: [PATCH] [zh] sync access-authn-authz/authentication.md Signed-off-by: xin.li --- .../access-authn-authz/authentication.md | 151 +++++++++++------- 1 file changed, 96 insertions(+), 55 deletions(-) diff --git a/content/zh-cn/docs/reference/access-authn-authz/authentication.md b/content/zh-cn/docs/reference/access-authn-authz/authentication.md index 8b7033d25f..92c3c6b116 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/authentication.md +++ b/content/zh-cn/docs/reference/access-authn-authz/authentication.md @@ -16,7 +16,7 @@ weight: 10 本页提供身份认证有关的概述。 @@ -106,7 +106,8 @@ Kubernetes 通过身份认证插件利用客户端证书、持有者令牌(Bea * 用户名:用来辩识最终用户的字符串。常见的值可以是 `kube-admin` 或 `jane@example.com`。 @@ -154,7 +155,7 @@ API 服务器并不保证身份认证模块的运行顺序。 来实现。 ### 启动引导令牌 {#bootstrap-tokens} @@ -308,15 +310,15 @@ how to manage these tokens with `kubeadm`. `kubeadm` 来管理这些令牌。 ### 服务账号令牌 {#service-account-tokens} @@ -457,7 +459,7 @@ ID 令牌是一种由服务器签名的 JWT 令牌,其中包含一些可预知 要识别用户,身份认证组件使用 OAuth2 @@ -495,14 +497,14 @@ sequenceDiagram 1. 登录到你的身份服务(Identity Provider) 2. 你的身份服务将为你提供 `access_token`、`id_token` 和 `refresh_token` @@ -517,16 +519,20 @@ sequenceDiagram 由于用来验证你是谁的所有数据都在 `id_token` 中,Kubernetes 不需要再去联系身份服务。 在一个所有请求都是无状态请求的模型中,这一工作方式可以使得身份认证的解决方案更容易处理大规模请求。 不过,此访问也有一些挑战: 1. Kubernetes 没有提供用来触发身份认证过程的 "Web 界面"。 因为不存在用来收集用户凭据的浏览器或用户接口,你必须自己先行完成对身份服务的认证过程。 @@ -604,20 +610,27 @@ Tremolo Security 的 [OpenUnison](https://openunison.github.io/)。 要在 Kubernetes 环境中使用某身份服务,该服务必须: -1. 支持 [OpenID connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html); - 但事实上并非所有服务都具备此能力 -2. 运行 TLS 协议且所使用的加密组件都未过时 -3. 拥有由 CA 签名的证书(即使 CA 不是商业 CA 或者是自签名的 CA 也可以) +1. 支持 [OpenID connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html); + 但事实上并非所有服务都具备此能力 +2. 运行 TLS 协议且所使用的加密组件都未过时 +3. 拥有由 CA 签名的证书(即使 CA 不是商业 CA 或者是自签名的 CA 也可以) 关于上述第三条需求,即要求具备 CA 签名的证书,有一些额外的注意事项。 如果你部署了自己的身份服务,而不是使用云厂商(如 Google 或 Microsoft)所提供的服务, @@ -642,9 +655,12 @@ Setup instructions for specific systems: ##### Option 1 - OIDC Authenticator -The first option is to use the kubectl `oidc` authenticator, which sets the `id_token` as a bearer token for all requests and refreshes the token once it expires. After you've logged into your provider, use kubectl to add your `id_token`, `refresh_token`, `client_id`, and `client_secret` to configure the plugin. +The first option is to use the kubectl `oidc` authenticator, which sets the `id_token` as a bearer token +for all requests and refreshes the token once it expires. After you've logged into your provider, use +kubectl to add your `id_token`, `refresh_token`, `client_id`, and `client_secret` to configure the plugin. -Providers that don't return an `id_token` as part of their refresh token response aren't supported by this plugin and should use "Option 2" below. +Providers that don't return an `id_token` as part of their refresh token response aren't supported +by this plugin and should use "Option 2" below. --> #### 使用 kubectl {#using-kubectl} @@ -706,7 +722,8 @@ users: ``` 当你的 `id_token` 过期时,`kubectl` 会尝试使用你的 `refresh_token` 来刷新你的 `id_token`,并且在 `.kube/config` 文件的 `client_secret` 中存放 `refresh_token` @@ -816,8 +833,9 @@ contexts: ``` 当客户端尝试在 API 服务器上使用持有者令牌完成身份认证 (如[前](#putting-a-bearer-token-in-a-request)所述)时, @@ -826,8 +844,8 @@ the authentication webhook POSTs a JSON-serialized `TokenReview` object containi Kubernetes 不会强制请求提供此 HTTP 头部。 要注意的是,Webhook API 对象和其他 Kubernetes API 对象一样, @@ -1015,9 +1033,15 @@ API 服务器可以配置成从请求的头部字段值(如 `X-Remote-User`) 这一设计是用来与某身份认证代理一起使用 API 服务器,代理负责设置请求的头部字段值。 * `--requestheader-username-headers` 必需字段,大小写不敏感。 用来设置要获得用户身份所要检查的头部字段名称列表(有序)。 @@ -1034,7 +1058,8 @@ API 服务器可以配置成从请求的头部字段值(如 `X-Remote-User`) {{< note >}} 在 1.13.3 版本之前(包括 1.10.7、1.9.11),附加字段的键名只能包含 [HTTP 头部标签的合法字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)。 @@ -1090,8 +1115,12 @@ certificate to the API server for validation against the specified CA before the checked. WARNING: do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage. -* `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names. -* `--requestheader-allowed-names` Optional. List of Common Name values (CNs). If set, a valid client certificate with a CN in the specified list must be presented before the request headers are checked for user names. If empty, any CN is allowed. +* `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate + must be presented and validated against the certificate authorities in the specified file before the + request headers are checked for user names. +* `--requestheader-allowed-names` Optional. List of Common Name values (CNs). If set, a valid client + certificate with a CN in the specified list must be presented before the request headers are checked + for user names. If empty, any CN is allowed. --> 为了防范头部信息侦听,在请求中的头部字段被检视之前, 身份认证代理需要向 API 服务器提供一份合法的客户端证书,供后者使用所给的 CA 来执行验证。 @@ -1182,9 +1211,14 @@ to the impersonated user info. The following HTTP headers can be used to performing an impersonation request: * `Impersonate-User`: The username to act as. -* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User". -* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` must be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1). -* `Impersonate-Uid`: A unique identifier that represents the user being impersonated. Optional. Requires "Impersonate-User". Kubernetes does not impose any format requirements on this string. +* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. + Optional. Requires "Impersonate-User". +* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. + Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` + must be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) + MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1). +* `Impersonate-Uid`: A unique identifier that represents the user being impersonated. Optional. + Requires "Impersonate-User". Kubernetes does not impose any format requirements on this string. --> 以下 HTTP 头部字段可用来执行伪装请求: @@ -1201,7 +1235,8 @@ The following HTTP headers can be used to performing an impersonation request: {{< note >}} 在 1.11.3 版本之前(以及 1.10.7、1.9.11),`<附加名称>` 只能包含合法的 HTTP 标签字符。 {{< /note >}} @@ -1999,9 +2034,13 @@ The following `ExecCredential` manifest describes a cluster information sample. {{< feature-state for_k8s_version="v1.28" state="stable" >}} @@ -2052,7 +2091,8 @@ Response example: ``` @@ -2164,8 +2204,8 @@ Kubernetes API 服务器在所有身份验证机制 {{< /note >}} 默认情况下,所有经过身份验证的用户都可以在 `APISelfSubjectReview` 特性被启用时创建 `SelfSubjectReview` 对象。 这是 `system:basic-user` 集群角色允许的操作。 @@ -2173,6 +2213,7 @@ It is allowed by the `system:basic-user` cluster role. {{< note >}}