From 7f4281ebb3f17d87f3d1d05d982f4f1b748d81a2 Mon Sep 17 00:00:00 2001 From: Rui Chen Date: Sun, 30 May 2021 12:27:23 -0400 Subject: [PATCH] zh: resync concepts/security files zh: resync content/zh/docs/concepts/security/controlling-access zh: resync content/zh/docs/concepts/security/pod-security-standards sync zh translation Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng --- .../concepts/security/controlling-access.md | 62 +++++++-------- .../security/pod-security-standards.md | 78 ++++++++++++------- 2 files changed, 83 insertions(+), 57 deletions(-) diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh/docs/concepts/security/controlling-access.md index d17e6744bb..b45dee64dd 100644 --- a/content/zh/docs/concepts/security/controlling-access.md +++ b/content/zh/docs/concepts/security/controlling-access.md @@ -2,7 +2,7 @@ title: Kubernetes API 访问控制 content_type: concept --- - - 本页面概述了对 Kubernetes API 的访问控制。 - ## 传输安全 {#transport-security} - ## 认证 {#authentication} - 如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 反之，该用户被认证为特定的 `username`，并且该用户名可用于后续步骤以在其决策中使用。 @@ -108,7 +108,7 @@ users in its API. ## 鉴权 {#authorization} - 如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 `projectCaribou` 名称空间中的对象。 @@ -153,27 +153,27 @@ If Bob makes the following request, the request is authorized because he is allo } } ``` - 如果 Bob 在 `projectCaribou` 名字空间中请求写（`create` 或 `update`）对象，其鉴权请求将被拒绝。 如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取（`get`）对象，其鉴权也会被拒绝。 -Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 +Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 使用 REST 格式很重要，因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。 - Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 @@ -187,7 +187,7 @@ Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhoo ## 准入控制 {#admission-control} - ## API 服务器端口和 IP {#api-server-ports-and-ips} - 前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务： @@ -250,7 +250,7 @@ By default the Kubernetes API server serves HTTP on 2 ports: - default IP is localhost, change with `--insecure-bind-address` flag. - request **bypasses** authentication and authorization modules. - request handled by admission control module(s). - - protected by need to have host access + - protected by need to have host access 2. “Secure port”: @@ -281,11 +281,11 @@ By default the Kubernetes API server serves HTTP on 2 ports: - 请求须经身份认证和鉴权组件处理 - 请求须经准入控制模块处理 - 身份认证和鉴权模块运行 - + ## {{% heading "whatsnext" %}} - @@ -60,7 +60,7 @@ should range from highly restricted to highly flexible: - **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略 允许已知的特权提升。 -- **_Baseline/Default_** - 限制性最弱的策略，禁止已知的策略提升。 +- **_Baseline_** - 限制性最弱的策略，禁止已知的策略提升。 允许使用默认的（规定最少）Pod 配置。 - **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。 @@ -90,15 +90,15 @@ Privileged 框架可能意味着不应用任何约束而不是实施某策略实 与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言， Privileged 策略应该默认允许所有控制（即，禁止所有限制）。 -### Baseline/Default +### Baseline -Baseline/Default 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。 +Baseline 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。 此策略针对的是应用运维人员和非关键性应用的开发人员。 下面列举的控制应该被实施（禁止）： @@ -201,39 +201,66 @@ Baseline/Default 策略的目标是便于常见的容器化应用采用，同时 - - AppArmor （可选） + + AppArmor - 在受支持的宿主上，默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略，或将重载限定未所允许的 profile 集合。
+ 在被支持的主机上，默认使用 'runtime/default' AppArmor Profile。 + 基线策略应避免覆盖或者禁用默认策略，以及限制覆盖一些 profile 集合的权限。

限制的字段：
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']

允许的值： 'runtime/default'、未定义
- - SELinux （可选） + + SELinux - 应禁止设置定制的 SELinux 选项。
+ 设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。

限制的字段：
- spec.securityContext.seLinuxOptions
- spec.containers[*].securityContext.seLinuxOptions
- spec.initContainers[*].securityContext.seLinuxOptions
-
允许的值： undefined/nil
+ spec.securityContext.seLinuxOptions.type
+ spec.containers[*].securityContext.seLinuxOptions.type
+ spec.initContainers[*].securityContext.seLinuxOptions.type
+
允许的值：
+ 未定义/空
+ container_t
+ container_init_t
+ container_kvm_t
+
被限制的字段：
+ spec.securityContext.seLinuxOptions.user
+ spec.containers[*].securityContext.seLinuxOptions.user
+ spec.initContainers[*].securityContext.seLinuxOptions.user
+ spec.securityContext.seLinuxOptions.role
+ spec.containers[*].securityContext.seLinuxOptions.role
+ spec.initContainers[*].securityContext.seLinuxOptions.role
+
允许的值： 未定义或空
@@ -306,8 +333,8 @@ Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作 策略（Policy） - - Default 策略的所有要求。 + + 基线策略的所有要求。 @@ -425,11 +452,11 @@ of individual policies are not defined here. ## 常见问题 {#faq} -### 为什么策略类型定义在 Privileged 和 Default 之间 +### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型