Skip to content

Commit 7f4281e

Browse files
chenrui333tengqm
andcommitted
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 <[email protected]> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <[email protected]> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <[email protected]> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <[email protected]> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <[email protected]> Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng <[email protected]>
1 parent 57cb82e commit 7f4281e

File tree

2 files changed

+83
-57
lines changed

2 files changed

+83
-57
lines changed

content/zh/docs/concepts/security/controlling-access.md

Lines changed: 31 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Kubernetes API 访问控制
33
content_type: concept
44
---
5-
<!--
5+
<!--
66
---
77
reviewers:
88
- erictune
@@ -14,13 +14,13 @@ content_type: concept
1414

1515
<!-- overview -->
1616

17-
<!--
17+
<!--
1818
This page provides an overview of controlling access to the Kubernetes API.
1919
-->
2020
本页面概述了对 Kubernetes API 的访问控制。
2121

2222
<!-- body -->
23-
<!--
23+
<!--
2424
Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`,
2525
client libraries, or by making REST requests. Both human users and
2626
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
@@ -37,7 +37,7 @@ following diagram:
3737
<!-- ## Transport security -->
3838
## 传输安全 {#transport-security}
3939

40-
<!--
40+
<!--
4141
In a typical Kubernetes cluster, the API serves on port 443, protected by TLS.
4242
The API server presents a certificate. This certificate may be signed using
4343
a private certificate authority (CA), or based on a public key infrastructure linked
@@ -47,9 +47,9 @@ to a generally recognized CA.
4747
API 服务器出示证书。
4848
该证书可以使用私有证书颁发机构(CA)签名,也可以基于链接到公认的 CA 的公钥基础架构签名。
4949

50-
<!--
50+
<!--
5151
If your cluster uses a private certificate authority, you need a copy of that CA
52-
certifcate configured into your `~/.kube/config` on the client, so that you can
52+
certificate configured into your `~/.kube/config` on the client, so that you can
5353
trust the connection and be confident it was not intercepted.
5454
5555
Your client can present a TLS client certificate at this stage.
@@ -62,7 +62,7 @@ Your client can present a TLS client certificate at this stage.
6262
<!-- ## Authentication -->
6363
## 认证 {#authentication}
6464

65-
<!--
65+
<!--
6666
Once TLS is established, the HTTP request moves to the Authentication step.
6767
This is shown as step **1** in the diagram.
6868
The cluster creation script or cluster admin configures the API server to run
@@ -74,9 +74,9 @@ Authenticators are described in more detail in
7474
集群创建脚本或者集群管理员配置 API 服务器,使之运行一个或多个身份认证组件。
7575
身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
7676

77-
<!--
77+
<!--
7878
The input to the authentication step is the entire HTTP request; however, it typically
79-
just examines the headers and/or client certificate.
79+
examines the headers and/or client certificate.
8080
8181
Authentication modules include client certificates, password, and plain tokens,
8282
bootstrap tokens, and JSON Web Tokens (used for service accounts).
@@ -90,7 +90,7 @@ until one of them succeeds.
9090

9191
可以指定多个认证模块,在这种情况下,服务器依次尝试每个验证模块,直到其中一个成功。
9292

93-
<!--
93+
<!--
9494
If the request cannot be authenticated, it is rejected with HTTP status code 401.
9595
Otherwise, the user is authenticated as a specific `username`, and the user name
9696
is available to subsequent steps to use in their decisions. Some authenticators
@@ -99,7 +99,7 @@ do not.
9999
100100
While Kubernetes uses usernames for access control decisions and in request logging,
101101
it does not have a `User` object nor does it store usernames or other information about
102-
users in its API.
102+
users in its API.
103103
-->
104104
如果请求认证不通过,服务器将以 HTTP 状态码 401 拒绝该请求。
105105
反之,该用户被认证为特定的 `username`,并且该用户名可用于后续步骤以在其决策中使用。
@@ -108,7 +108,7 @@ users in its API.
108108
<!-- ## Authorization -->
109109
## 鉴权 {#authorization}
110110

111-
<!--
111+
<!--
112112
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
113113
114114
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
@@ -134,7 +134,7 @@ For example, if Bob has the policy below, then he can read pods only in the name
134134
}
135135
}
136136
```
137-
<!--
137+
<!--
138138
If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace:
139139
-->
140140
如果 Bob 执行以下请求,那么请求会被鉴权,因为允许他读取 `projectCaribou` 名称空间中的对象。
@@ -153,27 +153,27 @@ If Bob makes the following request, the request is authorized because he is allo
153153
}
154154
}
155155
```
156-
<!--
157-
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied.
156+
<!--
157+
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied.
158158
If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
159159
160-
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems.
160+
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems.
161161
It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
162162
-->
163163
如果 Bob 在 `projectCaribou` 名字空间中请求写(`create``update`)对象,其鉴权请求将被拒绝。
164164
如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取(`get`)对象,其鉴权也会被拒绝。
165165

166-
Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
166+
Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
167167
使用 REST 格式很重要,因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。
168168

169-
<!--
170-
Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.
171-
When an administrator creates a cluster, they configure the authorization modules that should be used in the API server.
172-
If more than one authorization modules are configured, Kubernetes checks each module,
173-
and if any module authorizes the request, then the request can proceed.
169+
<!--
170+
Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.
171+
When an administrator creates a cluster, they configure the authorization modules that should be used in the API server.
172+
If more than one authorization modules are configured, Kubernetes checks each module,
173+
and if any module authorizes the request, then the request can proceed.
174174
If all of the modules deny the request, then the request is denied (HTTP status code 403).
175175
176-
To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules,
176+
To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules,
177177
see [Authorization](/docs/reference/access-authn-authz/authorization/).
178178
-->
179179
Kubernetes 支持多种鉴权模块,例如 ABAC 模式、RBAC 模式和 Webhook 模式等。
@@ -187,7 +187,7 @@ Kubernetes 支持多种鉴权模块,例如 ABAC 模式、RBAC 模式和 Webhoo
187187
<!-- ## Admission control -->
188188
## 准入控制 {#admission-control}
189189

190-
<!--
190+
<!--
191191
Admission Control modules are software modules that can modify or reject requests.
192192
In addition to the attributes available to Authorization modules, Admission
193193
Control modules can access the contents of the object that is being created or modified.
@@ -203,7 +203,7 @@ When multiple admission controllers are configured, they are called in order.
203203
准入控制器不会对仅读取对象的请求起作用。
204204
有多个准入控制器被配置时,服务器将依次调用它们。
205205

206-
<!--
206+
<!--
207207
This is shown as step **3** in the diagram.
208208
209209
Unlike Authentication and Authorization modules, if any admission controller module
@@ -230,11 +230,11 @@ for the corresponding API object, and then written to the object store (shown as
230230
<!-- ## API server ports and IPs -->
231231
## API 服务器端口和 IP {#api-server-ports-and-ips}
232232

233-
<!--
233+
<!--
234234
The previous discussion applies to requests sent to the secure port of the API server
235235
(the typical case). The API server can actually serve on 2 ports:
236236
237-
By default the Kubernetes API server serves HTTP on 2 ports:
237+
By default, the Kubernetes API server serves HTTP on 2 ports:
238238
-->
239239
前面的讨论适用于发送到 API 服务器的安全端口的请求(典型情况)。 API 服务器实际上可以在 2 个端口上提供服务:
240240

@@ -250,7 +250,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:
250250
- default IP is localhost, change with `--insecure-bind-address` flag.
251251
- request **bypasses** authentication and authorization modules.
252252
- request handled by admission control module(s).
253-
- protected by need to have host access
253+
- protected by need to have host access
254254
255255
2. “Secure port”:
256256
@@ -281,11 +281,11 @@ By default the Kubernetes API server serves HTTP on 2 ports:
281281
- 请求须经身份认证和鉴权组件处理
282282
- 请求须经准入控制模块处理
283283
- 身份认证和鉴权模块运行
284-
284+
285285

286286
## {{% heading "whatsnext" %}}
287287

288-
<!--
288+
<!--
289289
Read more documentation on authentication, authorization and API access control:
290290
291291
- [Authenticating](/docs/reference/access-authn-authz/authentication/)
@@ -330,4 +330,4 @@ You can learn about:
330330
你可以了解
331331
- Pod 如何使用
332332
[Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
333-
获取 API 凭证.
333+
获取 API 凭证.

content/zh/docs/concepts/security/pod-security-standards.md

Lines changed: 52 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ should range from highly restricted to highly flexible:
4949
5050
- **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
5151
policy allows for known privilege escalations.
52-
- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
52+
- **_Baseline_** - Minimally restrictive policy while preventing known privilege
5353
escalations. Allows the default (minimally specified) Pod configuration.
5454
- **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
5555
-->
@@ -60,7 +60,7 @@ should range from highly restricted to highly flexible:
6060

6161
- **_Privileged_** - 不受限制的策略,提供最大可能范围的权限许可。这些策略
6262
允许已知的特权提升。
63-
- **_Baseline/Default_** - 限制性最弱的策略,禁止已知的策略提升。
63+
- **_Baseline_** - 限制性最弱的策略,禁止已知的策略提升。
6464
允许使用默认的(规定最少)Pod 配置。
6565
- **_Restricted_** - 限制性非常强的策略,遵循当前的保护 Pod 的最佳实践。
6666

@@ -90,15 +90,15 @@ Privileged 框架可能意味着不应用任何约束而不是实施某策略实
9090
与此不同,对于默认拒绝(Deny-by-default)实施机制(如 Pod 安全策略)而言,
9191
Privileged 策略应该默认允许所有控制(即,禁止所有限制)。
9292

93-
### Baseline/Default
93+
### Baseline
9494

9595
<!--
96-
The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
96+
The Baseline policy is aimed at ease of adoption for common containerized workloads while
9797
preventing known privilege escalations. This policy is targeted at application operators and
9898
developers of non-critical applications. The following listed controls should be
9999
enforced/disallowed:
100100
-->
101-
Baseline/Default 策略的目标是便于常见的容器化应用采用,同时禁止已知的特权提升。
101+
Baseline 策略的目标是便于常见的容器化应用采用,同时禁止已知的特权提升。
102102
此策略针对的是应用运维人员和非关键性应用的开发人员。
103103
下面列举的控制应该被实施(禁止):
104104

@@ -201,39 +201,66 @@ Baseline/Default 策略的目标是便于常见的容器化应用采用,同时
201201
</td>
202202
</tr>
203203
<tr>
204-
<!-- td>AppArmor <em>(optional)</em></td -->
205-
<td>AppArmor <em>(可选)</em></td>
204+
<!-- <td>AppArmor <em>(optional)</em></td> -->
205+
<td>AppArmor</td>
206206
<!-- td>
207-
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
207+
On supported hosts, the 'runtime/default' AppArmor profile is applied by default.
208+
The baseline policy should prevent overriding or disabling the default AppArmor
209+
profile, or restrict overrides to an allowed set of profiles.<br>
208210
<br><b>限制的字段:</b><br>
209211
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
210212
<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
211213
</td -->
212214
<td>
213-
在受支持的宿主上,默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略,或将重载限定未所允许的 profile 集合。<br>
215+
在被支持的主机上,默认使用 'runtime/default' AppArmor Profile。
216+
基线策略应避免覆盖或者禁用默认策略,以及限制覆盖一些 profile 集合的权限。<br>
214217
<br><b>限制的字段:</b><br>
215218
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
216219
<br><b>允许的值:</b> 'runtime/default'、未定义<br>
217220
</td>
218221
</tr>
219222
<tr>
220-
<!-- td>SELinux <em>(optional)</em></td -->
221-
<td>SELinux <em>(可选)</em></td>
223+
<!-- <td>SELinux</td> -->
224+
<td>SELinux</td>
222225
<!-- td>
223-
Setting custom SELinux options should be disallowed.<br>
226+
Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.<br>
224227
<br><b>Restricted Fields:</b><br>
225-
spec.securityContext.seLinuxOptions<br>
226-
spec.containers[*].securityContext.seLinuxOptions<br>
227-
spec.initContainers[*].securityContext.seLinuxOptions<br>
228-
<br><b>Allowed Values:</b> undefined/nil<br>
228+
spec.securityContext.seLinuxOptions.type<br>
229+
spec.containers[*].securityContext.seLinuxOptions.type<br>
230+
spec.initContainers[*].securityContext.seLinuxOptions.type<br>
231+
<br><b>Allowed Values:</b><br>
232+
undefined/empty<br>
233+
container_t<br>
234+
container_init_t<br>
235+
container_kvm_t<br>
236+
<br><b>Restricted Fields:</b><br>
237+
spec.securityContext.seLinuxOptions.user<br>
238+
spec.containers[*].securityContext.seLinuxOptions.user<br>
239+
spec.initContainers[*].securityContext.seLinuxOptions.user<br>
240+
spec.securityContext.seLinuxOptions.role<br>
241+
spec.containers[*].securityContext.seLinuxOptions.role<br>
242+
spec.initContainers[*].securityContext.seLinuxOptions.role<br>
243+
<br><b>Allowed Values:</b> undefined/empty<br>
229244
</td -->
230245
<td>
231-
应禁止设置定制的 SELinux 选项。<br>
246+
设置 SELinux 类型的操作是被限制的,设置自定义的 SELinux 用户或角色选项是被禁止的。<br>
232247
<br><b>限制的字段:</b><br>
233-
spec.securityContext.seLinuxOptions<br>
234-
spec.containers[*].securityContext.seLinuxOptions<br>
235-
spec.initContainers[*].securityContext.seLinuxOptions<br>
236-
<br><b>允许的值:</b> undefined/nil<br>
248+
spec.securityContext.seLinuxOptions.type<br>
249+
spec.containers[*].securityContext.seLinuxOptions.type<br>
250+
spec.initContainers[*].securityContext.seLinuxOptions.type<br>
251+
<br><b>允许的值:</b><br>
252+
未定义/空<br>
253+
container_t<br>
254+
container_init_t<br>
255+
container_kvm_t<br>
256+
<br><b>被限制的字段:</b><br>
257+
spec.securityContext.seLinuxOptions.user<br>
258+
spec.containers[*].securityContext.seLinuxOptions.user<br>
259+
spec.initContainers[*].securityContext.seLinuxOptions.user<br>
260+
spec.securityContext.seLinuxOptions.role<br>
261+
spec.containers[*].securityContext.seLinuxOptions.role<br>
262+
spec.initContainers[*].securityContext.seLinuxOptions.role<br>
263+
<br><b>允许的值:</b> 未定义或空<br>
237264
</td>
238265
</tr>
239266
<tr>
@@ -306,8 +333,8 @@ Restricted 策略旨在实施当前保护 Pod 的最佳实践,尽管这样作
306333
<td><strong>策略(Policy)</strong></td>
307334
</tr>
308335
<tr>
309-
<!-- td colspan="2"><em>Everything from the default profile.</em></td -->
310-
<td colspan="2"><em>Default 策略的所有要求。</em></td>
336+
<!-- <td colspan="2"><em>Everything from the baseline profile.</em></td> -->
337+
<td colspan="2"><em>基线策略的所有要求。</em></td>
311338
</tr>
312339
<tr>
313340
<!-- td>Volume Types</td -->
@@ -425,11 +452,11 @@ of individual policies are not defined here.
425452
<!--
426453
## FAQ
427454
428-
### Why isn't there a profile between privileged and default?
455+
### Why isn't there a profile between privileged and baseline?
429456
-->
430457
## 常见问题 {#faq}
431458

432-
### 为什么策略类型定义在 Privileged 和 Default 之间
459+
### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型
433460

434461
<!--
435462
The three profiles defined here have a clear linear progression from most secure (restricted) to least
@@ -517,4 +544,3 @@ sandboxing. As such, no single recommended policy is recommended for all sandbox
517544

518545
此外,沙箱化负载的保护高度依赖于沙箱化的实现方法。
519546
因此,现在还没有针对所有沙箱化负载的建议策略。
520-

0 commit comments

Comments
 (0)