From b1ece1019d6ffe56e81b036169c0616e11f95efe Mon Sep 17 00:00:00 2001 From: Michael Date: Wed, 24 Aug 2022 18:50:40 +0800 Subject: [PATCH] [zh-cn] resync1.25 pod-security-admission.md --- .../security/pod-security-admission.md | 104 ++++-------------- 1 file changed, 20 insertions(+), 84 deletions(-) diff --git a/content/zh-cn/docs/concepts/security/pod-security-admission.md b/content/zh-cn/docs/concepts/security/pod-security-admission.md index 9a3d6533d8..a36b9ddb8e 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/docs/concepts/security/pod-security-admission.md @@ -5,7 +5,6 @@ description: > content_type: concept weight: 20 -min-kubernetes-server-version: v1.22 --- -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} -作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_ -{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}， -作为 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/) -特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 -{{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。 - -{{< note >}} - -PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中 -[移除](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)。 -{{< /note >}} - - - -## {{% heading "prerequisites" %}} - - -要使用此机制，你的集群必须强制执行 Pod 安全准入。 +Kubernetes 提供了一个内置的 **Pod Security** +{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}来执行 Pod 安全标准 +（Pod Security Standard）。 +创建 Pod 时在{{< glossary_tooltip text="名字空间" term_id="namespace" >}}级别应用这些 Pod 安全限制。 -### 内置 Pod 安全准入强制执行 +### 内置 Pod 安全准入强制执行 {#built-in-pod-security-admission-enforcement} -在 Kubernetes v1.23 中，`PodSecurity` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， -默认被启用。 本页面是 Kubernetes v{{< skew currentVersion >}} 文档的一部分。 -如果你运行的是其它版本的 Kubernetes，请查阅该版本的文档。 - - -### 替代方案：安装 `PodSecurity` 准入 Webhook {#webhook} - -`PodSecurity` 准入逻辑也可用作[验证性准入 Webhook](https://git.k8s.io/pod-security-admission/webhook)。 -该实现也是 Beta 版本。 -对于无法启用内置 `PodSecurity` 准入插件的环境，你可以改为通过验证准入 Webhook 启用该逻辑。 - - -在 [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 >}} - -所生成的证书合法期限为 2 年。在证书过期之前， -需要重新生成证书或者去掉 Webhook 以使用内置的准入插件。 -{{< /note >}} +如果你运行的是其他版本的 Kubernetes，请查阅该版本的文档。 @@ -131,9 +67,10 @@ 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-cn/docs/tasks/configure-pod-container/security-context/) -有一定的要求，并且依据 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards) -所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。 +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-cn/docs/concepts/security/pod-security-standards/)页面。 @@ -153,8 +90,8 @@ takes if a potential violation is detected: Pod 安全性准入控制模式。 Kubernetes 定义了一组{{< glossary_tooltip term_id="label" text="标签" >}}， 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 -你所选择的标签定义了检测到潜在违例时，{{< glossary_tooltip text="控制面" term_id="control-plane" >}} -要采取什么样的动作。 +你所选择的标签定义了检测到潜在违例时， +{{< glossary_tooltip text="控制面" term_id="control-plane" >}}要采取什么样的动作。 -``` +```yaml # 模式的级别标签用来标示对应模式所应用的策略级别 # # MODE 必须是 `enforce`、`audit` 或 `warn` 之一 @@ -233,7 +170,7 @@ Pod 通常是通过创建 {{< glossary_tooltip term_id="deployment" >}} 或 来间接创建的。工作负载对象为工作负载资源定义一个 **Pod 模板** 和一个对应的负责基于该模板来创建 Pod 的{{< glossary_tooltip term_id="controller" text="控制器" >}}。 为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。 -不过，`enforce` 模式并 **不** 应用到工作负载资源，仅应用到所生成的 Pod 对象上。 +不过，`enforce` 模式并 **不** 应用到工作负载资源，仅应用到所生成的 Pod 对象上。