Merge pull request #28177 from chenrui333/zh/resync-security-files

zh: resync concepts/security files

content/zh/docs/concepts/security/controlling-access.md

@@ -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 凭证.

content/zh/docs/concepts/security/pod-security-standards.md

@@ -49,7 +49,7 @@ should range from highly restricted to highly flexible:
 
 - **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
   policy allows for known privilege escalations.
-- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
+- **_Baseline_** - Minimally restrictive policy while preventing known privilege
   escalations. Allows the default (minimally specified) Pod configuration.
 - **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
 -->
@@ -60,7 +60,7 @@ should range from highly restricted to highly flexible:
 
 - **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略
   允许已知的特权提升。
-- **_Baseline/Default_** - 限制性最弱的策略，禁止已知的策略提升。
+- **_Baseline_** - 限制性最弱的策略，禁止已知的策略提升。
   允许使用默认的（规定最少）Pod 配置。
 - **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。
 
@@ -90,15 +90,15 @@ Privileged 框架可能意味着不应用任何约束而不是实施某策略实
 与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言，
 Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
 
-### Baseline/Default
+### Baseline
 
 <!--
-The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
+The Baseline policy is aimed at ease of adoption for common containerized workloads while
 preventing known privilege escalations. This policy is targeted at application operators and
 developers of non-critical applications. The following listed controls should be
 enforced/disallowed:
 -->
-Baseline/Default 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。
+Baseline 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。
 此策略针对的是应用运维人员和非关键性应用的开发人员。
 下面列举的控制应该被实施（禁止）：
 
@@ -201,39 +201,66 @@ Baseline/Default 策略的目标是便于常见的容器化应用采用，同时
 			</td>
 		</tr>
 		<tr>
-			<!-- td>AppArmor <em>(optional)</em></td -->
-			<td>AppArmor <em>（可选）</em></td>
+			<!-- <td>AppArmor <em>(optional)</em></td> -->
+			<td>AppArmor</td>
 			<!-- td>
-				On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
+				On supported hosts, the 'runtime/default' AppArmor profile is applied by default.
+				The baseline policy should prevent overriding or disabling the default AppArmor
+				profile, or restrict overrides to an allowed set of profiles.<br>
 				<br><b>限制的字段：</b><br>
 				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
 				<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
 			</td -->
 			<td>
-				在受支持的宿主上，默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略，或将重载限定未所允许的 profile 集合。<br>
+				在被支持的主机上，默认使用 'runtime/default' AppArmor Profile。
+				基线策略应避免覆盖或者禁用默认策略，以及限制覆盖一些 profile 集合的权限。<br>
 				<br><b>限制的字段：</b><br>
 				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
 				<br><b>允许的值：</b> 'runtime/default'、未定义<br>
 			</td>
 		</tr>
 		<tr>
-			<!-- td>SELinux <em>(optional)</em></td -->
-			<td>SELinux <em>（可选）</em></td>
+			<!-- <td>SELinux</td> -->
+			<td>SELinux</td>
 			<!-- td>
-				Setting custom SELinux options should be disallowed.<br>
+				Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.<br>
 				<br><b>Restricted Fields:</b><br>
-				spec.securityContext.seLinuxOptions<br>
-				spec.containers[*].securityContext.seLinuxOptions<br>
-				spec.initContainers[*].securityContext.seLinuxOptions<br>
-				<br><b>Allowed Values:</b> undefined/nil<br>
+				spec.securityContext.seLinuxOptions.type<br>
+				spec.containers[*].securityContext.seLinuxOptions.type<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.type<br>
+				<br><b>Allowed Values:</b><br>
+				undefined/empty<br>
+				container_t<br>
+				container_init_t<br>
+				container_kvm_t<br>
+				<br><b>Restricted Fields:</b><br>
+				spec.securityContext.seLinuxOptions.user<br>
+				spec.containers[*].securityContext.seLinuxOptions.user<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.user<br>
+				spec.securityContext.seLinuxOptions.role<br>
+				spec.containers[*].securityContext.seLinuxOptions.role<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.role<br>
+				<br><b>Allowed Values:</b> undefined/empty<br>
 			</td -->
 			<td>
-				应禁止设置定制的 SELinux 选项。<br>
+				设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。<br>
 				<br><b>限制的字段：</b><br>
-				spec.securityContext.seLinuxOptions<br>
-				spec.containers[*].securityContext.seLinuxOptions<br>
-				spec.initContainers[*].securityContext.seLinuxOptions<br>
-				<br><b>允许的值：</b> undefined/nil<br>
+				spec.securityContext.seLinuxOptions.type<br>
+				spec.containers[*].securityContext.seLinuxOptions.type<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.type<br>
+				<br><b>允许的值：</b><br>
+				未定义/空<br>
+				container_t<br>
+				container_init_t<br>
+				container_kvm_t<br>
+				<br><b>被限制的字段：</b><br>
+				spec.securityContext.seLinuxOptions.user<br>
+				spec.containers[*].securityContext.seLinuxOptions.user<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.user<br>
+				spec.securityContext.seLinuxOptions.role<br>
+				spec.containers[*].securityContext.seLinuxOptions.role<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.role<br>
+				<br><b>允许的值：</b> 未定义或空<br>
 			</td>
 		</tr>
 		<tr>
@@ -306,8 +333,8 @@ Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作
 			<td><strong>策略（Policy）</strong></td>
 		</tr>
 		<tr>
-			<!-- td colspan="2"><em>Everything from the default profile.</em></td -->
-			<td colspan="2"><em>Default 策略的所有要求。</em></td>
+			<!-- <td colspan="2"><em>Everything from the baseline profile.</em></td> -->
+			<td colspan="2"><em>基线策略的所有要求。</em></td>
 		</tr>
 		<tr>
 			<!-- td>Volume Types</td -->
@@ -425,11 +452,11 @@ of individual policies are not defined here.
 <!--
 ## FAQ
 
-### Why isn't there a profile between privileged and default?
+### Why isn't there a profile between privileged and baseline?
 -->
 ## 常见问题    {#faq}
 
-### 为什么策略类型定义在 Privileged 和 Default 之间
+### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型
 
 <!--
 The three profiles defined here have a clear linear progression from most secure (restricted) to least
@@ -517,4 +544,3 @@ sandboxing. As such, no single recommended policy is recommended for all sandbox
 
 此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
 因此，现在还没有针对所有沙箱化负载的建议策略。
-