Skip to content

Commit 95e6077

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #46384 from lbzss/authentication-machanisms
[zh-cn] Localize docs/concepts/security/hardening-guide/authenticatio…
2 parents 4b21f3e + e098095 commit 95e6077

File tree

1 file changed

+332
-0
lines changed

1 file changed

+332
-0
lines changed

‎content/zh-cn/docs/concepts/security/hardening-guide/authentication-mechanisms.md

Lines changed: 332 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,332 @@
1+
---
2+
title: 加固指南 - 身份认证机制
3+
description: >
4+
有关 Kubernetes 中的认证选项及其安全属性的信息。
5+
content_type: concept
6+
weight: 90
7+
---
8+
<!--
9+
---
10+
title: Hardening Guide - Authentication Mechanisms
11+
description: >
12+
Information on authentication options in Kubernetes and their security properties.
13+
content_type: concept
14+
weight: 90
15+
---
16+
-->
17+
18+
<!-- overview -->
19+
20+
<!--
21+
Selecting the appropriate authentication mechanism(s) is a crucial aspect of securing your cluster.
22+
Kubernetes provides several built-in mechanisms, each with its own strengths and weaknesses that
23+
should be carefully considered when choosing the best authentication mechanism for your cluster.
24+
-->
25+
选择合适的身份认证机制是确保集群安全的一个重要方面。
26+
Kubernetes 提供了多种内置机制，
27+
当为你的集群选择最好的身份认证机制时需要谨慎考虑每种机制的优缺点。
28+
29+
<!--
30+
In general, it is recommended to enable as few authentication mechanisms as possible to simplify
31+
user management and prevent cases where users retain access to a cluster that is no longer required.
32+
-->
33+
通常情况下，建议启用尽可能少的身份认证机制，
34+
以简化用户管理，避免用户仍保有对其不再需要的集群的访问权限的情况。
35+
36+
<!--
37+
It is important to note that Kubernetes does not have an in-built user database within the cluster.
38+
Instead, it takes user information from the configured authentication system and uses that to make
39+
authorization decisions. Therefore, to audit user access, you need to review credentials from every
40+
configured authentication source.
41+
-->
42+
值得注意的是 Kubernetes 集群中并没有内置的用户数据库。
43+
相反，它从已配置的身份认证系统中获取用户信息并依之做出鉴权决策。
44+
因此，要审计用户访问，你需要检视来自每个已配置身份认证数据源的凭据。
45+
46+
<!--
47+
For production clusters with multiple users directly accessing the Kubernetes API, it is
48+
recommended to use external authentication sources such as OIDC. The internal authentication
49+
mechanisms, such as client certificates and service account tokens, described below, are not
50+
suitable for this use-case.
51+
-->
52+
对于有多个用户直接访问 Kubernetes API 的生产集群来说，
53+
建议使用外部身份认证数据源，例如：OIDC。
54+
下文提到的客户端证书和服务账号令牌等内部身份认证机制则不适用这种情况。
55+
56+
<!-- body -->
57+
58+
<!--
59+
## X.509 client certificate authentication {#x509-client-certificate-authentication}
60+
-->
61+
## X.509 客户端证书身份认证 {#x509-client-certificate-authentication}
62+
63+
<!--
64+
Kubernetes leverages [X.509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certificates)
65+
authentication for system components, such as when the Kubelet authenticates to the API Server.
66+
While this mechanism can also be used for user authentication, it might not be suitable for
67+
production use due to several restrictions:
68+
-->
69+
Kubernetes 采用 [X.509 客户端证书](/zh-cn/docs/reference/access-authn-authz/authentication/#x509-client-certificates)
70+
对系统组件进行身份认证，
71+
例如 Kubelet 对 API 服务器进行身份认证时。
72+
虽然这种机制也可以用于用户身份认证，但由于一些限制它可能不太适合在生产中使用：
73+
74+
75+
<!--
76+
- Client certificates cannot be individually revoked. Once compromised, a certificate can be used
77+
by an attacker until it expires. To mitigate this risk, it is recommended to configure short
78+
lifetimes for user authentication credentials created using client certificates.
79+
-->
80+
- 客户端证书无法独立撤销。
81+
证书一旦被泄露，攻击者就可以使用它，直到证书过期。
82+
为了降低这种风险，建议为使用客户端证书创建的用户身份认证凭据配置较短的有效期。
83+
<!--
84+
- If a certificate needs to be invalidated, the certificate authority must be re-keyed, which
85+
can introduce availability risks to the cluster.
86+
-->
87+
- 如果证书需要被作废，必须重新为证书机构设置密钥，但这样做可能给集群带来可用性风险。
88+
<!--
89+
- There is no permanent record of client certificates created in the cluster. Therefore, all
90+
issued certificates must be recorded if you need to keep track of them.
91+
-->
92+
- 在集群中创建的客户端证书不会被永久记录。
93+
因此，如果你要跟踪所有已签发的证书，就必须将它们记录下来。
94+
<!--
95+
- Private keys used for client certificate authentication cannot be password-protected. Anyone
96+
who can read the file containing the key will be able to make use of it.
97+
-->
98+
- 用于对客户端证书进行身份认证的私钥不可以启用密码保护。
99+
任何可以读取包含密钥文件的人都可以利用该密钥。
100+
<!--
101+
- Using client certificate authentication requires a direct connection from the client to the
102+
API server with no intervening TLS termination points, which can complicate network architectures.
103+
-->
104+
- 使用客户端证书身份认证需要客户端直连 API 服务器而不允许中间存在 TLS 终止节点，
105+
这一约束可能会使网络架构变得复杂。
106+
<!--
107+
- Group data is embedded in the `O` value of the client certificate, which means the user's group
108+
memberships cannot be changed for the lifetime of the certificate.
109+
-->
110+
- 组数据包含在客户端证书的 `O` 值中，
111+
这意味着在证书有效期内无法更改用户的组成员身份。
112+
113+
<!--
114+
## Static token file {#static-token-file}、
115+
-->
116+
## 静态令牌文件 {#static-token-file}
117+
118+
<!--
119+
Although Kubernetes allows you to load credentials from a
120+
[static token file](/docs/reference/access-authn-authz/authentication/#static-token-file) located
121+
on the control plane node disks, this approach is not recommended for production servers due to
122+
several reasons:
123+
-->
124+
尽管 Kubernetes 允许你从控制平面节点的磁盘中加载
125+
[静态令牌文件](/zh-cn/docs/reference/access-authn-authz/authentication/#static-token-file)
126+
以获取凭据，但由于多种原因，在生产服务器上不建议采用这种方法：
127+
128+
<!--
129+
- Credentials are stored in clear text on control plane node disks, which can be a security risk.
130+
-->
131+
- 凭据以明文的方式存储在控制平面节点的磁盘中，这可能是一种安全风险。
132+
<!--
133+
- Changing any credential requires a restart of the API server process to take effect, which can
134+
impact availability.
135+
-->
136+
- 修改任何凭据都需要重启 API 服务进程使其生效，这会影响可用性。
137+
<!--
138+
- There is no mechanism available to allow users to rotate their credentials. To rotate a
139+
credential, a cluster administrator must modify the token on disk and distribute it to the users.
140+
-->
141+
- 没有现成的机制让用户轮换其凭据数据。
142+
要轮换凭据数据，集群管理员必须修改磁盘上的令牌并将其分发给用户。
143+
<!--
144+
- There is no lockout mechanism available to prevent brute-force attacks.
145+
-->
146+
- 没有合适的锁机制用以防止暴力破解攻击。
147+
148+
<!--
149+
## Bootstrap tokens {#bootstrap-tokens}
150+
-->
151+
## 启动引导令牌 {#bootstrap-tokens}
152+
153+
<!--
154+
[Bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) are used for joining
155+
nodes to clusters and are not recommended for user authentication due to several reasons:
156+
-->
157+
[启动引导令牌](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)用于节点加入集群，
158+
因为下列的一些原因，不建议用于用户身份认证：
159+
160+
<!--
161+
- They have hard-coded group memberships that are not suitable for general use, making them
162+
unsuitable for authentication purposes.
163+
-->
164+
- 启动引导令牌中包含有硬编码的组成员身份，不适合一般使用，
165+
因此不适用于身份认证目的。
166+
<!--
167+
- Manually generating bootstrap tokens can lead to weak tokens that can be guessed by an attacker,
168+
which can be a security risk.
169+
-->
170+
- 手动生成启动引导令牌有可能使较弱的令牌容易被攻击者猜到，
171+
有可能成为安全隐患。
172+
<!--
173+
- There is no lockout mechanism available to prevent brute-force attacks, making it easier for
174+
attackers to guess or crack the token.
175+
-->
176+
- 没有现成的加锁定机制用来防止暴力破解，
177+
这使得攻击者更容易猜测或破解令牌。
178+
179+
<!--
180+
## ServiceAccount secret tokens {#serviceaccount-secret-tokens}
181+
-->
182+
## 服务账号令牌 {#serviceaccount-secret-tokens}
183+
184+
<!--
185+
[Service account secrets](/docs/reference/access-authn-authz/service-accounts-admin/#manual-secret-management-for-serviceaccounts)
186+
are available as an option to allow workloads running in the cluster to authenticate to the
187+
API server. In Kubernetes < 1.23, these were the default option, however, they are being replaced
188+
with TokenRequest API tokens. While these secrets could be used for user authentication, they are
189+
generally unsuitable for a number of reasons:
190+
-->
191+
[服务账号令牌](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#manual-secret-management-for-serviceaccounts)
192+
在运行于集群中的工作负载向 API 服务器进行身份认证时是个可选项。
193+
在 Kubernetes < 1.23 的版本中，服务账号令牌是默认选项，但现在已经被 TokenRequest API 取代。
194+
尽管这些密钥可以用于用户身份认证，但由于多种原因，它们通常并不合适：
195+
196+
<!--
197+
- They cannot be set with an expiry and will remain valid until the associated service account is deleted.
198+
-->
199+
- 服务账号令牌无法设置有效期，在相关的服务账号被删除前一直有效。
200+
<!--
201+
- The authentication tokens are visible to any cluster user who can read secrets in the namespace
202+
that they are defined in.
203+
-->
204+
- 任何集群用户，只要能读取服务账号令牌定义所在的命名空间中的 Secret，就能看到身份认证令牌。
205+
<!--
206+
- Service accounts cannot be added to arbitrary groups complicating RBAC management where they are used.
207+
-->
208+
- 服务账号无法被添加到任意组中，这一限制使得使用服务账号的 RBAC 管理变得复杂。
209+
210+
<!--
211+
## TokenRequest API tokens {#tokenrequest-api-tokens}
212+
-->
213+
## TokenRequest API 令牌 {#tokenrequest-api-tokens}
214+
215+
<!--
216+
The TokenRequest API is a useful tool for generating short-lived credentials for service
217+
authentication to the API server or third-party systems. However, it is not generally recommended
218+
for user authentication as there is no revocation method available, and distributing credentials
219+
to users in a secure manner can be challenging.
220+
-->
221+
TokenRequest API 是一种可生成短期凭据的有用工具，所生成的凭据可
222+
用于对 API 服务器或第三方系统执行服务身份认证。
223+
然而，通常不建议将此机制用于用户身份认证，因为没有办法撤销这些令牌，
224+
而且，如何以安全的方式向用户分发凭据信息也是挑战。
225+
226+
<!--
227+
When using TokenRequest tokens for service authentication, it is recommended to implement a short
228+
lifespan to reduce the impact of compromised tokens.
229+
-->
230+
当使用 TokenRequest 令牌进行服务身份认证时，
231+
建议使用较短的有效期以减少被泄露令牌可能带来的影响。
232+
233+
<!--
234+
## OpenID Connect token authentication {#openid-connect-token-authentication}
235+
-->
236+
## OpenID Connect 令牌身份认证 {#openid-connect-token-authentication}
237+
238+
<!--
239+
Kubernetes supports integrating external authentication services with the Kubernetes API using
240+
[OpenID Connect (OIDC)](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens).
241+
There is a wide variety of software that can be used to integrate Kubernetes with an identity
242+
provider. However, when using OIDC authentication for Kubernetes, it is important to consider the
243+
following hardening measures:
244+
-->
245+
Kubernetes 支持使用 [OpenID Connect (OIDC)](/zh-cn/docs/reference/access-authn-authz/authentication/#openid-connect-tokens)
246+
将外部身份认证服务与 Kubernetes API 集成。
247+
有多种软件可用于将 Kubernetes 与认证服务组件集成。
248+
不过，当为 Kubernetes 使用 OIDC 身份认证时，
249+
必须考虑以下加固措施：
250+
251+
<!--
252+
- The software installed in the cluster to support OIDC authentication should be isolated from
253+
general workloads as it will run with high privileges.
254+
-->
255+
- 安装在集群中用于支持 OIDC 身份认证的软件应该与普通的工作负载隔离，
256+
因为它要以较高的特权来运行。
257+
<!--
258+
- Some Kubernetes managed services are limited in the OIDC providers that can be used.
259+
-->
260+
- 有些 Kubernetes 托管服务对可使用的 OIDC 服务组件有限制。
261+
<!--
262+
- As with TokenRequest tokens, OIDC tokens should have a short lifespan to reduce the impact of
263+
compromised tokens.
264+
-->
265+
- 与 TokenRequest 令牌一样，OIDC 令牌的有效期也应较短，以减少被泄露的令牌所带来的影响。
266+
267+
<!--
268+
## Webhook token authentication {#webhook-token-authentication}
269+
-->
270+
## Webhook 令牌身份认证 {#webhook-token-authentication}
271+
272+
<!--
273+
[Webhook token authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
274+
is another option for integrating external authentication providers into Kubernetes. This mechanism
275+
allows for an authentication service, either running inside the cluster or externally, to be
276+
contacted for an authentication decision over a webhook. It is important to note that the suitability
277+
of this mechanism will likely depend on the software used for the authentication service, and there
278+
are some Kubernetes-specific considerations to take into account.
279+
-->
280+
[Webhook 令牌身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
281+
是另一种集成外部身份认证服务组件到 Kubernetes 中的可选项。
282+
这种机制允许通过 Webhook 的方式连接集群内部或外部运行的身份认证服务，
283+
以做出身份认证决策。值得注意的是，
284+
这种机制的适用性可能更取决于身份认证服务所使用的软件，
285+
而且还需要考虑一些特定于 Kubernetes 的因素。
286+
287+
<!--
288+
To configure Webhook authentication, access to control plane server filesystems is required. This
289+
means that it will not be possible with Managed Kubernetes unless the provider specifically makes it
290+
available. Additionally, any software installed in the cluster to support this access should be
291+
isolated from general workloads, as it will run with high privileges.
292+
-->
293+
要配置 Webhook 身份认证的前提是需要提供控制平面服务器文件系统的访问权限。
294+
这意味着托管的 Kubernetes 无法实现这一点，除非供应商特别提供。
295+
此外，集群中安装的任何支持该访问的软件都应当与普通工作负载隔离，
296+
因为它需要以较高的特权来运行。
297+
298+
<!--
299+
## Authenticating proxy {#authenticating-proxy}
300+
-->
301+
## 身份认证代理 {#authenticating-proxy}
302+
303+
<!--
304+
Another option for integrating external authentication systems into Kubernetes is to use an
305+
[authenticating proxy](/docs/reference/access-authn-authz/authentication/#authenticating-proxy).
306+
With this mechanism, Kubernetes expects to receive requests from the proxy with specific header
307+
values set, indicating the username and group memberships to assign for authorization purposes.
308+
It is important to note that there are specific considerations to take into account when using
309+
this mechanism.
310+
-->
311+
将外部身份认证系统集成到 Kubernetes 的另一种方式是使用
312+
[身份认证代理](/zh-cn/docs/reference/access-authn-authz/authentication/#authenticating-proxy)。
313+
在这种机制下，Kubernetes 接收到来自代理的请求，这些请求会携带特定的标头，
314+
标明为鉴权目的所赋予的用户名和组成员身份。
315+
值得注意的是，在使用这种机制时有一些特定的注意事项。
316+
317+
<!--
318+
Firstly, securely configured TLS must be used between the proxy and Kubernetes API server to
319+
mitigate the risk of traffic interception or sniffing attacks. This ensures that the communication
320+
between the proxy and Kubernetes API server is secure.
321+
-->
322+
首先，在代理和 Kubernetes API 服务器间必须以安全的方式配置 TLS 连接，
323+
从而降低流量劫持或嗅探攻击的风险。
324+
TLS 连接可以确保代理和 Kubernetes API 服务器间的通信是安全的。
325+
326+
<!--
327+
Secondly, it is important to be aware that an attacker who is able to modify the headers of the
328+
request may be able to gain unauthorized access to Kubernetes resources. As such, it is important
329+
to ensure that the headers are properly secured and cannot be tampered with.
330+
-->
331+
其次，需要注意的是，能够修改表头的攻击者可能会在未经授权的情况下访问 Kubernetes 资源。
332+
因此，确保标头得到妥善保护并且不会被篡改非常重要。

0 commit comments

Comments
 (0)