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 之间的策略类型