Merge pull request #37696 from windsonsea/calay
[zh] sync configure-aggregation-layer.mdpull/37614/head
Kubernetes Prow Robot
GitHub
commit
adf6dda78b
|
|
@ -18,27 +18,26 @@ weight: 10
|
|||
<!--
|
||||
Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
-->
|
||||
配置[聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心
|
||||
Kubernetes API 的一部分。
|
||||
配置[聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)可以允许
|
||||
Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the Kubernetes general CA.
|
||||
-->
|
||||
{{< note >}}
|
||||
要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
|
||||
需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA，
|
||||
因此请确保代理是由聚合层 CA 签名的，而不是由 Kubernetes 通用 CA 签名的。
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
|
||||
-->
|
||||
{{< caution >}}
|
||||
对不同的客户端类型重复使用相同的 CA 会对集群的功能产生负面影响。
|
||||
有关更多信息，请参见 [CA 重用和冲突](#ca-reusage-and-conflicts)。
|
||||
{{< /caution >}}
|
||||
|
|
@ -52,11 +51,11 @@ Unlike Custom Resource Definitions (CRDs), the Aggregation API involves another
|
|||
|
||||
This section describes how the authentication and authorization flows work, and how to configure them.
|
||||
-->
|
||||
## 身份认证流程
|
||||
## 身份认证流程 {#authentication-flow}
|
||||
|
||||
与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API
|
||||
还涉及另一个服务器：扩展 apiserver。
|
||||
Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver
|
||||
Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver
|
||||
也需要与 Kubernetes apiserver 通信。
|
||||
为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。
|
||||
|
||||
|
|
@ -84,13 +83,15 @@ The rest of this section describes these steps in detail.
|
|||
|
||||
The flow can be seen in the following diagram.
|
||||
|
||||
.
|
||||
|
||||
The source for the above swimlanes can be found in the source of this document.
|
||||
-->
|
||||
本节的其余部分详细描述了这些步骤。
|
||||
|
||||
该流程可以在下图中看到。
|
||||
|
||||
.
|
||||
|
||||
|
||||
以上泳道的来源可以在本文档的源码中找到。
|
||||
|
||||
|
|
@ -222,7 +223,7 @@ Everything to this point has been standard Kubernetes API requests, authenticati
|
|||
|
||||
The Kubernetes apiserver now is prepared to send the request to the extension apiserver.
|
||||
-->
|
||||
### Kubernetes Apiserver 认证和授权
|
||||
### Kubernetes Apiserver 认证和授权 {#kubernetes-apiserver-authentication-and-authorization}
|
||||
|
||||
由扩展 apiserver 服务的对 API 路径的请求以与所有 API 请求相同的方式开始：
|
||||
与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在
|
||||
|
|
@ -231,10 +232,10 @@ Kubernetes apiserver 中注册。
|
|||
用户与 Kubernetes apiserver 通信，请求访问路径。
|
||||
Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定路径的鉴权。
|
||||
|
||||
有关对 Kubernetes 集群认证的概述，请参见
|
||||
[对集群认证](/zh-cn/docs/reference/access-authn-authz/authentication/)。
|
||||
有关对Kubernetes集群资源的访问鉴权的概述，请参见
|
||||
[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)。
|
||||
有关对 Kubernetes 集群认证的概述，
|
||||
请参见[对集群认证](/zh-cn/docs/reference/access-authn-authz/authentication/)。
|
||||
有关对 Kubernetes 集群资源的访问鉴权的概述，
|
||||
请参见[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)。
|
||||
|
||||
到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
|
||||
|
||||
|
|
@ -250,7 +251,7 @@ The Kubernetes apiserver now will send, or proxy, the request to the extension a
|
|||
|
||||
In order to provide for these two, you must configure the Kubernetes apiserver using several flags.
|
||||
-->
|
||||
### Kubernetes Apiserver 代理请求
|
||||
### Kubernetes Apiserver 代理请求 {#kubernetes-apiserver-proxies-the-request}
|
||||
|
||||
Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。
|
||||
为此，它需要了解几件事：
|
||||
|
|
@ -258,8 +259,8 @@ Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求
|
|||
1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展
|
||||
apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？
|
||||
|
||||
2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求
|
||||
已通过认证的用户名和组？
|
||||
2. Kubernetes apiserver 应该如何通知扩展 apiserver
|
||||
原始请求已通过认证的用户名和组？
|
||||
|
||||
为提供这两条信息，你必须使用若干标志来配置 Kubernetes apiserver。
|
||||
|
||||
|
|
@ -295,12 +296,12 @@ Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来向
|
|||
1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 `--requestheader-client-ca-file` 中。
|
||||
2. 连接必须使用客户端证书，该客户端证书的 CN 是 `--requestheader-allowed-names` 中列出的证书之一。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
|
||||
-->
|
||||
{{< note >}}
|
||||
你可以将此选项设置为空白，即为`--requestheader-allowed-names=""`。
|
||||
这将向扩展 apiserver 指示**任何** CN 是可接受的。
|
||||
这将向扩展 apiserver 指示**任何** CN 都是可接受的。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -314,8 +315,8 @@ Note that the same client certificate is used by the Kubernetes apiserver to aut
|
|||
使用这些选项启动时，Kubernetes apiserver 将：
|
||||
|
||||
1. 使用它们向扩展 apiserver 认证。
|
||||
2. 在 `kube-system` 命名空间中
|
||||
创建一个名为 `extension-apiserver-authentication` 的 ConfigMap，
|
||||
2. 在 `kube-system` 命名空间中创建一个名为
|
||||
`extension-apiserver-authentication` 的 ConfigMap，
|
||||
它将在其中放置 CA 证书和允许的 CN。
|
||||
反过来，扩展 apiserver 可以检索这些内容以验证请求。
|
||||
|
||||
|
|
@ -341,9 +342,9 @@ These header names are also placed in the `extension-apiserver-authentication` c
|
|||
它在其代理请求的 HTTP 头部中提供这些。你必须将要使用的标头名称告知
|
||||
Kubernetes apiserver。
|
||||
|
||||
* 通过`--requestheader-username-headers` 标明用来保存用户名的头部
|
||||
* 通过`--requestheader-group-headers` 标明用来保存 group 的头部
|
||||
* 通过`--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部
|
||||
* 通过 `--requestheader-username-headers` 标明用来保存用户名的头部
|
||||
* 通过 `--requestheader-group-headers` 标明用来保存 group 的头部
|
||||
* 通过 `--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部
|
||||
|
||||
这些头部名称也放置在 `extension-apiserver-authentication` ConfigMap 中，
|
||||
因此扩展 apiserver 可以检索和使用它们。
|
||||
|
|
@ -363,13 +364,13 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
|
|||
* Has a CN in the list of allowed CNs, unless the list is blank, in which case all CNs are allowed.
|
||||
* Extract the username and group from the appropriate headers
|
||||
-->
|
||||
### 扩展 Apiserver 认证
|
||||
### 扩展 Apiserver 认证请求 {#extension-apiserver-authenticates-the-request}
|
||||
|
||||
扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后，
|
||||
必须验证该请求确实确实来自有效的身份验证代理，
|
||||
该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证：
|
||||
|
||||
1. 如上所述，从`kube-system`中的 configmap 中检索以下内容：
|
||||
1. 如上所述，从 `kube-system` 中的 ConfigMap 中检索以下内容：
|
||||
|
||||
* 客户端 CA 证书
|
||||
* 允许名称（CN）列表
|
||||
|
|
@ -379,7 +380,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
|
|||
|
||||
* 由其证书与检索到的 CA 证书匹配的 CA 签名。
|
||||
* 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
|
||||
* 从适当的头部中提取用户名和组
|
||||
* 从适当的头部中提取用户名和组。
|
||||
|
||||
<!--
|
||||
If the above passes, then the request is a valid proxied request from a legitimate authenticating proxy, in this case the Kubernetes apiserver.
|
||||
|
|
@ -406,7 +407,7 @@ The extension apiserver now can validate that the user/group retrieved from the
|
|||
|
||||
In order for the extension apiserver to be authorized itself to submit the `SubjectAccessReview` request to the Kubernetes apiserver, it needs the correct permissions. Kubernetes includes a default `ClusterRole` named `system:auth-delegator` that has the appropriate permissions. It can be granted to the extension apiserver's service account.
|
||||
-->
|
||||
### 扩展 Apiserver 对请求鉴权
|
||||
### 扩展 Apiserver 对请求鉴权 {#extensions-apiserver-authorizes-the-request}
|
||||
|
||||
扩展 apiserver 现在可以验证从标头检索的`user/group`是否有权执行给定请求。
|
||||
通过向 Kubernetes apiserver 发送标准
|
||||
|
|
@ -426,7 +427,7 @@ If the `SubjectAccessReview` passes, the extension apiserver executes the reques
|
|||
|
||||
Enable the aggregation layer via the following `kube-apiserver` flags. They may have already been taken care of by your provider.
|
||||
-->
|
||||
### 扩展 Apiserver 执行
|
||||
### 扩展 Apiserver 执行 {#enable-kubernetes-apiserver-flags}
|
||||
|
||||
如果 `SubjectAccessReview` 通过，则扩展 apiserver 执行请求。
|
||||
|
||||
|
|
@ -450,7 +451,7 @@ Enable the aggregation layer via the following `kube-apiserver` flags. They may
|
|||
|
||||
The Kubernetes apiserver has two client CA options:
|
||||
-->
|
||||
### CA-重用和冲突 {#ca-reusage-and-conflicts}
|
||||
### CA 重用和冲突 {#ca-reusage-and-conflicts}
|
||||
|
||||
Kubernetes apiserver 有两个客户端 CA 选项：
|
||||
|
||||
|
|
@ -468,7 +469,7 @@ Each of these functions independently and can conflict with each other, if not u
|
|||
* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项，
|
||||
则 Kubernetes apiserver 会检查请求的证书。
|
||||
如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，
|
||||
并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。
|
||||
并且用户是公用名 `CN=` 的值，而组是组织 `O=` 的取值，则该请求被视为合法请求。
|
||||
请参阅[关于 TLS 身份验证的文档](/zh-cn/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
|
||||
|
||||
* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，
|
||||
|
|
@ -485,7 +486,7 @@ If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided,
|
|||
For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests.
|
||||
-->
|
||||
如果同时提供了 `--client-ca-file` 和 `--requestheader-client-ca-file`，
|
||||
则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。
|
||||
则首先检查 `--requestheader-client-ca-file` CA，然后再检查 `--client-ca-file`。
|
||||
通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。
|
||||
常规客户端请求与 `--client-ca-file` 相匹配，而聚合请求要与
|
||||
`--requestheader-client-ca-file` 相匹配。
|
||||
|
|
@ -500,11 +501,11 @@ apiserver 认证。
|
|||
用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用
|
||||
不同的 CA 证书。
|
||||
|
||||
{{< 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.
|
||||
-->
|
||||
{{< warning >}}
|
||||
除非你了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。
|
||||
除非你了解风险和保护 CA 用法的机制，否则 **不要** 重用在不同上下文中使用的 CA。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -523,7 +524,7 @@ If you are not running kube-proxy on a host running the API server, then you mus
|
|||
You can dynamically configure what client requests are proxied to extension
|
||||
apiserver. The following is an example registration:
|
||||
-->
|
||||
### 注册 APIService 对象
|
||||
### 注册 APIService 对象 {#register-apiservice-objects}
|
||||
|
||||
你可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例：
|
||||
|
||||
|
|
@ -547,8 +548,8 @@ spec:
|
|||
The name of an APIService object must be a valid
|
||||
[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
|
||||
-->
|
||||
APIService 对象的名称必须是合法的
|
||||
[路径片段名称](/zh-cn/docs/concepts/overview/working-with-objects/names#path-segment-names)。
|
||||
APIService
|
||||
对象的名称必须是合法的[路径片段名称](/zh-cn/docs/concepts/overview/working-with-objects/names#path-segment-names)。
|
||||
|
||||
<!--
|
||||
#### Contacting the extension apiserver
|
||||
|
|
@ -572,10 +573,9 @@ and to verify the TLS connection against the ServerName
|
|||
服务的名字空间和名字是必需的。端口是可选的，默认为 443。
|
||||
|
||||
下面是一个扩展 apiserver 的配置示例，它被配置为在端口 `1234` 上调用。
|
||||
并针对 ServerName
|
||||
`my-service-name.my-service-namespace.svc`
|
||||
使用自定义的 CA 包来验证 TLS 连接
|
||||
使用自定义 CA 捆绑包的 `my-service-name.my-service-namespace.svc`。
|
||||
并针对 ServerName `my-service-name.my-service-namespace.svc`
|
||||
使用自定义的 CA 包来验证 TLS 连接使用自定义 CA 捆绑包的
|
||||
`my-service-name.my-service-namespace.svc`。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiregistration.k8s.io/v1
|
||||
|
|
|
|||
Loading…
Reference in New Issue