whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh]Update concepts pages(part-3) for links with '/zh/' prefix, using new prefix '/zh-cn/'

Browse Source
This commit is contained in:
howieyuen
2022-06-23 20:18:40 +08:00
parent e0d6f94bf6
commit 5f0ec40aaa
29 changed files with 260 additions and 260 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/concepts/security/controlling-access.md
+21 -21
View File
@@ -28,8 +28,8 @@ 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。
用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)。
人类用户和 [Kubernetes 服务账户](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。
当请求到达 API 时，它会经历多个阶段，如下图所示：
![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg)
@@ -72,7 +72,7 @@ Authenticators are described in more detail in
-->
如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。
集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。
身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
身份认证组件在[认证](/zh-cn/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
<!--
The input to the authentication step is the entire HTTP request; however, it typically
@@ -182,7 +182,7 @@ Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhoo
如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。
要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息，
请参阅[鉴权](/zh/docs/reference/access-authn-authz/authorization/)。
请参阅[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)。
<!-- ## Admission control -->
## 准入控制 {#admission-control}
@@ -223,7 +223,7 @@ for the corresponding API object, and then written to the object store (shown as
除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。
可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
可用的准入控制模块在[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。
@@ -241,7 +241,7 @@ For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).
Kubernetes 审计提供了一套与安全相关的、按时间顺序排列的记录，其中记录了集群中的操作序列。
集群对用户、使用 Kubernetes API 的应用程序以及控制平面本身产生的活动进行审计。
更多信息请参考 [审计](/zh/docs/tasks/debug/debug-cluster/audit/).
更多信息请参考 [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/).
<!-- ## API server ports and IPs -->
## API 服务器端口和 IP {#api-server-ports-and-ips}
@@ -327,23 +327,23 @@ You can learn about:
-->
阅读更多有关身份认证、鉴权和 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-cn/docs/reference/access-authn-authz/authentication/)
- [使用 Bootstrap 令牌进行身份认证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)
- [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
- [动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)
- [基于角色的访问控制](/zh-cn/docs/reference/access-authn-authz/rbac/)
- [基于属性的访问控制](/zh-cn/docs/reference/access-authn-authz/abac/)
- [节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)
- [Webhook 鉴权](/zh-cn/docs/reference/access-authn-authz/webhook/)
- [证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)
- 包括 [CSR 认证](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
和[证书签名](/zh-cn/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/)
- [开发者指导](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
- [管理](/zh-cn/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)
[Secrets](/zh-cn/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
获取 API 凭证.
content/zh-cn/docs/concepts/security/overview.md
+17 -17
View File
@@ -165,7 +165,7 @@ good information practices, read and follow the advice about
-->
### 集群组件 {#cluster-components}
如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
<!--
### Components in the cluster (your application) {#cluster-applications}
@@ -196,13 +196,13 @@ TLS for Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networ
工作负载安全性关注领域 | 建议 |
------------------------------ | --------------------- |
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
RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/
认证方式 | https://kubernetes.io/zh-cn/docs/concepts/security/controlling-access/
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/encrypt-data/
确保 Pod 符合定义的 Pod 安全标准 | https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation
服务质量（和集群资源管理）| https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/
网络策略 | https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/
Kubernetes Ingress 的 TLS 支持 | https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#tls
<!--
## Container
@@ -226,7 +226,7 @@ Use container runtime with stronger isolation | Select [container runtime classe
容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，你应该扫描你的容器里的已知漏洞。
镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。
禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。
使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。
使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh-cn/docs/concepts/containers/runtime-class/)。
<!--
## Code
@@ -283,12 +283,12 @@ Learn about related Kubernetes security topics:
-->
学习了解相关的 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)
* [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)
* [Pod 的网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)
* [控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)
* [保护你的集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)
* 为控制面[加密通信中的数据](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/)
* [加密静止状态的数据](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)
* [Kubernetes 中的 Secret](/zh-cn/docs/concepts/configuration/secret/)
* [运行时类](/zh-cn/docs/concepts/containers/runtime-class)
content/zh-cn/docs/concepts/security/pod-security-admission.md
+16 -16
View File
@@ -29,7 +29,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta
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/)
Kubernetes [Pod 安全性标准（Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards/)
为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
<!--
@@ -41,7 +41,7 @@ are created.
-->
作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_
{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}，
作为 [PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)
作为 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)
特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在
{{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。
@@ -51,7 +51,7 @@ 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)。
[移除](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)。
{{< /note >}}
<!-- body -->
@@ -75,7 +75,7 @@ is a beta feature and is enabled by default. You must have this feature gate ena
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 特性，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性，
默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。
@@ -132,11 +132,11 @@ Standards](/docs/concepts/security/pod-security-standards): `privileged`, `basel
`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)
Pod 安全性准入插件对 Pod 的[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)
有一定的要求，并且依据 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)
所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。
关于这些需求的更进一步讨论，请参阅
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。
[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)页面。
<!--
## Pod Security Admission labels for namespaces
@@ -170,7 +170,7 @@ Mode | Description
模式 | 描述
:---------|:------------
**enforce** | 策略违例会导致 Pod 被拒绝
**audit** | 策略违例会触发[审计日志](/zh/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
**audit** | 策略违例会触发[审计日志](/zh-cn/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
**warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。
{{< /table >}}
@@ -216,7 +216,7 @@ 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/)。
[使用名字空间标签来强制实施 Pod 安全标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。
<!--
## Workload resources and Pod templates
@@ -232,7 +232,7 @@ 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/)
{{< glossary_tooltip term_id="job">}} 这类[工作负载对象](/zh-cn/docs/concepts/workloads/controllers/)
来间接创建的。工作负载对象为工作负载资源定义一个 _Pod 模板_ 和一个对应的
负责基于该模板来创建 Pod 的{{< glossary_tooltip term_id="controller" text="控制器" >}}。
为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。
@@ -250,7 +250,7 @@ Exemptions can be statically configured in the
你可以为 Pod 安全性的实施设置 _豁免（Exemptions）_ 规则，
从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。
豁免规则可以在[准入控制器配置](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
豁免规则可以在[准入控制器配置](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
中静态配置。
<!--
@@ -322,9 +322,9 @@ current policy level:
- [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/)
- [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)
- [强制实施 Pod 安全性标准](/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards/)
- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
- [使用名字空间标签来实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)
content/zh-cn/docs/concepts/security/pod-security-policy.md
+20 -20
View File
@@ -24,9 +24,9 @@ For more information on the deprecation,
see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
-->
PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。
我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)，
我们建议迁移到 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission)，
或者第三方的准入插件。
若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。
若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。
关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
{{< /caution >}}
@@ -107,8 +107,8 @@ cluster.
-->
## 启用 Pod 安全策略 {#enabling-pod-security-policies}
Pod 安全策略实现为一种可选的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。
[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施
Pod 安全策略实现为一种可选的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。
[启用了准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施
Pod 安全策略，不过如果没有授权认可策略之前即启用准入控制器 **将导致集群中无法创建任何 Pod**。
<!--
@@ -132,7 +132,7 @@ must be authorized to use the policy, by allowing the `use` verb on the policy.
PodSecurityPolicy 资源被创建时，并不执行任何操作。为了使用该资源，
需要对发出请求的用户或者目标 Pod
的[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)授权，
的[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)授权，
通过允许其对策略执行 `use` 动词允许其使用该策略。
<!--
@@ -146,8 +146,8 @@ so the preferred method for authorizing policies is to grant access to the
pod's service account (see [example](#run-another-pod)).
-->
大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
或者经由控制器管理器模版化的控制器创建。
赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。
因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限
@@ -164,7 +164,7 @@ policies. The rules to grant access look like this:
-->
### 通过 RBAC 授权 {#via-rbac}
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes
[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes
鉴权模式，可以很容易地用来授权策略访问。
首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。
@@ -272,7 +272,7 @@ For more examples of RBAC bindings, see
[Role Binding Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
For a complete example of authorizing a PodSecurityPolicy, see [below](#example).
-->
参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples)查看
参阅[角色绑定示例](/zh-cn/docs/reference/access-authn-authz/rbac#role-binding-examples)查看
RBAC 绑定的更多实例。
参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。
@@ -303,7 +303,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
-->
1. 将 PodSecurityPolicies 限制为
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略：
[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)所定义的策略：
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
@@ -371,9 +371,9 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
-->
### 故障排查 {#troubleshooting}
- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
- [控制器管理器组件](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
必须运行在安全的 API 端口之上，并且不能拥有超级用户的访问权限。
参阅[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access)以了解
参阅[控制 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access)以了解
API 服务器的访问控制。
如果控制器管理器通过可信的 API 端口连接（也称作 `localhost` 监听组件），
@@ -381,7 +381,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
用户亦能授予自身创建特权容器的特权。
关于配置控制器管理器鉴权的进一步细节，
请参阅[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。
请参阅[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)。
<!--
## Policy Order
@@ -467,7 +467,7 @@ The name of a PodSecurityPolicy object must be a valid
在一个文件中定义一个示例的 PodSecurityPolicy 对象。
这里的策略只是用来禁止创建有特权要求的 Pods。
PodSecurityPolicy 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
{{< codenew file="policy/example-psp.yaml" >}}
@@ -794,7 +794,7 @@ several security mechanisms.
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
-->
更多的示例可参考
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。
<!--
## Policy Reference
@@ -868,7 +868,7 @@ The **recommended minimum set** of allowed volumes for new PSPs are:
### 卷和文件系统 {#volumes-and-file-systems}
**Volumes** - 提供一组被允许的卷类型列表。可被允许的值对应于创建卷时可以设置的卷来源。
卷类型的完整列表可参见[卷类型](/zh/docs/concepts/storage/volumes/#types-of-volumes)。
卷类型的完整列表可参见[卷类型](/zh-cn/docs/concepts/storage/volumes/#types-of-volumes)。
此外，`*` 可以用来允许所有卷类型。
对于新的 Pod 安全策略设置而言，建议设置的卷类型的**最小列表**包含：
@@ -1235,7 +1235,7 @@ documentation](/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations).
通过 PodSecurityPolicy 上的注解来控制。
详情请参阅
[AppArmor 文档](/zh/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。
[AppArmor 文档](/zh-cn/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。
<!--
@@ -1255,7 +1255,7 @@ are:
### Seccomp
从 Kubernetes v1.19 开始，你可以使用 Pod 或容器的 `securityContext` 中的 `seccompProfile`
字段来[控制 seccomp 配置的使用](/zh/docs/tutorials/security/seccomp/)。
字段来[控制 seccomp 配置的使用](/zh-cn/docs/tutorials/security/seccomp/)。
在更早的版本中，seccomp 是通过为 Pod 添加注解来控制的。
相同的 PodSecurityPolicy 可以用于不同版本，进而控制如何应用对应的字段或注解。
@@ -1336,7 +1336,7 @@ By default, all safe sysctls are allowed.
<!--
Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy).
-->
参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。
参阅 [Sysctl 文档](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。
## {{% heading "whatsnext" %}}
@@ -1353,7 +1353,7 @@ Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluste
Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)，
了解 Pod 安全策略的未来。
- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)，
- 参阅[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)，
了解策略建议。
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)，
了解 API 细节。
content/zh-cn/docs/concepts/security/pod-security-standards.md
+7 -7
View File
@@ -117,7 +117,7 @@ fail validation.
</td> -->
<td>
<p>Windows Pod 提供了运行
<a href="/zh/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess 容器</a> 的能力，
<a href="/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess 容器</a> 的能力，
这使得对 Windows 节点的特权访问成为可能。
基线策略中对宿主的特权访问是被禁止的。
HostProcess Pod 是 Kubernetes <strong>v1.22</strong> 版本的
@@ -833,13 +833,13 @@ of individual policies are not defined here.
随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。
[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/)
[**Pod 安全性准入控制器**](/zh-cn/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/) （已弃用）
[**PodSecurityPolicy**](/zh-cn/docs/concepts/security/pod-security-policy/) （已弃用）
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
@@ -896,7 +896,7 @@ in the Pod manifest, and represent parameters to the container runtime.
-->
### 安全策略与安全上下文的区别是什么？
[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
[安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，
所代表的是传递给容器运行时的参数。
@@ -908,8 +908,8 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit
-->
安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
在 2020 年 7 月，
[Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃，
取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。
[Pod 安全性策略](/zh-cn/docs/concepts/security/pod-security-policy/)已被废弃，
取而代之的是内置的 [Pod 安全性准入控制器](/zh-cn/docs/concepts/security/pod-security-admission/)。
<!--
### What profiles should I apply to my Windows Pods?
@@ -923,7 +923,7 @@ such, no standardized Pod Security profiles currently exists.
Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
尤其是 Pod SecurityContext
字段[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
字段[对 Windows 不起作用](/zh-cn/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
因此，目前没有对应的标准 Pod 安全性框架。
<!--
content/zh-cn/docs/concepts/security/rbac-good-practices.md
+11 -11
View File
@@ -31,7 +31,7 @@ Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}}
降低因过多权限而导致安全事件的风险。
此文档的良好实践应该与通用
[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。
[RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。
<!-- body -->
@@ -74,7 +74,7 @@ some general rules that can be applied are :
由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型，
还包含所有未来被创建的所有对象类型。
- 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供
[伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)
[伪装权限](/zh-cn/docs/reference/access-authn-authz/authentication/#user-impersonation)
可以避免意外修改集群资源。
- 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查，
始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding`
@@ -102,9 +102,9 @@ In cases where a workload requires powerful permissions, consider the following
- 限制运行此类 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)确保
考虑使用[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)、
[节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或
[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保
Pod 不会与不可信或不太受信任的 Pod 一起运行。
特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。
<!--
@@ -133,7 +133,7 @@ Kubernetes 默认提供访问权限并非是每个集群都需要的。
- 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其删除，
因为这会给所有能够访问 API 服务器的人以网络级别的权限。
- 通过设置 `automountServiceAccountToken: false` 来避免服务账号令牌的默认自动挂载，
有关更多详细信息，请参阅[使用默认服务账号令牌](/zh/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。
有关更多详细信息，请参阅[使用默认服务账号令牌](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。
此参数可覆盖 Pod 服务账号设置，而需要服务账号令牌的工作负载仍可以挂载。
<!--
@@ -192,9 +192,9 @@ be able to gain access to the underlying node unless restrictions based on the K
-->
### 工作负载的创建 {#workload-creation}
能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)）
能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)）
能够访问下层的节点，除非基于 Kubernetes 的
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。
[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)做限制。
<!--
Users who can run privileged Pods can use that access to gain node access and potentially to
@@ -208,7 +208,7 @@ or other (third party) mechanisms to implement that enforcement.
并可能进一步提升他们的特权。如果你不完全信任某用户或其他主体，
不相信他们能够创建比较安全且相互隔离的 Pod，你应该强制实施 **Baseline**
或 **Restricted** Pod 安全标准。
你可以使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
你可以使用 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
<!--
You can also use the deprecated [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) mechanism
@@ -264,7 +264,7 @@ 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)
[RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
中所述，拥有此权限的用户可以有效地提升他们的权限。
<!--
@@ -352,4 +352,4 @@ to limit the quantity of objects which can be created.
产生拒绝服务状况，如 [Kubernetes 使用的 etcd 容易受到 OOM 攻击](https://github.com/kubernetes/kubernetes/issues/107325)中的讨论。
允许太不受信任或者不受信任的用户对系统进行有限的访问在多租户集群中是特别重要的。
缓解此问题的一种选择是使用[资源配额](/zh/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。
缓解此问题的一种选择是使用[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。
content/zh-cn/docs/concepts/security/windows-security.md
+2 -2
View File
@@ -56,7 +56,7 @@ 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)
可以为 Windows Pod 或容器指定 [RunAsUsername](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername)
以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh-cn/docs/concepts/security/pod-security-policy/#users-and-groups)。
<!--
@@ -86,7 +86,7 @@ Local users can be added to container images during the container build process.
<!--
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/)作为
Windows 容器还可以通过使用[组管理的服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)作为
Active Directory 身份运行。
<!--