Skip to content

Commit 56b562f

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #42716 from my-git9/secret34
[zh-cn] sync configuration/secret.md
2 parents 1b0e5f7 + 498d407 commit 56b562f

File tree

1 file changed

+120
-140
lines changed
  • content/zh-cn/docs/concepts/configuration

1 file changed

+120
-140
lines changed

‎content/zh-cn/docs/concepts/configuration/secret.md

Lines changed: 120 additions & 140 deletions
Original file line numberDiff line numberDiff line change
@@ -99,30 +99,116 @@ See [Information security for Secrets](#information-security-for-secrets) for mo
9999
<!--
100100
## Uses for Secrets
101101
102-
There are three main ways for a Pod to use a Secret:
103-
- As [files](#using-secrets-as-files-from-a-pod) in a
104-
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
105-
its containers.
106-
- As [container environment variable](#using-secrets-as-environment-variables).
107-
- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
102+
You can use Secrets for purposes such as the following:
103+
- [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data).
104+
- [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds).
105+
- [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/).
108106
109107
The Kubernetes control plane also uses Secrets; for example,
110108
[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to
111109
help automate node registration.
112110
-->
113111
## Secret 的使用 {#uses-for-secrets}
114112

115-
Pod 可以用三种方式之一来使用 Secret：
113+
你可以将 Secret 用于以下场景：
116114

117-
- 作为挂载到一个或多个容器上的{{< glossary_tooltip text="卷" term_id="volume" >}}
118-
中的[文件](#using-secrets-as-files-from-a-pod)。
119-
- 作为[容器的环境变量](#using-secrets-as-environment-variables)。
120-
- 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets)。
115+
- [设置容器的环境变量](/zh-cn/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data)。
116+
- [向 Pod 提供 SSH 密钥或密码等凭据](/zh-cn/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds)。
117+
- [允许 kubelet 从私有镜像仓库中拉取镜像](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry/)。
121118

122119
Kubernetes 控制面也使用 Secret；
123120
例如，[引导令牌 Secret](#bootstrap-token-secrets)
124121
是一种帮助自动化节点注册的机制。
125122

123+
<!--
124+
### Use case: dotfiles in a secret volume
125+
126+
You can make your data "hidden" by defining a key that begins with a dot.
127+
This key represents a dotfile or "hidden" file. For example, when the following secret
128+
is mounted into a volume, `secret-volume`, the volume will contain a single file,
129+
called `.secret-file`, and the `dotfile-test-container` will have this file
130+
present at the path `/etc/secret-volume/.secret-file`.
131+
-->
132+
### 使用场景：在 Secret 卷中带句点的文件 {#use-case-dotfiles-in-a-secret-volume}
133+
134+
通过定义以句点（`.`）开头的主键，你可以“隐藏”你的数据。
135+
这些主键代表的是以句点开头的文件或“隐藏”文件。
136+
例如，当以下 Secret 被挂载到 `secret-volume` 卷上时，该卷中会包含一个名为
137+
`.secret-file` 的文件，并且容器 `dotfile-test-container`
138+
中此文件位于路径 `/etc/secret-volume/.secret-file` 处。
139+
140+
{{< note >}}
141+
<!--
142+
Files beginning with dot characters are hidden from the output of `ls -l`;
143+
you must use `ls -la` to see them when listing directory contents.
144+
-->
145+
以句点开头的文件会在 `ls -l` 的输出中被隐藏起来；
146+
列举目录内容时你必须使用 `ls -la` 才能看到它们。
147+
{{< /note >}}
148+
149+
```yaml
150+
apiVersion: v1
151+
kind: Secret
152+
metadata:
153+
name: dotfile-secret
154+
data:
155+
.secret-file: dmFsdWUtMg0KDQo=
156+
---
157+
apiVersion: v1
158+
kind: Pod
159+
metadata:
160+
name: secret-dotfiles-pod
161+
spec:
162+
volumes:
163+
- name: secret-volume
164+
secret:
165+
secretName: dotfile-secret
166+
containers:
167+
- name: dotfile-test-container
168+
image: registry.k8s.io/busybox
169+
command:
170+
- ls
171+
- "-l"
172+
- "/etc/secret-volume"
173+
volumeMounts:
174+
- name: secret-volume
175+
readOnly: true
176+
mountPath: "/etc/secret-volume"
177+
```
178+
179+
<!--
180+
### Use case: Secret visible to one container in a Pod
181+
182+
Consider a program that needs to handle HTTP requests, do some complex business
183+
logic, and then sign some messages with an HMAC. Because it has complex
184+
application logic, there might be an unnoticed remote file reading exploit in
185+
the server, which could expose the private key to an attacker.
186+
-->
187+
### 使用场景：仅对 Pod 中一个容器可见的 Secret {#use-case-secret-visible-to-one-container-in-a-pod}
188+
189+
考虑一个需要处理 HTTP 请求，执行某些复杂的业务逻辑，之后使用 HMAC
190+
来对某些消息进行签名的程序。因为这一程序的应用逻辑很复杂，
191+
其中可能包含未被注意到的远程服务器文件读取漏洞，
192+
这种漏洞可能会把私钥暴露给攻击者。
193+
194+
<!--
195+
This could be divided into two processes in two containers: a frontend container
196+
which handles user interaction and business logic, but which cannot see the
197+
private key; and a signer container that can see the private key, and responds
198+
to simple signing requests from the frontend (for example, over localhost networking).
199+
-->
200+
这一程序可以分隔成两个容器中的两个进程：前端容器要处理用户交互和业务逻辑，
201+
但无法看到私钥；签名容器可以看到私钥，并对来自前端的简单签名请求作出响应
202+
（例如，通过本地主机网络）。
203+
204+
<!--
205+
With this partitioned approach, an attacker now has to trick the application
206+
server into doing something rather arbitrary, which may be harder than getting
207+
it to read a file.
208+
-->
209+
采用这种划分的方法，攻击者现在必须欺骗应用服务器来做一些其他操作，
210+
而这些操作可能要比读取一个文件要复杂很多。
211+
126212
<!--
127213
### Alternatives to Secrets
128214
@@ -423,12 +509,13 @@ for information on referencing service account credentials from within Pods.
423509
<!--
424510
### Docker config Secrets
425511

426-
You can use one of the following `type` values to create a Secret to
427-
store the credentials for accessing a container image registry:
512+
If you are creating a Secret to store credentials for accessing a container image registry,
513+
you must use one of the following `type` values for that Secret:
428514
-->
429515
### Docker 配置 Secret {#docker-config-secrets}
430516

431-
你可以使用下面两种 `type` 值之一来创建 Secret，用以存放用于访问容器镜像仓库的凭据：
517+
如果你要创建 Secret 用来存放用于访问容器镜像仓库的凭据，则必须选用以下 `type`
518+
值之一来创建 Secret：
432519

433520
- `kubernetes.io/dockercfg`
434521
- `kubernetes.io/dockerconfigjson`
@@ -537,14 +624,19 @@ Docker configuration file):
537624
}
538625
```
539626

540-
{{< note >}}
627+
{{< caution >}}
541628
<!--
542629
The `auth` value there is base64 encoded; it is obscured but not secret.
543630
Anyone who can read that Secret can learn the registry access bearer token.
631+
632+
It is suggested to use [credential providers](/docs/tasks/administer-cluster/kubelet-credential-provider/) to dynamically and securely provide pull secrets on-demand.
544633
-->
545634
`auths` 值是 base64 编码的，其内容被屏蔽但未被加密。
546635
任何能够读取该 Secret 的人都可以了解镜像库的访问令牌。
547-
{{< /note >}}
636+
637+
建议使用[凭据提供程序](/zh-cn/docs/tasks/administer-cluster/kubelet-credential-provider/)来动态、
638+
安全地按需提供拉取 Secret。
639+
{{< /caution >}}
548640

549641
<!--
550642
### Basic authentication Secret
@@ -669,6 +761,8 @@ When using this type of Secret, the `tls.key` and the `tls.crt` key must be prov
669761
in the `data` (or `stringData`) field of the Secret configuration, although the API
670762
server doesn't actually validate the values for each key.
671763

764+
As an alternative to using `stringData`, you can use the `data` field to provide the base64 encoded certificate and private key. Refer to [Constraints on Secret names and data](#restriction-names-data) for more on this.
765+
672766
The following YAML contains an example config for a TLS Secret:
673767
-->
674768
### TLS Secret
@@ -680,6 +774,9 @@ TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-n
680774
当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含
681775
`tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。
682776

777+
作为使用 `stringData` 的替代方法，你可以使用 `data` 字段来指定 base64 编码的证书和私钥。
778+
有关详细信息，请参阅 [Secret 名称和数据的限制](#restriction-names-data)。
779+
683780
下面的 YAML 包含一个 TLS Secret 的配置示例：
684781

685782
```yaml
@@ -688,11 +785,13 @@ kind: Secret
688785
metadata:
689786
name: secret-tls
690787
type: kubernetes.io/tls
691-
data:
788+
stringData:
692789
# 此例中的数据被截断
693790
tls.crt: |
791+
--------BEGIN CERTIFICATE-----
694792
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
695793
tls.key: |
794+
-----BEGIN RSA PRIVATE KEY-----
696795
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
697796
```
698797

@@ -720,36 +819,11 @@ kubectl create secret tls my-tls-secret \
720819
```
721820

722821
<!--
723-
The public/private key pair must exist before hand. The public key certificate
724-
for `--cert` must be DER format as per
725-
[Section 5.1 of RFC 7468](https://datatracker.ietf.org/doc/html/rfc7468#section-5.1),
726-
and must match the given private key for `--key` (PKCS #8 in DER format;
727-
[Section 11 of RFC 7468](https://datatracker.ietf.org/doc/html/rfc7468#section-11)).
822+
The public/private key pair must exist before hand. The public key certificate for `--cert` must be .PEM encoded
823+
and must match the given private key for `--key`.
728824
-->
729-
这里的公钥/私钥对都必须事先已存在。用于 `--cert` 的公钥证书必须是
730-
[RFC 7468 中 5.1 节](https://datatracker.ietf.org/doc/html/rfc7468#section-5.1)
731-
中所规定的 DER 格式，且与 `--key` 所给定的私钥匹配。
732-
私钥必须是 DER 格式的 PKCS #8
733-
（参见 [RFC 7468 第 11节](https://datatracker.ietf.org/doc/html/rfc7468#section-11)）。
734-
735-
{{< note >}}
736-
<!--
737-
A kubernetes.io/tls Secret stores the Base64-encoded DER data for keys and
738-
certificates. If you're familiar with PEM format for private keys and for certificates,
739-
the base64 data are the same as that format except that you omit
740-
the initial and the last lines that are used in PEM.
741-
-->
742-
类型为 `kubernetes.io/tls` 的 Secret 中包含密钥和证书的 DER 数据，以 Base64 格式编码。
743-
如果你熟悉私钥和证书的 PEM 格式，base64 与该格式相同，只是你需要略过 PEM
744-
数据中所包含的第一行和最后一行。
745-
746-
<!--
747-
For example, for a certificate, you do **not** include `--------BEGIN CERTIFICATE-----`
748-
and `-------END CERTIFICATE----`.
749-
-->
750-
例如，对于证书而言，你 **不要** 包含 `--------BEGIN CERTIFICATE-----`
751-
和 `-------END CERTIFICATE----` 这两行。
752-
{{< /note >}}
825+
公钥/私钥对必须事先存在，`--cert` 的公钥证书必须采用 .PEM 编码，
826+
并且必须与 `--key` 的给定私钥匹配。
753827

754828
<!--
755829
### Bootstrap token Secrets
@@ -1030,7 +1104,6 @@ spec:
10301104
- name: mypod
10311105
image: redis
10321106
volumeMounts:
1033-
- name: foo
10341107
mountPath: "/etc/foo"
10351108
readOnly: true
10361109
volumes:
@@ -1549,99 +1622,6 @@ spec:
15491622
image: myClientImage
15501623
```
15511624
1552-
<!--
1553-
### Use case: dotfiles in a secret volume
1554-
1555-
You can make your data "hidden" by defining a key that begins with a dot.
1556-
This key represents a dotfile or "hidden" file. For example, when the following secret
1557-
is mounted into a volume, `secret-volume`:
1558-
-->
1559-
### 使用场景：在 Secret 卷中带句点的文件 {#use-case-dotfiles-in-a-secret-volume}
1560-
1561-
通过定义以句点（`.`）开头的主键，你可以“隐藏”你的数据。
1562-
这些主键代表的是以句点开头的文件或“隐藏”文件。
1563-
例如，当下面的 Secret 被挂载到 `secret-volume` 卷中时：
1564-
1565-
```yaml
1566-
apiVersion: v1
1567-
kind: Secret
1568-
metadata:
1569-
name: dotfile-secret
1570-
data:
1571-
.secret-file: dmFsdWUtMg0KDQo=
1572-
---
1573-
apiVersion: v1
1574-
kind: Pod
1575-
metadata:
1576-
name: secret-dotfiles-pod
1577-
spec:
1578-
volumes:
1579-
- name: secret-volume
1580-
secret:
1581-
secretName: dotfile-secret
1582-
containers:
1583-
- name: dotfile-test-container
1584-
image: registry.k8s.io/busybox
1585-
command:
1586-
- ls
1587-
- "-l"
1588-
- "/etc/secret-volume"
1589-
volumeMounts:
1590-
- name: secret-volume
1591-
readOnly: true
1592-
mountPath: "/etc/secret-volume"
1593-
```
1594-
1595-
<!--
1596-
The volume will contain a single file, called `.secret-file`, and
1597-
the `dotfile-test-container` will have this file present at the path
1598-
`/etc/secret-volume/.secret-file`.
1599-
-->
1600-
卷中会包含一个名为 `.secret-file` 的文件，并且容器 `dotfile-test-container`
1601-
中此文件位于路径 `/etc/secret-volume/.secret-file` 处。
1602-
1603-
{{< note >}}
1604-
<!--
1605-
Files beginning with dot characters are hidden from the output of `ls -l`;
1606-
you must use `ls -la` to see them when listing directory contents.
1607-
-->
1608-
以句点开头的文件会在 `ls -l` 的输出中被隐藏起来；
1609-
列举目录内容时你必须使用 `ls -la` 才能看到它们。
1610-
{{< /note >}}
1611-
1612-
<!--
1613-
### Use case: Secret visible to one container in a Pod
1614-
1615-
Consider a program that needs to handle HTTP requests, do some complex business
1616-
logic, and then sign some messages with an HMAC. Because it has complex
1617-
application logic, there might be an unnoticed remote file reading exploit in
1618-
the server, which could expose the private key to an attacker.
1619-
-->
1620-
### 使用场景：仅对 Pod 中一个容器可见的 Secret {#use-case-secret-visible-to-one-container-in-a-pod}
1621-
1622-
考虑一个需要处理 HTTP 请求，执行某些复杂的业务逻辑，之后使用 HMAC
1623-
来对某些消息进行签名的程序。因为这一程序的应用逻辑很复杂，
1624-
其中可能包含未被注意到的远程服务器文件读取漏洞，
1625-
这种漏洞可能会把私钥暴露给攻击者。
1626-
1627-
<!--
1628-
This could be divided into two processes in two containers: a frontend container
1629-
which handles user interaction and business logic, but which cannot see the
1630-
private key; and a signer container that can see the private key, and responds
1631-
to simple signing requests from the frontend (for example, over localhost networking).
1632-
-->
1633-
这一程序可以分隔成两个容器中的两个进程：前端容器要处理用户交互和业务逻辑，
1634-
但无法看到私钥；签名容器可以看到私钥，并对来自前端的简单签名请求作出响应
1635-
（例如，通过本地主机网络）。
1636-
1637-
<!--
1638-
With this partitioned approach, an attacker now has to trick the application
1639-
server into doing something rather arbitrary, which may be harder than getting
1640-
it to read a file.
1641-
-->
1642-
采用这种划分的方法，攻击者现在必须欺骗应用服务器来做一些其他操作，
1643-
而这些操作可能要比读取一个文件要复杂很多。
1644-
16451625
<!--
16461626
## Immutable Secrets {#secret-immutable}
16471627
-->

0 commit comments

Comments
 (0)