Switch language name 'zh' to 'zh-cn'

This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.

- The upstream docsy theme changed the language name, leading to many warnings during site build;
  The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.

There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.

We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.

This PR is based on commit cdad0a7342.

content/zh-cn/docs/concepts/security/_index.md

@@ -0,0 +1,5 @@
+---
+title: "安全"
+weight: 81
+description: 确保云原生工作负载安全的一组概念。
+---

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

@@ -0,0 +1,349 @@
+---
+title: Kubernetes API 访问控制
+content_type: concept
+---
+<!--
+---
+reviewers:
+- erictune
+- lavalamp
+title: Controlling Access to the Kubernetes API
+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
+authorized for API access.
+When a request reaches the API, it goes through several stages, illustrated in the
+following diagram:
+-->
+用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。
+人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。
+当请求到达 API 时，它会经历多个阶段，如下图所示：
+
+![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg)
+
+<!-- ## 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
+to a generally recognized CA.
+-->
+在典型的 Kubernetes 集群中，API 服务器在 443 端口上提供服务，受 TLS 保护。
+API 服务器出示证书。
+该证书可以使用私有证书颁发机构（CA）签名，也可以基于链接到公认的 CA 的公钥基础架构签名。
+
+<!--
+If your cluster uses a private certificate authority, you need a copy of that CA
+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.
+-->
+如果你的集群使用私有证书颁发机构，你需要在客户端的 `~/.kube/config` 文件中提供该 CA 证书的副本，
+以便你可以信任该连接并确认该连接没有被拦截。
+
+你的客户端可以在此阶段出示 TLS 客户端证书。
+
+<!-- ## 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
+one or more Authenticator modules.
+Authenticators are described in more detail in
+[Authentication](/docs/reference/access-authn-authz/authentication/).
+-->
+如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。
+集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。
+身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
+
+<!--
+The input to the authentication step is the entire HTTP request; however, it typically
+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).
+
+Multiple authentication modules can be specified, in which case each one is tried in sequence,
+until one of them succeeds.
+-->
+认证步骤的输入整个 HTTP 请求；但是，通常组件只检查头部或/和客户端证书。
+
+认证模块包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌（JWT，用于服务账户）。
+
+可以指定多个认证模块，在这种情况下，服务器依次尝试每个验证模块，直到其中一个成功。
+
+<!--
+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
+also provide the group memberships of the user, while other authenticators
+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.
+-->
+如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。
+反之，该用户被认证为特定的 `username`，并且该用户名可用于后续步骤以在其决策中使用。
+部分验证器还提供用户的组成员身份，其他则不提供。
+
+<!-- ## 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.
+
+For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
+-->
+如上图的步骤 **2** 所示，将请求验证为来自特定的用户后，请求必须被鉴权。
+
+请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。
+如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。
+
+例如，如果 Bob 有以下策略，那么他只能在 `projectCaribou` 名称空间中读取 Pod。
+
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+<!--
+If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace:
+-->
+如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 `projectCaribou` 名称空间中的对象。
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+<!--
+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.
+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 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
+使用 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.
+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,
+see [Authorization](/docs/reference/access-authn-authz/authorization/).
+-->
+Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。
+管理员创建集群时，他们配置应在 API 服务器中使用的鉴权模块。
+如果配置了多个鉴权模块，则 Kubernetes 会检查每个模块，任意一个模块鉴权该请求，请求即可继续；
+如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。
+
+要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息，
+请参阅[鉴权](/zh/docs/reference/access-authn-authz/authorization/)。
+
+<!-- ## 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.
+
+Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
+Admission controllers do not act on requests that merely read objects.
+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
+rejects, then the request is immediately rejected.
+
+In addition to rejecting objects, admission controllers can also set complex defaults for
+fields.
+
+The available Admission Control modules are described in [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
+
+Once a request passes all admission controllers, it is validated using the validation routines
+for the corresponding API object, and then written to the object store (shown as step **4**).
+-->
+这一操作如上图的步骤 **3** 所示。
+
+与身份认证和鉴权模块不同，如果任何准入控制器模块拒绝某请求，则该请求将立即被拒绝。
+
+除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。
+
+可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
+
+请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。
+
+<!--
+## Auditing
+
+Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
+The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
+
+For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).
+-->
+
+## 审计 {#auditing}
+
+Kubernetes 审计提供了一套与安全相关的、按时间顺序排列的记录，其中记录了集群中的操作序列。
+集群对用户、使用 Kubernetes API 的应用程序以及控制平面本身产生的活动进行审计。
+
+更多信息请参考 [审计](/zh/docs/tasks/debug/debug-cluster/audit/).
+
+<!-- ## 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:
+-->
+前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务：
+
+默认情况下，Kubernetes API 服务器在 2 个端口上提供 HTTP 服务：
+
+<!--
+  1. `localhost` port:
+
+      - is intended for testing and bootstrap, and for other components of the master node
+        (scheduler, controller-manager) to talk to the API
+      - no TLS
+      - default is port 8080
+      - 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
+
+  2. “Secure port”:
+
+      - use whenever possible
+      - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
+      - default is port 6443, change with `--secure-port` flag.
+      - default IP is first non-localhost network interface, change with `--bind-address` flag.
+      - request handled by authentication and authorization modules.
+      - request handled by admission control module(s).
+      - authentication and authorization modules run.
+ -->
+  1. `localhost` 端口:
+
+      - 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
+      - 没有 TLS
+      - 默认为端口 8080
+      - 默认 IP 为 localhost，使用 `--insecure-bind-address` 进行更改
+      - 请求 **绕过** 身份认证和鉴权模块
+      - 由准入控制模块处理的请求
+      - 受需要访问主机的保护
+
+  2. “安全端口”：
+
+      - 尽可能使用
+      - 使用 TLS。 用 `--tls-cert-file` 设置证书，用 `--tls-private-key-file` 设置密钥
+      - 默认端口 6443，使用 `--secure-port` 更改
+      - 默认 IP 是第一个非本地网络接口，使用 `--bind-address` 更改
+      - 请求须经身份认证和鉴权组件处理
+      - 请求须经准入控制模块处理
+      - 身份认证和鉴权模块运行
+
+
+## {{% heading "whatsnext" %}}
+
+<!--
+Read more documentation on authentication, authorization and API access control:
+
+- [Authenticating](/docs/reference/access-authn-authz/authentication/)
+   - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+   - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [Authorization](/docs/reference/access-authn-authz/authorization/)
+   - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/)
+   - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/)
+   - [Node Authorization](/docs/reference/access-authn-authz/node/)
+   - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/)
+- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- Service accounts
+  - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
+  - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
+
+You can learn about:
+- how Pods can use
+  [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  to obtain API credentials.
+-->
+阅读更多有关身份认证、鉴权和 API 访问控制的文档：
+
+- [认证](/zh/docs/reference/access-authn-authz/authentication/)
+   - [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+   - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
+   - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/)
+   - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/)
+   - [节点鉴权](/zh/docs/reference/access-authn-authz/node/)
+   - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/)
+- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- 服务账户
+  - [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/)
+  - [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
+
+你可以了解
+- Pod 如何使用
+  [Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  获取 API 凭证.

content/zh-cn/docs/concepts/security/overview.md

@@ -0,0 +1,294 @@
+---
+title: 云原生安全概述
+description: >
+ 在云原生安全的背景下思考 Kubernetes 安全模型。
+content_type: concept
+weight: 1
+---
+<!--
+reviewers:
+- zparnold
+title: Overview of Cloud Native Security
+description: >
+  A model for thinking about Kubernetes security in the context of Cloud Native security.
+content_type: concept
+weight: 1
+-->
+
+<!-- overview -->
+<!--
+This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
+-->
+本概述定义了一个模型，用于在 Cloud Native 安全性上下文中考虑 Kubernetes 安全性。
+
+<!--
+This container security model provides suggestions, not proven information security policies.
+-->
+{{< warning >}}
+此容器安全模型只提供建议，而不是经过验证的信息安全策略。
+{{< /warning >}}
+
+<!-- body -->
+
+<!--
+## The 4C's of Cloud Native security
+
+You can think about security in layers. The 4C's of Cloud Native security are Cloud,
+Clusters, Containers, and Code.
+-->
+## 云原生安全的 4 个 C    {#the-4c-s-of-cloud-native-security}
+
+你可以分层去考虑安全性，云原生安全的 4 个 C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。
+
+<!--
+This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
+computing approach to security, which is widely regarded as a best practice for securing
+software systems.
+-->
+{{< note >}}
+这种分层方法增强了[深度防护方法](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))在安全性方面的
+防御能力，该方法被广泛认为是保护软件系统的最佳实践。
+
+{{< /note >}}
+
+{{< figure src="/images/docs/4c.png" title="云原生安全的 4C" >}}
+
+<!--
+Each layer of the Cloud Native security model builds upon the next outermost layer.
+The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
+You cannot safeguard against poor security standards in the base layers by addressing
+security at the Code level.
+-->
+云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。
+你无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
+
+<!--
+## Cloud
+-->
+## 云    {#cloud}
+
+<!--
+In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the
+[trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
+of a Kubernetes cluster. If the Cloud layer is vulnerable (or
+configured in a vulnerable way) then there is no guarantee that the components built
+on top of this base are secure. Each cloud provider makes security recommendations
+for running workloads securely in their environment.
+-->
+在许多方面，云（或者位于同一位置的服务器，或者是公司数据中心）是 Kubernetes 集群中的
+[可信计算基](https://en.wikipedia.org/wiki/Trusted_computing_base)。
+如果云层容易受到攻击（或者被配置成了易受攻击的方式），就不能保证在此基础之上构建的组件是安全的。
+每个云提供商都会提出安全建议，以在其环境中安全地运行工作负载。
+
+<!--
+### Cloud provider security
+
+If you are running a Kubernetes cluster on your own hardware or a different cloud provider,
+consult your documentation for security best practices.
+Here are links to some of the popular cloud providers' security documentation:
+-->
+### 云提供商安全性    {#cloud-provider-security}
+
+如果你是在你自己的硬件或者其他不同的云提供商上运行 Kubernetes 集群，
+请查阅相关文档来获取最好的安全实践。
+
+下面是一些比较流行的云提供商的安全性文档链接：
+
+{{< table caption="云提供商安全" >}}
+
+IaaS 提供商        | 链接 |
+-------------------- | ------------ |
+Alibaba Cloud | https://www.alibabacloud.com/trust-center |
+Amazon Web Services | https://aws.amazon.com/security/ |
+Google Cloud Platform | https://cloud.google.com/security/ |
+IBM Cloud | https://www.ibm.com/cloud/security |
+Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
+VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+
+{{< /table >}}
+
+<!--
+### Infrastructure security {#infrastructure-security}
+
+Suggestions for securing your infrastructure in a Kubernetes cluster:
+
+{{< table caption="Infrastructure security" >}}
+
+Area of Concern for Kubernetes Infrastructure | Recommendation |
+--------------------------------------------- | -------------- |
+Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
+Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists) from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
+Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
+Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
+etcd Encryption | Wherever possible it's a good practice to encrypt all storage at rest, and since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
+
+{{< /table >}}
+-->
+### 基础设施安全 {#infrastructure-security}
+
+关于在 Kubernetes 集群中保护你的基础设施的建议：
+
+{{< table caption="基础设施安全" >}}
+
+Kubernetes 基础架构关注领域 | 建议 |
+--------------------------------------------- | -------------- |
+通过网络访问 API 服务（控制平面）|所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。|
+通过网络访问 Node（节点）| 节点应配置为 _仅能_ 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。|
+Kubernetes 访问云提供商的 API | 每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)。[Kops 文档](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)提供有关 IAM 策略和角色的信息。|
+访问 etcd | 对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 [etcd 文档](https://github.com/etcd-io/etcd/tree/master/Documentation)中找到。|
+etcd 加密 | 在所有可能的情况下，最好对所有存储进行静态数据加密，并且由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。|
+
+{{< /table >}}
+
+<!--
+## Cluster
+
+There are two areas of concern for securing Kubernetes:
+
+* Securing the cluster components that are configurable
+* Securing the applications which run in the cluster
+-->
+## 集群    {#cluster}
+
+保护 Kubernetes 有两个方面需要注意：
+
+* 保护可配置的集群组件
+* 保护在集群中运行的应用程序
+
+<!--
+### Components of the Cluster {#cluster-components}
+
+If you want to protect your cluster from accidental or malicious access and adopt
+good information practices, read and follow the advice about
+[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/).
+-->
+### 集群组件 {#cluster-components}
+
+如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
+
+<!--
+### Components in the cluster (your application) {#cluster-applications}
+
+Depending on the attack surface of your application, you may want to focus on specific
+aspects of security. For example: If you are running a service (Service A) that is critical
+in a chain of other resources and a separate workload (Service B) which is
+vulnerable to a resource exhaustion attack, then the risk of compromising Service A
+is high if you do not limit the resources of Service B. The following table lists
+areas of security concerns and recommendations for securing workloads running in Kubernetes:
+
+Area of Concern for Workload Security | Recommendation |
+------------------------------ | --------------------- |
+RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/
+Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+Ensuring that pods meet defined Pod Security Standards | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
+Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
+Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
+TLS for Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
+-->
+### 集群中的组件（你的应用） {#cluster-applications}
+
+根据你的应用程序的受攻击面，你可能需要关注安全性的特定面，比如：
+如果你正在运行中的一个服务（A 服务）在其他资源链中很重要，并且所运行的另一工作负载（服务 B）
+容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。
+下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载：
+
+工作负载安全性关注领域         |  建议                 |
+------------------------------ | --------------------- |
+RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
+认证方式 | https://kubernetes.io/zh/docs/concepts/security/controlling-access/
+应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/
+确保 Pod 符合定义的 Pod 安全标准 | https://kubernetes.io/zh/docs/concepts/security/pod-security-standards/#policy-instantiation
+服务质量（和集群资源管理）| https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
+网络策略 | https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
+Kubernetes Ingress 的 TLS 支持 | https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#tls
+
+<!--
+## Container
+
+Container security is outside the scope of this guide. Here are general recommendations and
+links to explore this topic:
+
+Area of Concern for Containers | Recommendation |
+------------------------------ | -------------- |
+Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
+Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
+Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
+Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation
+-->
+## 容器    {#container}
+
+容器安全性不在本指南的探讨范围内。下面是一些探索此主题的建议和连接：
+
+容器关注领域                   | 建议           |
+------------------------------ | -------------- |
+容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，你应该扫描你的容器里的已知漏洞。
+镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。
+禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。
+使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。
+<!--
+## Code
+
+Application code is one of the primary attack surfaces over which you have the most control.
+While securing application code is outside of the Kubernetes security topic, here
+are recommendations to protect application code:
+-->
+## 代码    {#code}
+
+应用程序代码是你最能够控制的主要攻击面之一，虽然保护应用程序代码不在 Kubernetes 安全主题范围内，但以下是保护应用程序代码的建议：
+
+<!--
+### Code security
+
+{{< table caption="Code security" >}}
+
+Area of Concern for Code | Recommendation |
+-------------------------| -------------- |
+Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual TLS authentication or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
+Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
+3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
+Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
+Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/) tool. |
+
+{{< /table >}}
+-->
+### 代码安全性    {#code-security}
+
+{{< table caption="代码安全" >}}
+
+代码关注领域 | 建议 |
+-------------------------| -------------- |
+仅通过 TLS 访问 | 如果你的代码需要通过 TCP 通信，请提前与客户端执行 TLS 握手。除少数情况外，请加密传输中的所有内容。更进一步，加密服务之间的网络流量是一个好主意。这可以通过被称为双向 TLS 或 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) 的过程来完成，该过程对两个证书持有服务之间的通信执行双向验证。 |
+限制通信端口范围 | 此建议可能有点不言自明，但是在任何可能的情况下，你都只应公开服务上对于通信或度量收集绝对必要的端口。|
+第三方依赖性安全 | 最好定期扫描应用程序的第三方库以了解已知的安全漏洞。每种编程语言都有一个自动执行此检查的工具。 |
+静态代码分析 | 大多数语言都提供给了一种方法，来分析代码段中是否存在潜在的不安全的编码实践。只要有可能，你都应该使用自动工具执行检查，该工具可以扫描代码库以查找常见的安全错误，一些工具可以在以下连接中找到： https://owasp.org/www-community/Source_Code_Analysis_Tools |
+动态探测攻击 | 你可以对服务运行一些自动化工具，来尝试一些众所周知的服务攻击。这些攻击包括 SQL 注入、CSRF 和 XSS。[OWASP Zed Attack](https://owasp.org/www-project-zap/) 代理工具是最受欢迎的动态分析工具之一。 |
+
+{{< /table >}}
+
+## {{% heading "whatsnext" %}}
+
+<!--
+Learn about related Kubernetes security topics:
+
+* [Pod security standards](/docs/concepts/security/pod-security-standards/)
+* [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
+* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
+* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
+* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
+* [Runtime class](/docs/concepts/containers/runtime-class)
+-->
+学习了解相关的 Kubernetes 安全主题：
+
+* [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
+* [Pod 的网络策略](/zh/docs/concepts/services-networking/network-policies/)
+* [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
+* [保护你的集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)
+* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
+* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/)
+* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/)
+* [运行时类](/zh/docs/concepts/containers/runtime-class)
+

content/zh-cn/docs/concepts/security/pod-security-admission.md

@@ -0,0 +1,330 @@
+---
+title: Pod 安全性准入
+description: >
+  对 Pod 安全性准入控制器的概述，Pod 安全性准入控制器可以实施 Pod 安全性标准。
+
+content_type: concept
+weight: 20
+min-kubernetes-server-version: v1.22
+---
+<!--
+reviewers:
+- tallclair
+- liggitt
+title: Pod Security Admission
+description: >
+  An overview of the Pod Security Admission Controller, which can enforce the Pod Security
+  Standards.
+content_type: concept
+weight: 20
+min-kubernetes-server-version: v1.22
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+<!--
+The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) define
+different isolation levels for Pods. These standards let you define how you want to restrict the
+behavior of pods in a clear, consistent fashion.
+-->
+Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/security/pod-security-standards/)
+为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
+
+<!--
+As a beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
+text="admission controller" term_id="admission-controller" >}}, the successor
+to [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/). Pod security restrictions
+are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
+are created.
+-->
+作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_ 
+{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}，
+作为 [PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)
+特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在
+{{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。
+
+{{< note >}}
+<!--
+The PodSecurityPolicy API is deprecated and will be 
+[removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25.
+-->
+PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中
+[移除](/zh/docs/reference/using-api/deprecation-guide/#v1-25)。
+{{< /note >}}
+
+<!-- body -->
+
+<!--
+## {{% heading "prerequisites" %}}
+
+To use this mechanism, your cluster must enforce Pod Security admission.
+
+### Built-in Pod Security admission enforcement
+-->
+## {{% heading "prerequisites" %}}
+
+要使用此机制，你的集群必须强制执行 Pod 安全准入。
+
+### 内置 Pod 安全准入强制执行
+
+<!--
+In Kubernetes v{{< skew currentVersion >}}, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is a beta feature and is enabled by default. You must have this feature gate enabled.
+If you are running a different version of Kubernetes, consult the documentation for that release.
+-->
+在 Kubernetes v{{< skew currentVersion >}} 中，`PodSecurity`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性，
+默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。
+
+
+
+<!--
+### Alternative: installing the `PodSecurity` admission webhook {#webhook}
+
+The `PodSecurity` admission logic is also available as a [validating admission webhook](https://git.k8s.io/pod-security-admission/webhook). This implementation is also beta.
+For environments where the built-in `PodSecurity` admission plugin cannot be enabled, you can instead enable that logic via a validating admission webhook.
+-->
+### 替代方案：安装 `PodSecurity` 准入 Webhook   {#webhook}
+
+`PodSecurity` 准入逻辑也可用作[验证性准入 Webhook](https://git.k8s.io/pod-security-admission/webhook)。
+该实现也是 Beta 版本。
+对于无法启用内置 `PodSecurity` 准入插件的环境，你可以改为通过验证准入 Webhook 启用该逻辑。
+
+<!--
+A pre-built container image, certificate generation scripts, and example manifests
+are available at [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook).
+
+To install:
+-->
+在 [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook)
+上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。
+
+```shell
+git clone git@github.com:kubernetes/pod-security-admission.git
+cd pod-security-admission/webhook
+make certs
+kubectl apply -k .
+```
+
+{{< note >}}
+<!--
+The generated certificate is valid for 2 years. Before it expires,
+regenerate the certificate or remove the webhook in favor of the built-in admission plugin.
+-->
+所生成的证书合法期限为 2 年。在证书过期之前，
+需要重新生成证书或者去掉 Webhook 以使用内置的准入查件。
+{{< /note >}}
+
+<!-- body -->
+
+<!--
+## Pod Security levels
+-->
+## Pod 安全性级别   {#pod-security-levels}
+
+<!--
+Pod Security admission places requirements on a Pod's [Security
+Context](/docs/tasks/configure-pod-container/security-context/) and other related fields according
+to the three levels defined by the [Pod Security
+Standards](/docs/concepts/security/pod-security-standards): `privileged`, `baseline`, and
+`restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards)
+page for an in-depth look at those requirements.
+-->
+Pod 安全性准入插件对 Pod 的[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)
+有一定的要求，并且依据 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)
+所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。
+关于这些需求的更进一步讨论，请参阅
+[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。
+
+<!--
+## Pod Security Admission labels for namespaces
+
+Once the feature is enabled or the webhook is installed, you can configure namespaces to define the admission
+control mode you want to use for pod security in each namespace. Kubernetes defines a set of 
+{{< glossary_tooltip term_id="label" text="labels" >}} that you can set to define which of the 
+predefined Pod Security Standard levels you want to use for a namespace. The label you select
+defines what action the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+takes if a potential violation is detected:
+-->
+## 为名字空间设置 Pod 安全性准入控制标签
+
+一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中
+Pod 安全性准入控制模式。
+Kubernetes 定义了一组{{< glossary_tooltip term_id="label" text="标签" >}}，
+你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。
+你所选择的标签定义了检测到潜在违例时，{{< glossary_tooltip text="控制面" term_id="control-plane" >}}
+要采取什么样的动作。
+
+<!--
+{{< table caption="Pod Security Admission modes" >}}
+Mode | Description
+:---------|:------------
+**enforce** | Policy violations will cause the pod to be rejected.
+**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug/debug-cluster/audit/), but are otherwise allowed.
+**warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed.
+{{< /table >}}
+-->
+{{< table caption="Pod 安全准入模式" >}}
+模式 | 描述
+:---------|:------------
+**enforce** | 策略违例会导致 Pod 被拒绝
+**audit** | 策略违例会触发[审计日志](/zh/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
+**warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。
+{{< /table >}}
+
+<!--
+A namespace can configure any or all modes, or even set a different level for different modes.
+
+For each mode, there are two labels that determine the policy used:
+-->
+名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。
+
+对于每种模式，决定所使用策略的标签有两个：
+
+<!--
+# The per-mode level label indicates which policy level to apply for the mode.
+#
+# MODE must be one of `enforce`, `audit`, or `warn`.
+# LEVEL must be one of `privileged`, `baseline`, or `restricted`.
+pod-security.kubernetes.io/<MODE>: <LEVEL>
+
+# Optional: per-mode version label that can be used to pin the policy to the
+# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}).
+#
+# MODE must be one of `enforce`, `audit`, or `warn`.
+# VERSION must be a valid Kubernetes minor version, or `latest`.
+pod-security.kubernetes.io/<MODE>-version: <VERSION>
+-->
+```
+# 针对模式的级别标签用来标示针对该模式所应用的策略级别
+#
+# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
+# LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一
+pod-security.kubernetes.io/<MODE>: <LEVEL>
+
+# 可选：针对每个模式版本的版本标签可以将策略锁定到
+# 给定 Kubernetes 小版本号所附带的版本（例如 v{{< skew latestVersion >}}）
+#
+# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
+# VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest`
+pod-security.kubernetes.io/<MODE>-version: <VERSION>
+```
+
+<!--
+Check out [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) to see example usage.
+-->
+关于用法示例，可参阅
+[使用名字空间标签来强制实施 Pod 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。
+
+<!--
+## Workload resources and Pod templates
+
+Pods are often created indirectly, by creating a [workload
+object](/docs/concepts/workloads/controllers/) such as a {{< glossary_tooltip
+term_id="deployment" >}} or {{< glossary_tooltip term_id="job">}}. The workload object defines a
+_Pod template_ and a {{< glossary_tooltip term_id="controller" text="controller" >}} for the
+workload resource creates Pods based on that template. To help catch violations early, both the
+audit and warning modes are applied to the workload resources. However, enforce mode is **not**
+applied to workload resources, only to the resulting pod objects.
+-->
+## 负载资源和 Pod 模板    {#workload-resources-and-pod-templates}
+
+Pod 通常是通过创建 {{< glossary_tooltip term_id="deployment" >}} 或
+{{< glossary_tooltip term_id="job">}} 这类[工作负载对象](/zh/docs/concepts/workloads/controllers/)
+来间接创建的。工作负载对象为工作负载资源定义一个 _Pod 模板_ 和一个对应的
+负责基于该模板来创建 Pod 的{{< glossary_tooltip term_id="controller" text="控制器" >}}。
+为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。
+不过，`enforce` 模式并 **不** 应用到工作负载资源，仅应用到所生成的 Pod 对象上。 
+
+<!--
+## Exemptions
+
+You can define _exemptions_ from pod security enforcement in order to allow the creation of pods that
+would have otherwise been prohibited due to the policy associated with a given namespace.
+Exemptions can be statically configured in the
+[Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller).
+-->
+## 豁免   {#exemptions}
+
+你可以为 Pod 安全性的实施设置 _豁免（Exemptions）_ 规则，
+从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。
+豁免规则可以在[准入控制器配置](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
+中静态配置。
+
+<!--
+Exemptions must be explicitly enumerated. Requests meeting exemption criteria are _ignored_ by the
+Admission Controller (all `enforce`, `audit` and `warn` behaviors are skipped). Exemption dimensions include:
+-->
+豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 _忽略_
+（所有 `enforce`、`audit` 和 `warn` 行为都会被略过）。
+豁免的维度包括：
+
+<!--
+- **Usernames:** requests from users with an exempt authenticated (or impersonated) username are
+  ignored.
+- **RuntimeClassNames:** pods and [workload resources](#workload-resources-and-pod-templates) specifying an exempt runtime class name are
+  ignored.
+- **Namespaces:** pods and [workload resources](#workload-resources-and-pod-templates) in an exempt namespace are ignored.
+-->
+- **Username：** 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。
+- **RuntimeClassName：** 指定了已豁免的运行时类名称的 Pod
+  和[负载资源](#workload-resources-and-pod-templates)会被忽略。
+- **Namespace：** 位于被豁免的名字空间中的 Pod 和[负载资源](#workload-resources-and-pod-templates) 
+  会被忽略。
+
+{{< caution >}}
+<!--
+Most pods are created by a controller in response to a [workload
+resource](#workload-resources-and-pod-templates), meaning that exempting an end user will only
+exempt them from enforcement when creating pods directly, but not when creating a workload resource.
+Controller service accounts (such as `system:serviceaccount:kube-system:replicaset-controller`)
+should generally not be exempted, as doing so would implicitly exempt any user that can create the
+corresponding workload resource.
+-->
+大多数 Pod 是作为对[工作负载资源](#workload-resources-and-pod-templates)的响应，
+由控制器所创建的，这意味着为某最终用户提供豁免时，只会当该用户直接创建 Pod
+时对其实施安全策略的豁免。用户创建工作负载资源时不会被豁免。
+控制器服务账号（例如：`system:serviceaccount:kube-system:replicaset-controller`）
+通常不应该被豁免，因为豁免这类服务账号隐含着对所有能够创建对应工作负载资源的用户豁免。
+{{< /caution >}}
+
+<!--
+Updates to the following pod fields are exempt from policy checks, meaning that if a pod update
+request only changes these fields, it will not be denied even if the pod is in violation of the
+current policy level:
+-->
+策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod
+更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。
+
+<!--
+- Any metadata updates **except** changes to the seccomp or AppArmor annotations:
+  - `seccomp.security.alpha.kubernetes.io/pod` (deprecated)
+  - `container.seccomp.security.alpha.kubernetes.io/*` (deprecated)
+  - `container.apparmor.security.beta.kubernetes.io/*`
+- Valid updates to `.spec.activeDeadlineSeconds`
+- Valid updates to `.spec.tolerations`
+-->
+- 除了对 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作：
+  - `seccomp.security.alpha.kubernetes.io/pod` （已弃用）
+  - `container.seccomp.security.alpha.kubernetes.io/*` （已弃用）
+  - `container.apparmor.security.beta.kubernetes.io/*`
+- 对 `.spec.activeDeadlineSeconds` 的合法更新
+- 对 `.spec.tolerations` 的合法更新
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- [Pod Security Standards](/docs/concepts/security/pod-security-standards)
+- [Enforcing Pod Security Standards](/docs/setup/best-practices/enforcing-pod-security-standards)
+- [Enforce Pod Security Standards by Configuring the Built-in Admission Controller](/docs/tasks/configure-pod-container/enforce-standards-admission-controller)
+- [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)
+- [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp)
+-->
+- [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)
+- [强制实施 Pod 安全性标准](/zh/docs/setup/best-practices/enforcing-pod-security-standards/)
+- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
+- [使用名字空间标签来实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
+- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)
+

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

@@ -0,0 +1,966 @@
+---
+title: Pod 安全性标准
+content_type: concept
+weight: 10
+---
+<!--
+reviewers:
+- tallclair
+title: Pod Security Standards
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+
+<!--
+The Pod Security Standards define three different _policies_ to broadly cover the security
+spectrum. These policies are _cumulative_ and range from highly-permissive to highly-restrictive.
+This guide outlines the requirements of each policy.
+
+| Profile | Description |
+| ------ | ----------- |
+| <strong style="white-space: nowrap">Privileged</strong> | Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. |
+| <strong style="white-space: nowrap">Baseline</strong> | Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration. |
+| <strong style="white-space: nowrap">Restricted</strong> | Heavily restricted policy, following current Pod hardening best practices. |
+-->
+Pod 安全性标准定义了三种不同的 _策略（Policy）_，以广泛覆盖安全应用场景。
+这些策略是 _渐进式的（Cumulative）_，安全级别从高度宽松至高度受限。
+本指南概述了每个策略的要求。
+
+| Profile | 描述 |
+| ------ | ----------- |
+| <strong style="white-space: nowrap">Privileged</strong> | 不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。 |
+| <strong style="white-space: nowrap">Baseline</strong> | 限制性最弱的策略，禁止已知的策略提升。允许使用默认的（规定最少）Pod 配置。 |
+| <strong style="white-space: nowrap">Restricted</strong> | 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。 |
+
+<!-- body -->
+
+<!--
+## Profile Details
+
+### Privileged
+-->
+## Profile 细节    {#profile-details}
+
+### Privileged
+
+<!--
+**The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is
+typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
+
+The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
+mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
+rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
+Security Policy) the privileged policy should enable all controls (disable all restrictions).
+-->
+**_Privileged_ 策略是有目的地开放且完全无限制的策略。**
+此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。
+
+Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper），
+Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。
+与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言，
+Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
+
+### Baseline
+
+<!--
+**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_ 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。**
+此策略针对的是应用运维人员和非关键性应用的开发人员。
+下面列举的控制应该被实施（禁止）：
+
+{{< note >}}
+<!--
+In this table, wildcards (`*`) indicate all elements in a list. For example,
+`spec.containers[*].securityContext` refers to the Security Context object for _all defined
+containers_. If any of the listed containers fails to meet the requirements, the entire pod will
+fail validation.
+-->
+在下述表格中，通配符（`*`）意味着一个列表中的所有元素。
+例如 `spec.containers[*].securityContext` 表示 _所定义的所有容器_ 的安全性上下文对象。
+如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。
+{{< /note >}}
+
+<table>
+	<!-- caption style="display:none">Baseline policy specification</caption -->
+	<caption style="display:none">Baseline 策略规范</caption>
+	<tbody>
+		<tr>
+			<td>控制（Control）</td>
+			<td>策略（Policy）</td>
+		</tr>
+    <tr>
+			<!-- <td style="white-space: nowrap">HostProcess</td> -->
+      <td style="white-space: nowrap">HostProcess</td>
+      <!-- <td>
+				<p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess containers</a> which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are an <strong>alpha</strong> feature as of Kubernetes <strong>v1.22</strong>.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.containers[*].securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.initContainers[*].securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td> -->
+			<td>
+				<p>Windows Pod 提供了运行
+         <a href="/zh/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess 容器</a> 的能力，
+         这使得对 Windows 节点的特权访问成为可能。 
+         基线策略中对宿主的特权访问是被禁止的。 
+         HostProcess Pod 是 Kubernetes <strong>v1.22</strong> 版本的
+          <strong>alpha</strong> 特性。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.containers[*].securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.initContainers[*].securityContext.windowsOptions.hostProcess</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">Host Namespaces</td> -->
+			<td style="white-space: nowrap">宿主名字空间</td>
+			<!-- 
+      <td>
+				<p>Sharing the host namespaces must be disallowed.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.hostNetwork</code></li>
+					<li><code>spec.hostPID</code></li>
+					<li><code>spec.hostIPC</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td>
+      -->
+			<td>
+        <p>必须禁止共享宿主名字空间。</p>
+        <p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.hostNetwork</code></li>
+					<li><code>spec.hostPID</code></li>
+					<li><code>spec.hostIPC</code></li>
+				</ul>
+        <p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">Privileged Containers</td> -->
+			<td style="white-space: nowrap">特权容器</td>
+			<!-- <td>
+				<p>Privileged Pods disable most security mechanisms and must be disallowed.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.privileged</code></li>
+					<li><code>spec.initContainers[*].securityContext.privileged</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.privileged</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>特权 Pod 关闭了大多数安全性机制，必须被禁止。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.privileged</code></li>
+					<li><code>spec.initContainers[*].securityContext.privileged</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.privileged</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>false</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">Capabilities</td> -->
+			<td style="white-space: nowrap">权能</td>
+			<!-- <td>
+				<p>Adding additional capabilities beyond those listed below must be disallowed.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>AUDIT_WRITE</code></li>
+					<li><code>CHOWN</code></li>
+					<li><code>DAC_OVERRIDE</code></li>
+					<li><code>FOWNER</code></li>
+					<li><code>FSETID</code></li>
+					<li><code>KILL</code></li>
+					<li><code>MKNOD</code></li>
+					<li><code>NET_BIND_SERVICE</code></li>
+					<li><code>SETFCAP</code></li>
+					<li><code>SETGID</code></li>
+					<li><code>SETPCAP</code></li>
+					<li><code>SETUID</code></li>
+					<li><code>SYS_CHROOT</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>必须禁止添加除下列字段之外的权能。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>AUDIT_WRITE</code></li>
+					<li><code>CHOWN</code></li>
+					<li><code>DAC_OVERRIDE</code></li>
+					<li><code>FOWNER</code></li>
+					<li><code>FSETID</code></li>
+					<li><code>KILL</code></li>
+					<li><code>MKNOD</code></li>
+					<li><code>NET_BIND_SERVICE</code></li>
+					<li><code>SETFCAP</code></li>
+					<li><code>SETGID</code></li>
+					<li><code>SETPCAP</code></li>
+					<li><code>SETUID</code></li>
+					<li><code>SYS_CHROOT</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">HostPath Volumes</td>-->
+			<td style="white-space: nowrap">HostPath 卷</td>
+			<!-- <td>
+				<p>HostPath volumes must be forbidden.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.volumes[*].hostPath</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+				</ul>
+			</td> -->
+			<td>
+        <p>必须禁止 HostPath 卷。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.volumes[*].hostPath</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">Host Ports</td> -->
+			<td style="white-space: nowrap">宿主端口</td>
+			<!-- <td>
+				<p>HostPorts should be disallowed, or at minimum restricted to a known list.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].ports[*].hostPort</code></li>
+					<li><code>spec.initContainers[*].ports[*].hostPort</code></li>
+					<li><code>spec.ephemeralContainers[*].ports[*].hostPort</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li>Known list</li>
+					<li><code>0</code></li>
+				</ul>
+			</td>-->
+			<td>
+        <p>应禁止使用宿主端口，或者至少限定为已知列表。</p>
+        <p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].ports[*].hostPort</code></li>
+					<li><code>spec.initContainers[*].ports[*].hostPort</code></li>
+					<li><code>spec.ephemeralContainers[*].ports[*].hostPort</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li>已知列表</li>
+					<li><code>0</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">AppArmor</td> -->
+			<td style="white-space: nowrap">AppArmor</td>
+			<!-- <td>
+				<p>On supported hosts, the <code>runtime/default</code> 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.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>runtime/default</code></li>
+					<li><code>localhost/*</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>在受支持的主机上，默认使用 <code>runtime/default</code> AppArmor Profile。
+				基线策略应避免覆盖或者禁用默认策略，以及限制覆盖一些 Profile 集合的权限。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>runtime/default</code></li>
+					<li><code>localhost/*</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">SELinux</td> -->
+			<td style="white-space: nowrap">SELinux</td>
+			<!-- <td>
+				<p>Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.type</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/""</li>
+					<li><code>container_t</code></li>
+					<li><code>container_init_t</code></li>
+					<li><code>container_kvm_t</code></li>
+				</ul>
+				<hr />
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.role</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/""</li>
+				</ul>
+			</td>-->
+			<td>
+        <p>设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。</p>
+        <p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.type</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/""</li>
+					<li><code>container_t</code></li>
+					<li><code>container_init_t</code></li>
+					<li><code>container_kvm_t</code></li>
+				</ul>
+				<hr />
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.user</code></li>
+					<li><code>spec.securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.containers[*].securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.initContainers[*].securityContext.seLinuxOptions.role</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.role</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/""</li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap"><code>/proc</code> Mount Type</td> -->
+			<td style="white-space: nowrap"><code>/proc</code> 挂载类型</td>
+			<!-- <td>
+				<p>The default <code>/proc</code> masks are set up to reduce attack surface, and should be required.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.procMount</code></li>
+					<li><code>spec.initContainers[*].securityContext.procMount</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.procMount</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>Default</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>要求使用默认的 <code>/proc</code> 掩码以减小攻击面。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.procMount</code></li>
+					<li><code>spec.initContainers[*].securityContext.procMount</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.procMount</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>Default</code></li>
+				</ul>
+			</td>
+		</tr>
+    <tr>
+  			<td>Seccomp</td>
+  			<!-- <td>
+  				<p>Seccomp profile must not be explicitly set to <code>Unconfined</code>.</p>
+  				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seccompProfile.type</code></li>
+					<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>RuntimeDefault</code></li>
+					<li><code>Localhost</code></li>
+				</ul>
+  			</td> -->
+        <td>
+  				<p>Seccomp Profile 禁止被显式设置为 <code>Unconfined</code>。</p>
+  				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seccompProfile.type</code></li>
+					<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>RuntimeDefault</code></li>
+					<li><code>Localhost</code></li>
+				</ul>
+  			</td>
+  		</tr>
+		<tr>
+			<td>Sysctls</td>
+			<!-- <td>
+				<p>Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.sysctls[*].name</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>kernel.shm_rmid_forced</code></li>
+					<li><code>net.ipv4.ip_local_port_range</code></li>
+					<li><code>net.ipv4.ip_unprivileged_port_start</code></li>
+					<li><code>net.ipv4.tcp_syncookies</code></li>
+					<li><code>net.ipv4.ping_group_range</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干“安全”的子集之外，应该被禁止。
+				如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.sysctls[*].name</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>kernel.shm_rmid_forced</code></li>
+					<li><code>net.ipv4.ip_local_port_range</code></li>
+					<li><code>net.ipv4.ip_unprivileged_port_start</code></li>
+					<li><code>net.ipv4.tcp_syncookies</code></li>
+					<li><code>net.ipv4.ping_group_range</code></li>
+				</ul>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+### Restricted
+
+<!--
+**The _Restricted_ policy is aimed at enforcing current Pod hardening best practices, at the
+expense of some compatibility.** It is targeted at operators and developers of security-critical
+applications, as well as lower-trust users. The following listed controls should be
+enforced/disallowed:
+
+In this table, wildcards (`*`) indicate all elements in a list. For example, 
+`spec.containers[*].securityContext` refers to the Security Context object for _all defined
+containers_. If any of the listed containers fails to meet the requirements, the entire pod will
+fail validation.
+-->
+**_Restricted_ 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作可能会牺牲一些兼容性。**
+该类策略主要针对运维人员和安全性很重要的应用的开发人员，以及不太被信任的用户。
+下面列举的控制需要被实施（禁止）：
+
+{{< note >}}
+在下述表格中，通配符（`*`）意味着一个列表中的所有元素。
+例如 `spec.containers[*].securityContext` 表示 _所定义的所有容器_ 的安全性上下文对象。
+如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。
+{{< /note >}}
+
+<table>
+	<!-- caption style="display:none">Restricted policy specification</caption -->
+	<caption style="display:none">Restricted 策略规范</caption>
+	<tbody>
+		<tr>
+			<!-- td><strong>Control</strong></td -->
+			<td width="30%"><strong>控制（Control）</strong></td>
+			<!-- td><strong>Policy</strong></td -->
+			<td><strong>策略（Policy）</strong></td>
+		</tr>
+		<tr>
+			<!-- <td colspan="2"><em>Everything from the baseline profile.</em></td> -->
+			<td colspan="2"><em>基线策略的所有要求。</em></td>
+		</tr>
+		<tr>
+      <!-- <td style="white-space: nowrap">Volume Types</td>
+			<td>
+				<p>In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.volumes[*]</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				Every item in the <code>spec.volumes[*]</code> list must set one of the following fields to a non-null value:
+				<ul>
+					<li><code>spec.volumes[*].configMap</code></li>
+					<li><code>spec.volumes[*].csi</code></li>
+					<li><code>spec.volumes[*].downwardAPI</code></li>
+					<li><code>spec.volumes[*].emptyDir</code></li>
+					<li><code>spec.volumes[*].ephemeral</code></li>
+					<li><code>spec.volumes[*].persistentVolumeClaim</code></li>
+					<li><code>spec.volumes[*].projected</code></li>
+					<li><code>spec.volumes[*].secret</code></li>
+				</ul>
+			</td> -->
+			<td>卷类型</td>
+			<td>
+        <p>除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.volumes[*]</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<code>spec.volumes[*]</code> 列表中的每个条目必须将下面字段之一设置为非空值：
+				<ul>
+					<li><code>spec.volumes[*].configMap</code></li>
+					<li><code>spec.volumes[*].csi</code></li>
+					<li><code>spec.volumes[*].downwardAPI</code></li>
+					<li><code>spec.volumes[*].emptyDir</code></li>
+					<li><code>spec.volumes[*].ephemeral</code></li>
+					<li><code>spec.volumes[*].persistentVolumeClaim</code></li>
+					<li><code>spec.volumes[*].projected</code></li>
+					<li><code>spec.volumes[*].secret</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+      <!-- <td style="white-space: nowrap">Privilege Escalation (v1.8+)</td>
+			<td>
+				<p>Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.allowPrivilegeEscalation</code></li>
+					<li><code>spec.initContainers[*].securityContext.allowPrivilegeEscalation</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li><code>false</code></li>
+				</ul>
+			</td> -->
+			<td style="white-space: nowrap">特权提升（v1.8+）</td>
+			<td>
+        <p>禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升。</p>
+				<br>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.allowPrivilegeEscalation</code></li>
+					<li><code>spec.initContainers[*].securityContext.allowPrivilegeEscalation</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li><code>false</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+      <!-- <td style="white-space: nowrap">Running as Non-root</td> -->
+			<td style="white-space: nowrap">以非 root 账号运行 </td>
+      <!-- <td>
+				<p>Containers must be required to run as non-root users.</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.runAsNonRoot</code></li>
+					<li><code>spec.containers[*].securityContext.runAsNonRoot</code></li>
+					<li><code>spec.initContainers[*].securityContext.runAsNonRoot</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.runAsNonRoot</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li><code>true</code></li>
+				</ul>
+				<small>
+					The container fields may be undefined/<code>nil</code> if the pod-level
+					<code>spec.securityContext.runAsNonRoot</code> is set to <code>true</code>.
+				</small>
+			</td> -->
+			<td>
+        <p>必须要求容器以非 root 用户运行。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.runAsNonRoot</code></li>
+					<li><code>spec.containers[*].securityContext.runAsNonRoot</code></li>
+					<li><code>spec.initContainers[*].securityContext.runAsNonRoot</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.runAsNonRoot</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li><code>true</code></li>
+				</ul>
+				<small>
+					如果 Pod 级别 <code>spec.securityContext.runAsNonRoot</code> 设置为 
+          <code>true</code>，则允许容器组的安全上下文字段设置为 未定义/<code>nil</code>。
+				</small>
+			</td>
+		</tr>
+		<tr>
+			<!-- <td style="white-space: nowrap">Running as Non-root user (v1.23+)</td> -->
+			<td style="white-space: nowrap">非 root 用户（v1.23+）</td>
+			<td>
+				<!--
+				<p>Containers must not set <tt>runAsUser</tt> to 0</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.runAsUser</code></li>
+					<li><code>spec.containers[*].securityContext.runAsUser</code></li>
+					<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>any non-zero value</li>
+					<li><code>undefined/null</code></li>
+				</ul>
+			</td> -->
+				<p>Containers 不可以将 <tt>runAsUser</tt> 设置为 0</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.runAsUser</code></li>
+					<li><code>spec.containers[*].securityContext.runAsUser</code></li>
+					<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
+				</ul>
+				<p><strong>允许的字段</strong></p>
+				<ul>
+					<li>any non-zero value</li>
+					<li><code>未定义/空值</code></li>
+				</ul>
+			</td>
+		</tr>
+		<tr>
+			<td style="white-space: nowrap">Seccomp (v1.19+)</td>
+			<td>
+				<!-- <td>
+  				<p>Seccomp profile must be explicitly set to one of the allowed values. Both the <code>Unconfined</code> profile and the <em>absence</em> of a profile are prohibited.</p>
+  				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seccompProfile.type</code></li>
+					<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li><code>RuntimeDefault</code></li>
+					<li><code>Localhost</code></li>
+				</ul>
+				<small>
+					The container fields may be undefined/<code>nil</code> if the pod-level
+					<code>spec.securityContext.seccompProfile.type</code> field is set appropriately.
+					Conversely, the pod-level field may be undefined/<code>nil</code> if _all_ container-
+					level fields are set.
+				</small>
+  			</td> -->
+        <p>Seccomp Profile 必须被显式设置成一个允许的值。禁止使用 <code>Unconfined</code> 
+        Profile 或者指定 <em>不存在的</em> Profile。</p>
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.securityContext.seccompProfile.type</code></li>
+					<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li><code>RuntimeDefault</code></li>
+					<li><code>Localhost</code></li>
+				</ul>
+				<small>
+					如果 Pod 级别的 <code>spec.securityContext.seccompProfile.type</code> 
+          已设置得当，容器级别的安全上下文字段可以为 未定义/<code>nil</code>。
+          反过来说，如果 _所有的_ 容器级别的安全上下文字段已设置，则 Pod 级别的字段可为 未定义/<code>nil</code>。 
+				</small>
+			</td>
+		</tr>
+    <tr>
+			<!-- <td style="white-space: nowrap">Capabilities (v1.22+)</td> -->
+      <td style="white-space: nowrap">权能（v1.22+）</td>
+      <!-- <td>
+				<p>
+					Containers must drop <code>ALL</code> capabilities, and are only permitted to add back
+					the <code>NET_BIND_SERVICE</code> capability.
+				</p>
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.drop</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.drop</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.drop</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Any list of capabilities that includes <code>ALL</code></li>
+				</ul>
+				<hr />
+				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>NET_BIND_SERVICE</code></li>
+				</ul>
+			</td> -->
+			<td>
+        <p>
+					容器组必须弃用 <code>ALL</code> 权能，并且只允许添加 <code>NET_BIND_SERVICE</code> 权能。
+				</p>
+        <p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.drop</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.drop</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.drop</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>包含 <code>ALL</code> 的任何一种权能列表。</li>
+				</ul>
+				<hr />
+				<p><strong>限制的字段</strong></p>
+				<ul>
+					<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
+				</ul>
+				<p><strong>允许的值</strong></p>
+				<ul>
+					<li>未定义/nil</li>
+					<li><code>NET_BIND_SERVICE</code></li>
+				</ul>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+<!--
+## Policy Instantiation
+
+Decoupling policy definition from policy instantiation allows for a common understanding and
+consistent language of policies across clusters, independent of the underlying enforcement
+mechanism.
+
+As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement
+of individual policies are not defined here.
+-->
+## 策略实例化   {#policy-instantiation}
+
+将策略定义从策略实例中解耦出来有助于形成跨集群的策略理解和语言陈述，
+以免绑定到特定的下层实施机制。
+
+随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。
+
+[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/)
+
+- {{< example file="security/podsecurity-privileged.yaml" >}}Privileged 名字空间{{< /example >}}
+- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline 名字空间{{< /example >}}
+- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted 名字空间{{< /example >}}
+
+[**PodSecurityPolicy**](/zh/docs/concepts/security/pod-security-policy/) （已弃用）
+
+- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
+- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
+- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+
+<!--
+## FAQ
+
+### Why isn't there a profile between privileged and baseline?
+-->
+## 常见问题    {#faq}
+
+### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型
+
+<!--
+The three profiles defined here have a clear linear progression from most secure (restricted) to least
+secure (privileged), and cover a broad set of workloads. Privileges required above the baseline
+policy are typically very application specific, so we do not offer a standard profile in this
+niche. This is not to say that the privileged profile should always be used in this case, but that
+policies in this space need to be defined on a case-by-case basis.
+
+SIG Auth may reconsider this position in the future, should a clear need for other profiles arise.
+-->
+这里定义的三种策略框架有一个明晰的线性递进关系，从最安全（Restricted）到最不安全，
+并且覆盖了很大范围的工作负载。特权要求超出 Baseline 策略者通常是特定于应用的需求，
+所以我们没有在这个范围内提供标准框架。
+这并不意味着在这样的情形下仍然只能使用 Privileged 框架，只是说处于这个范围的
+策略需要因地制宜地定义。
+
+SIG Auth 可能会在将来考虑这个范围的框架，前提是有对其他框架的需求。
+
+<!--
+### What's the difference between a security policy and a security context?
+
+[Security Contexts](/docs/tasks/configure-pod-container/security-context/) configure Pods and
+Containers at runtime. Security contexts are defined as part of the Pod and container specifications
+in the Pod manifest, and represent parameters to the container runtime.
+-->
+### 安全策略与安全上下文的区别是什么？
+
+[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
+和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，所代表的是
+传递给容器运行时的参数。
+
+<!--
+Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
+as well as other related parameters outside the Security Context. As of July 2021, 
+[Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
+built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/). 
+
+Other alternatives for enforcing security profiles are being developed in the Kubernetes
+ecosystem, such as: 
+- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
+- [Kubewarden](https://github.com/kubewarden).
+- [Kyverno](https://kyverno.io/policies/pod-security/).
+-->
+安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
+在 2020 年 7 月，
+[Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃，
+取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。
+
+Kubernetes 生态系统中还在开发一些其他的替代方案，例如
+- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)。
+- [Kubewarden](https://github.com/kubewarden)。
+- [Kyverno](https://kyverno.io/policies/pod-security/)。
+
+<!--
+### What profiles should I apply to my Windows Pods?
+
+Windows in Kubernetes has some limitations and differentiators from standard Linux-based
+workloads. Specifically, the Pod SecurityContext fields [have no effect on
+Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
+such, no standardized Pod Security profiles currently exists.
+-->
+### 我应该为我的 Windows Pod 实施哪种框架？
+
+Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
+尤其是 Pod SecurityContext 字段
+[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+因此，目前没有对应的标准 Pod 安全性框架。
+
+
+<!-- 
+If you apply the restricted profile for a Windows pod, this **may** have an impact on the pod
+at runtime. The restricted profile requires enforcing Linux-specific restrictions (such as seccomp
+profile, and disallowing privilege escalation). If the kubelet and / or its container runtime ignore
+these Linux-specific values, then the Windows pod should still work normally within the restricted
+profile. However, the lack of enforcement means that there is no additional restriction, for Pods
+that use Windows containers, compared to the baseline profile.
+
+The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged.
+-->
+
+如果你为一个 Windows Pod 应用了 Restricted 策略，**可能会** 对该 Pod 的运行时产生影响。
+Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile，并且禁止特权提升）。
+如果 kubelet 和/或其容器运行时忽略了 Linux 特有的值，那么应该不影响 Windows Pod 正常工作。
+然而，对于使用 Windows 容器的 Pod 来说，缺乏强制执行意味着相比于 Restricted 策略，没有任何额外的限制。
+
+你应该只在 Privileged 策略下使用 HostProcess 标志来创建 HostProcess Pod。
+在 Baseline 和 Restricted 策略下，创建 Windows HostProcess Pod 是被禁止的，
+因此任何 HostProcess Pod 都应该被认为是有特权的。
+
+<!--
+### What about sandboxed Pods?
+
+There is not currently an API standard that controls whether a Pod is considered sandboxed or
+not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata
+Containers), but there is no standard definition of what a sandboxed runtime is.
+
+The protections necessary for sandboxed workloads can differ from others. For example, the need to
+restrict privileged permissions is lessened when the workload is isolated from the underlying
+kernel. This allows for workloads requiring heightened permissions to still be isolated.
+
+Additionally, the protection of sandboxed workloads is highly dependent on the method of
+sandboxing. As such, no single recommended policy is recommended for all sandboxed workloads.
+-->
+### 沙箱（Sandboxed） Pod 怎么处理？
+
+现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。
+沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过
+目前还没有关于什么是沙箱化运行时的标准定义。
+
+沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时，
+限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。
+
+此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
+因此，现在还没有针对所有沙箱化负载的建议策略。

content/zh-cn/docs/concepts/security/rbac-good-practices.md

@@ -0,0 +1,355 @@
+---
+title: 基于角色的访问控制良好实践
+description: >
+  为集群操作人员提供的良好的 RBAC 设计原则和实践。
+content_type: concept
+---
+
+<!--
+reviewers:
+title: Role Based Access Control Good Practices
+description: >
+  Principles and practices for good RBAC design for cluster operators.
+content_type: concept
+-->
+
+<!-- overview -->
+
+<!--
+Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control 
+to ensure that cluster users and workloads have only the access to resources required to 
+execute their roles. It is important to ensure that, when designing permissions for cluster
+users, the cluster administrator understands the areas where privilge escalation could occur, 
+to reduce the risk of excessive access leading to security incidents.
+
+The good practices laid out here should be read in conjunction with the general [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
+-->
+
+Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}}
+是一项重要的安全控制措施，用于保证集群用户和工作负载只能访问履行自身角色所需的资源。
+在为集群用户设计权限时，请务必确保集群管理员知道可能发生特权提级的地方，
+降低因过多权限而导致安全事件的风险。
+
+此文档的良好实践应该与通用
+[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。
+
+<!-- body -->
+
+<!--
+## General good practice
+
+### Least privilege
+-->
+## 通用的良好实践 {#general-good-practice}
+
+### 最小特权  {#least-privilege}
+
+<!--
+Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions 
+explicitly required for their operation should be used. Whilst each cluster will be different, 
+some general rules that can be applied are :
+-->
+理想情况下，分配给用户和服务帐户的 RBAC 权限应该是最小的。
+仅应使用操作明确需要的权限，虽然每个集群会有所不同，但可以应用的一些常规规则：
+
+<!--
+ - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to 
+   ClusterRoleBindings to give users rights only within a specific namespace.
+ - Avoid providing wildcard permissions when possible, especially to all resources.
+   As Kubernetes is an extensible system, providing wildcard access gives rights
+   not just to all object types presently in the cluster, but also to all future object types
+   which are created in the future.
+ - Administrators should not use `cluster-admin` accounts except where specifically needed. 
+   Providing a low privileged account with [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
+   can avoid accidental modification of cluster resources.
+ - Avoid adding users to the `system:masters` group. Any user who is a member of this group 
+   bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be 
+   revoked by removing Role Bindings or Cluster Role Bindings. As an aside, if a cluster is 
+   using an authorization webhook, membership of this group also bypasses that webhook (requests 
+   from users who are members of that group are never sent to the webhook)
+-->
+- 尽可能在命名空间级别分配权限。授予用户在特定命名空间中的权限时使用 RoleBinding
+  而不是 ClusterRoleBinding。
+- 尽可能避免通过通配符设置权限，尤其是对所有资源的权限。
+  由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型，
+  还包含所有未来被创建的所有对象类型。
+- 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供
+  [伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)
+  可以避免意外修改集群资源。
+- 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查，
+  始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding`
+  来取消其权限。顺便说一句，如果集群是使用 Webhook 鉴权，此组的成员身份也会绕过该 
+  Webhook（来自属于该组成员的用户的请求永远不会发送到 Webhook）。
+ 
+<!--
+### Minimize distribution of privileged tokens
+-->
+### 最大限度地减少特权令牌的分发 {#minimize-distribution-of-privileged-tokens}
+
+<!--
+Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions (for example, any of the rights listed under
+[privilege escalation risks](#privilege-escalation-risks)). 
+In cases where a workload requires powerful permissions, consider the following practices:
+ - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
+  are necessary and are run with least privilege to limit the blast radius of container escapes.
+ - Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using 
+   [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/), [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) to ensure 
+   pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
+   situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
+-->
+理想情况下，不应为 Pod 分配具有强大权限（例如，在[特权提级的风险](#privilege-escalation-risks)中列出的任一权限）的服务帐户。
+如果工作负载需要比较大的权限，请考虑以下做法：
+- 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的，
+  并且以最小权限运行，以限制容器逃逸的影响范围。
+- 避免将此类 Pod 与不可信任或公开的 Pod 在一起运行。
+  考虑使用[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)、
+  [节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或
+  [Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保 
+  Pod 不会与不可信或不太受信任的 Pod 一起运行。
+  特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。
+<!--
+### Hardening
+
+Kubernetes defaults to providing access which may not be required in every cluster. Reviewing 
+the RBAC rights provided by default can provide opportunities for security hardening.
+In general, changes should not be made to rights provided to `system:` accounts some options 
+to harden cluster rights exist:
+-->
+### 加固 {#hardening}
+
+Kubernetes 默认提供访问权限并非是每个集群都需要的。
+审查默认提供的 RBAC 权限为安全加固提供了机会。
+一般来说，不应该更改 `system:` 帐户的某些权限，有一些方式来强化现有集群的权限：
+
+<!--
+- Review bindings for the `system:unauthenticated` group and remove where possible, as this gives 
+  access to anyone who can contact the API server at a network level.
+- Avoid the default auto-mounting of service account tokens by setting
+  `automountServiceAccountToken: false`. For more details, see
+  [using default service account token](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server).
+  Setting this value for a Pod will overwrite the service account setting, workloads
+  which require service account tokens can still mount them.
+-->
+- 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其删除，
+  因为这会给所有能够访问 API 服务器的人以网络级别的权限。
+- 通过设置 `automountServiceAccountToken: false` 来避免服务账号令牌的默认自动挂载，
+  有关更多详细信息，请参阅[使用默认服务账号令牌](/zh/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。
+  此参数可覆盖 Pod 服务账号设置，而需要服务账号令牌的工作负载仍可以挂载。
+
+<!--
+### Periodic review
+
+It is vital to periodically review the Kubernetes RBAC settings for redundant entries and 
+possible privilege escalations.
+If an attacker is able to create a user account with the same name as a deleted user,
+they can automatically inherit all the rights of the deleted user, especially the
+rights assigned to that user.
+ --> 
+### 定期检查  {#periodic-review}
+定期检查 Kubernetes RBAC 设置是否有冗余条目和提权可能性是至关重要的。
+如果攻击者能够创建与已删除用户同名的用户账号，
+他们可以自动继承被删除用户的所有权限，尤其是分配给该用户的权限。
+
+<!--
+## Kubernetes RBAC - privilege escalation risks {#privilege-escalation-risks}
+
+Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account
+to escalate their privileges in the cluster or affect systems outside the cluster.
+
+This section is intended to provide visibility of the areas where cluster operators 
+should take care, to ensure that they do not inadvertantly allow for more access to clusters than intended.
+-->
+## Kubernetes RBAC - 权限提权的风险 {#privilege-escalation-risks}
+
+在 Kubernetes RBAC 中有许多特权，如果被授予，
+用户或服务帐户可以提升其在集群中的权限并可能影响集群外的系统。
+
+本节旨在提醒集群操作员需要注意的不同领域，
+以确保他们不会无意中授予超出预期的集群访问权限。
+
+<!--
+### Listing secrets
+
+It is generally clear that allowing `get` access on Secrets will allow a user to read their contents.
+It is also important to note that `list` and `watch` access also effectively allow for users to reveal the Secret contents.
+For example, when a List response is returned (for example, via `kubectl get secrets -A -o yaml`), the response
+includes the contents of all Secrets.
+-->
+### 列举 Secret {#listing-secrets}
+
+大家都很清楚，若允许对 Secrets 执行 `get` 访问，用户就获得了访问 Secret 内容的能力。
+同样需要注意的是：`list` 和 `watch` 访问也会授权用户获取 Secret 的内容。
+例如，当返回 List 响应时（例如，通过 
+`kubectl get secrets -A -o yaml`），响应包含所有 Secret 的内容。
+
+<!--
+### Workload creation
+
+Users who are able to create workloads (either Pods, or
+[workload resources](/docs/concepts/workloads/controllers/) that manage Pods) will
+be able to gain access to the underlying node unless restrictions based on the Kubernetes
+[Pod Security Standards](/docs/concepts/security/pod-security-standards/) are in place.
+-->
+### 工作负载的创建 {#workload-creation}
+
+能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)） 
+能够访问下层的节点，除非基于 Kubernetes 的
+[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。
+
+<!--
+Users who can run privileged Pods can use that access to gain node access and potentially to
+further elevate their privileges. Where you do not fully trust a user or other principal
+with the ability to create suitably secure and isolated Pods, you should enforce either the
+**Baseline** or **Restricted** Pod Security Standard.
+You can use [Pod Security admission](/docs/concepts/security/pod-security-admission/)
+or other (third party) mechanisms to implement that enforcement.
+-->
+可以运行特权 Pod 的用户可以利用该访问权限获得节点访问权限，
+并可能进一步提升他们的特权。如果你不完全信任某用户或其他主体，
+不相信他们能够创建比较安全且相互隔离的 Pod，你应该强制实施 **Baseline**
+或 **Restricted** Pod 安全标准。
+你可以使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
+
+<!--
+You can also use the deprecated [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) mechanism
+to restrict users' abilities to create privileged Pods (N.B. PodSecurityPolicy is scheduled for removal
+in version 1.25).
+-->
+你还可以使用已弃用的 [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)
+机制以限制用户创建特权 Pod 的能力 （特别注意：PodSecurityPolicy 已计划在版本 1.25 中删除）。
+
+<!--
+Creating a workload in a namespace also grants indirect access to Secrets in that namespace. 
+Creating a pod in kube-system or a similarly privileged namespace can grant a user access to 
+Secrets they would not have through RBAC directly.
+-->
+在命名空间中创建工作负载还会授予对该命名空间中 Secret 的间接访问权限。
+在 kube-system 或类似特权的命名空间中创建 Pod 
+可以授予用户不需要通过 RBAC 即可获取 Secret 访问权限。
+
+<!--
+### Persistent volume creation
+
+As noted in the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) documentation, access to create PersistentVolumes can allow for escalation of access to the underlying host. Where access to persistent storage is required trusted administrators should create 
+PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.
+-->
+### 持久卷的创建 {#persistent-volume-creation}
+
+如 [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) 
+文档中所述，创建 PersistentVolumes 的权限可以提权访问底层主机。
+如果需要访问 PersistentVolume，受信任的管理员应该创建 `PersistentVolume`，
+受约束的用户应该使用 `PersistentVolumeClaim` 访问该存储。
+
+<!--
+### Access to `proxy` subresource of Nodes
+
+Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 
+which allows for command execution on every pod on the node(s) which they have rights to. 
+This access bypasses audit logging and admission control, so care should be taken before 
+granting rights to this resource.
+-->
+### 访问 Node 的 `proxy` 子资源  {#access-to-proxy-subresource-of-nodes}
+
+有权访问 Node 对象的 proxy 子资源的用户有权访问 Kubelet API，
+这允许在他们有权访问的节点上的所有 Pod 上执行命令。
+此访问绕过审计日志记录和准入控制，因此在授予对此资源的权限前应小心。
+
+<!--
+### Escalate verb
+
+Generally the RBAC system prevents users from creating clusterroles with more rights than 
+they possess. The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
+users with this right can effectively escalate their privileges.
+-->
+### esclate 动词 {#escalate-verb}
+通常，RBAC 系统会阻止用户创建比他所拥有的更多权限的 `ClusterRole`。
+而 `escalate` 动词是个例外。如
+[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
+中所述，拥有此权限的用户可以有效地提升他们的权限。
+
+<!--
+### Bind verb
+
+Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes 
+in-built protections against privilege escalation, allowing users to create bindings to 
+roles with rights they do not already have.
+-->
+### bind 动词  {#bind-verb}
+
+与 `escalate` 动作类似，授予此权限的用户可以绕过 Kubernetes
+对权限提升的内置保护，用户可以创建并绑定尚不具有的权限的角色。
+
+<!--
+### Impersonate verb
+
+This verb allows users to impersonate and gain the rights of other users in the cluster. 
+Care should be taken when granting it, to ensure that excessive permissions cannot be gained 
+via one of the impersonated accounts.
+-->
+### impersonate 动词 {#impersonate-verb}
+
+此动词允许用户伪装并获得集群中其他用户的权限。
+授予它时应小心，以确保通过其中一个伪装账号不会获得过多的权限。
+
+<!--
+### CSRs and certificate issuing
+
+The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` 
+where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates 
+which allow users to authenticate to the cluster. Those client certificates can have arbitrary 
+names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.
+-->
+### CSR 和证书颁发 {#csrs-and-certificate-issuing}
+
+CSR API 允许用户拥有 `create` CSR 的权限和 `update`
+`certificatesigningrequests/approval` 的权限，
+其中签名者是 `kubernetes.io/kube-apiserver-client`，
+通过此签名创建的客户端证书允许用户向集群进行身份验证。
+这些客户端证书可以包含任意的名称，包括 Kubernetes 系统组件的副本。
+这将有利于特权提级。
+
+<!--
+### Token request
+
+Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue 
+tokens for existing service accounts. 
+-->
+### 令牌请求 {#token-request}
+
+拥有 `serviceaccounts/token` 的 `create` 权限的用户可以创建 
+TokenRequest 来发布现有服务帐户的令牌。
+
+<!--
+### Control admission webhooks
+
+Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` 
+can control webhooks that can read any object admitted to the cluster, and in the case of 
+mutating webhooks, also mutate admitted objects.
+-->
+###  控制准入 Webhook {#control-admission-webhooks}
+
+可以控制 `validatingwebhookconfigurations` 或 `mutatingwebhookconfigurations`
+的用户可以控制能读取任何允许进入集群的对象的 webhook，
+并且在有变更 webhook 的情况下，还可以变更准入的对象。
+
+<!--
+## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
+
+### Object creation denial-of-service {#object-creation-dos}
+Users who have rights to create objects in a cluster may be able to create sufficient large 
+objects to create a denial of service condition either based on the size or number of objects, as discussed in
+[etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be
+specifically relevant in multi-tenant clusters if semi-trusted or untrusted users 
+are allowed limited access to a system.
+
+One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota)
+to limit the quantity of objects which can be created.
+-->
+## Kubernetes RBAC - 拒绝服务攻击的风险 {#denial-of-service-risks}
+
+### 对象创建拒绝服务 {#object-creation-dos}
+有权在集群中创建对象的用户根据创建对象的大小和数量可能会创建足够大的对象，
+产生拒绝服务状况，如 [Kubernetes 使用的 etcd 容易受到 OOM 攻击](https://github.com/kubernetes/kubernetes/issues/107325)中的讨论。
+允许太不受信任或者不受信任的用户对系统进行有限的访问在多租户集群中是特别重要的。
+
+缓解此问题的一种选择是使用[资源配额](/zh/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。

content/zh-cn/docs/concepts/security/windows-security.md

@@ -0,0 +1,109 @@
+---
+title: Windows 节点的安全性
+content_type: concept
+weight: 75
+---
+<!--
+reviewers:
+- jayunit100
+- jsturtevant
+- marosset
+- perithompson
+  title:    Security For Windows Nodes
+  content_type: concept
+  weight: 75
+-->
+
+<!-- overview -->
+
+<!--
+This page describes security considerations and best practices specific to the Windows operating system.
+-->
+本篇介绍特定于 Windows 操作系统的安全注意事项和最佳实践。
+
+<!-- body -->
+
+<!--
+## Protection for Secret data on nodes
+-->
+## 保护节点上的 Secret 数据
+
+<!--
+On Windows, data from Secrets are written out in clear text onto the node's local
+storage (as compared to using tmpfs / in-memory filesystems on Linux). As a cluster
+operator, you should take both of the following additional measures:
+-->
+在 Windows 上，来自 Secret 的数据以明文形式写入节点的本地存储
+（与在 Linux 上使用 tmpfs / 内存中文件系统不同）。
+作为集群操作员，你应该采取以下两项额外措施：
+
+<!--
+1. Use file ACLs to secure the Secrets' file location.
+1. Apply volume-level encryption using [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).
+-->
+1. 使用文件 ACL 来保护 Secret 的文件位置。
+2. 使用 [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)
+   进行卷级加密。
+
+<!--
+## Container users
+-->
+## 容器用户
+
+<!--
+[RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername)
+can be specified for Windows Pods or containers to execute the container
+processes as specific user. This is roughly equivalent to
+[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups).
+-->
+可以为 Windows Pod 或容器指定 [RunAsUsername](/zh/docs/tasks/configure-pod-container/configure-runasusername)
+以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh/docs/concepts/policy/pod-security-policy/#users-and-groups)。
+
+<!--
+Windows containers offer two default user accounts, ContainerUser and ContainerAdministrator.
+The differences between these two user accounts are covered in
+[When to use ContainerAdmin and ContainerUser user accounts](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts) within Microsoft's _Secure Windows containers_ documentation.
+-->
+Windows 容器提供两个默认用户帐户，ContainerUser 和 ContainerAdministrator。
+在微软的 Windows 容器安全文档
+[何时使用 ContainerAdmin 和 ContainerUser 用户帐户](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)
+中介绍了这两个用户帐户之间的区别。
+
+<!--
+Local users can be added to container images during the container build process.
+-->
+在容器构建过程中，可以将本地用户添加到容器镜像中。
+
+{{< note >}}
+<!--
+* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) based images run as `ContainerUser` by default
+* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) based images run as `ContainerAdministrator` by default
+-->
+* 基于 [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 的镜像默认以 `ContainerUser` 运行
+* 基于 [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 的镜像默认以 `ContainerAdministrator` 运行
+{{< /note >}}
+
+<!--
+Windows containers can also run as Active Directory identities by utilizing [Group Managed Service Accounts](/docs/tasks/configure-pod-container/configure-gmsa/)
+-->
+Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为
+Active Directory 身份运行。
+
+<!--
+## Pod-level security isolation
+-->
+## Pod 级安全隔离
+
+<!--
+Linux-specific pod security context mechanisms (such as SELinux, AppArmor, Seccomp, or custom
+POSIX capabilities) are not supported on Windows nodes.
+-->
+Windows 节点不支持特定于 Linux 的 Pod 安全上下文机制（例如 SELinux、AppArmor、Seccomp 或自定义 POSIX 权能字）。
+
+<!--
+Privileged containers are [not supported](#compatibility-v1-pod-spec-containers-securitycontext) on Windows.
+Instead [HostProcess containers](/docs/tasks/configure-pod-container/create-hostprocess-pod) can be used on Windows to perform many of the tasks performed by privileged containers on Linux.
+-->
+Windows 上[不支持](/zh/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext)特权容器。
+然而，可以在 Windows 上使用 [HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod)来执行
+Linux 上特权容器执行的许多任务。