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

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

@@ -60,7 +60,7 @@ some general rules that can be applied are :
    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 that currently exist in the cluster, but also to all future object types
+   not just to all object types that currently exist in the cluster, but also to all 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
@@ -82,7 +82,7 @@ some general rules that can be applied are :
   可以避免意外修改集群资源。
 - 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查，
   始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding`
-  来取消其权限。顺便说一句，如果集群是使用 Webhook 鉴权，此组的成员身份也会绕过该 
+  来取消其权限。顺便说一句，如果集群使用 Webhook 鉴权，此组的成员身份也会绕过该
   Webhook（来自属于该组成员的用户的请求永远不会发送到 Webhook）。
 
 <!--
@@ -106,6 +106,7 @@ In cases where a workload requires powerful permissions, consider the following
 -->
 理想情况下，不应为 Pod 分配具有强大权限（例如，在[特权提级的风险](#privilege-escalation-risks)中列出的任一权限）的服务帐户。
 如果工作负载需要比较大的权限，请考虑以下做法：
+
 - 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的，
   并且以最小权限运行，以限制容器逃逸的影响范围。
 - 避免将此类 Pod 与不可信任或公开的 Pod 在一起运行。
@@ -154,6 +155,7 @@ they can automatically inherit all the rights of the deleted user, especially th
 rights assigned to that user.
  -->
 ### 定期检查  {#periodic-review}
+
 定期检查 Kubernetes RBAC 设置是否有冗余条目和提权可能性是至关重要的。
 如果攻击者能够创建与已删除用户同名的用户账号，
 他们可以自动继承被删除用户的所有权限，尤其是分配给该用户的权限。
@@ -193,16 +195,21 @@ includes the contents of all Secrets.
 <!--
 ### 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.
+Permission to create workloads (either Pods, or
+[workload resources](/docs/concepts/workloads/controllers/) that manage Pods) in a namespace
+implicitly grants access to many other resources in that namespace, such as Secrets, ConfigMaps, and
+PersistentVolumes that can be mounted in Pods. Additionally, since Pods can run as any
+[ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/), granting permission
+to create workloads also implicitly grants the API access levels of any service account in that
+namespace.
 -->
 ### 工作负载的创建 {#workload-creation}
 
-能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)） 
-能够访问下层的节点，除非基于 Kubernetes 的
-[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)做限制。
+在一个命名空间中创建工作负载（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)）
+的权限隐式地授予了对该命名空间中许多其他资源的访问权限，例如可以挂载在
+Pod 中的 Secret、ConfigMap 和 PersistentVolume。
+此外，由于 Pod 可以被任何[服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)运行，
+因此授予创建工作负载的权限也会隐式地授予该命名空间中任何服务账号的 API 访问级别。
 
 <!--
 Users who can run privileged Pods can use that access to gain node access and potentially to
@@ -219,21 +226,14 @@ or other (third party) mechanisms to implement that enforcement.
 你可以使用 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
 
 <!-- 
-You can also use the deprecated [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) mechanism
-to restrict users' abilities to create privileged Pods (N.B. PodSecurityPolicy is scheduled for removal
-in version 1.25).
+For these reasons, namespaces should be used to separate resources requiring different levels of
+trust or tenancy. It is still considered best practice to follow [least privilege](#least-privilege)
+principles and assign the minimum set of permissions, but boundaries within a namespace should be
+considered weak.
 -->
-你还可以使用已弃用的 [PodSecurityPolicy](/zh-cn/docs/concepts/security/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 访问权限。
+出于这些原因，命名空间应该用于隔离不同的信任级别或不同租户所需的资源。
+遵循[最小特权](#least-privilege)原则并分配最小权限集仍被认为是最佳实践，
+但命名空间内的边界概念应视为比较弱。
 
 <!--
 ### Persistent volume creation
@@ -272,6 +272,7 @@ The exception to this is the `escalate` verb. As noted in the [RBAC documentatio
 users with this right can effectively escalate their privileges.
 -->
 ### esclate 动词 {#escalate-verb}
+
 通常，RBAC 系统会阻止用户创建比他所拥有的更多权限的 `ClusterRole`。
 而 `escalate` 动词是个例外。如
 [RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
@@ -359,6 +360,7 @@ 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)中的讨论。
 允许太不受信任或者不受信任的用户对系统进行有限的访问在多租户集群中是特别重要的。
@@ -370,4 +372,5 @@ to limit the quantity of objects which can be created.
 <!--
 * To learn more about RBAC, see the [RBAC documentation](/docs/reference/access-authn-authz/rbac/).
 -->
+
 * 了解有关 RBAC 的更多信息，请参阅 [RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/)。