zh: resync concepts/security files
zh: resync content/zh/docs/concepts/security/controlling-access zh: resync content/zh/docs/concepts/security/pod-security-standards sync zh translation Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <tengqm@outlook.com>
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
title: Kubernetes API 访问控制
|
||||
content_type: concept
|
||||
---
|
||||
<!--
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
@@ -14,13 +14,13 @@ content_type: concept
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
<!--
|
||||
This page provides an overview of controlling access to the Kubernetes API.
|
||||
-->
|
||||
本页面概述了对 Kubernetes API 的访问控制。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
<!--
|
||||
Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`,
|
||||
client libraries, or by making REST requests. Both human users and
|
||||
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
|
||||
@@ -37,7 +37,7 @@ following diagram:
|
||||
<!-- ## Transport security -->
|
||||
## 传输安全 {#transport-security}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
In a typical Kubernetes cluster, the API serves on port 443, protected by TLS.
|
||||
The API server presents a certificate. This certificate may be signed using
|
||||
a private certificate authority (CA), or based on a public key infrastructure linked
|
||||
@@ -47,9 +47,9 @@ to a generally recognized CA.
|
||||
API 服务器出示证书。
|
||||
该证书可以使用私有证书颁发机构(CA)签名,也可以基于链接到公认的 CA 的公钥基础架构签名。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
If your cluster uses a private certificate authority, you need a copy of that CA
|
||||
certifcate configured into your `~/.kube/config` on the client, so that you can
|
||||
certificate configured into your `~/.kube/config` on the client, so that you can
|
||||
trust the connection and be confident it was not intercepted.
|
||||
|
||||
Your client can present a TLS client certificate at this stage.
|
||||
@@ -62,7 +62,7 @@ Your client can present a TLS client certificate at this stage.
|
||||
<!-- ## Authentication -->
|
||||
## 认证 {#authentication}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Once TLS is established, the HTTP request moves to the Authentication step.
|
||||
This is shown as step **1** in the diagram.
|
||||
The cluster creation script or cluster admin configures the API server to run
|
||||
@@ -74,9 +74,9 @@ Authenticators are described in more detail in
|
||||
集群创建脚本或者集群管理员配置 API 服务器,使之运行一个或多个身份认证组件。
|
||||
身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The input to the authentication step is the entire HTTP request; however, it typically
|
||||
just examines the headers and/or client certificate.
|
||||
examines the headers and/or client certificate.
|
||||
|
||||
Authentication modules include client certificates, password, and plain tokens,
|
||||
bootstrap tokens, and JSON Web Tokens (used for service accounts).
|
||||
@@ -90,7 +90,7 @@ until one of them succeeds.
|
||||
|
||||
可以指定多个认证模块,在这种情况下,服务器依次尝试每个验证模块,直到其中一个成功。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
If the request cannot be authenticated, it is rejected with HTTP status code 401.
|
||||
Otherwise, the user is authenticated as a specific `username`, and the user name
|
||||
is available to subsequent steps to use in their decisions. Some authenticators
|
||||
@@ -99,7 +99,7 @@ do not.
|
||||
|
||||
While Kubernetes uses usernames for access control decisions and in request logging,
|
||||
it does not have a `User` object nor does it store usernames or other information about
|
||||
users in its API.
|
||||
users in its API.
|
||||
-->
|
||||
如果请求认证不通过,服务器将以 HTTP 状态码 401 拒绝该请求。
|
||||
反之,该用户被认证为特定的 `username`,并且该用户名可用于后续步骤以在其决策中使用。
|
||||
@@ -108,7 +108,7 @@ users in its API.
|
||||
<!-- ## Authorization -->
|
||||
## 鉴权 {#authorization}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
|
||||
|
||||
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
|
||||
@@ -134,7 +134,7 @@ For example, if Bob has the policy below, then he can read pods only in the name
|
||||
}
|
||||
}
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace:
|
||||
-->
|
||||
如果 Bob 执行以下请求,那么请求会被鉴权,因为允许他读取 `projectCaribou` 名称空间中的对象。
|
||||
@@ -153,27 +153,27 @@ If Bob makes the following request, the request is authorized because he is allo
|
||||
}
|
||||
}
|
||||
```
|
||||
<!--
|
||||
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied.
|
||||
<!--
|
||||
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied.
|
||||
If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
|
||||
|
||||
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems.
|
||||
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems.
|
||||
It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
|
||||
-->
|
||||
如果 Bob 在 `projectCaribou` 名字空间中请求写(`create` 或 `update`)对象,其鉴权请求将被拒绝。
|
||||
如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取(`get`)对象,其鉴权也会被拒绝。
|
||||
|
||||
Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
|
||||
Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
|
||||
使用 REST 格式很重要,因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。
|
||||
|
||||
<!--
|
||||
Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.
|
||||
When an administrator creates a cluster, they configure the authorization modules that should be used in the API server.
|
||||
If more than one authorization modules are configured, Kubernetes checks each module,
|
||||
and if any module authorizes the request, then the request can proceed.
|
||||
<!--
|
||||
Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.
|
||||
When an administrator creates a cluster, they configure the authorization modules that should be used in the API server.
|
||||
If more than one authorization modules are configured, Kubernetes checks each module,
|
||||
and if any module authorizes the request, then the request can proceed.
|
||||
If all of the modules deny the request, then the request is denied (HTTP status code 403).
|
||||
|
||||
To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules,
|
||||
To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules,
|
||||
see [Authorization](/docs/reference/access-authn-authz/authorization/).
|
||||
-->
|
||||
Kubernetes 支持多种鉴权模块,例如 ABAC 模式、RBAC 模式和 Webhook 模式等。
|
||||
@@ -187,7 +187,7 @@ Kubernetes 支持多种鉴权模块,例如 ABAC 模式、RBAC 模式和 Webhoo
|
||||
<!-- ## Admission control -->
|
||||
## 准入控制 {#admission-control}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Admission Control modules are software modules that can modify or reject requests.
|
||||
In addition to the attributes available to Authorization modules, Admission
|
||||
Control modules can access the contents of the object that is being created or modified.
|
||||
@@ -203,7 +203,7 @@ When multiple admission controllers are configured, they are called in order.
|
||||
准入控制器不会对仅读取对象的请求起作用。
|
||||
有多个准入控制器被配置时,服务器将依次调用它们。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
This is shown as step **3** in the diagram.
|
||||
|
||||
Unlike Authentication and Authorization modules, if any admission controller module
|
||||
@@ -230,11 +230,11 @@ for the corresponding API object, and then written to the object store (shown as
|
||||
<!-- ## API server ports and IPs -->
|
||||
## API 服务器端口和 IP {#api-server-ports-and-ips}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The previous discussion applies to requests sent to the secure port of the API server
|
||||
(the typical case). The API server can actually serve on 2 ports:
|
||||
|
||||
By default the Kubernetes API server serves HTTP on 2 ports:
|
||||
By default, the Kubernetes API server serves HTTP on 2 ports:
|
||||
-->
|
||||
前面的讨论适用于发送到 API 服务器的安全端口的请求(典型情况)。 API 服务器实际上可以在 2 个端口上提供服务:
|
||||
|
||||
@@ -250,7 +250,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:
|
||||
- default IP is localhost, change with `--insecure-bind-address` flag.
|
||||
- request **bypasses** authentication and authorization modules.
|
||||
- request handled by admission control module(s).
|
||||
- protected by need to have host access
|
||||
- protected by need to have host access
|
||||
|
||||
2. “Secure port”:
|
||||
|
||||
@@ -281,11 +281,11 @@ By default the Kubernetes API server serves HTTP on 2 ports:
|
||||
- 请求须经身份认证和鉴权组件处理
|
||||
- 请求须经准入控制模块处理
|
||||
- 身份认证和鉴权模块运行
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Read more documentation on authentication, authorization and API access control:
|
||||
|
||||
- [Authenticating](/docs/reference/access-authn-authz/authentication/)
|
||||
@@ -330,4 +330,4 @@ You can learn about:
|
||||
你可以了解
|
||||
- Pod 如何使用
|
||||
[Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
|
||||
获取 API 凭证.
|
||||
获取 API 凭证.
|
||||
|
||||
Reference in New Issue
Block a user