kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #43251 from windsonsea/secrety 

[zh] Sync /concepts/configuration/secret.md
pull/43370/head
Kubernetes Prow Robot 2023-10-07 14:11:07 +02:00 committed by GitHub
parent b4f8e61b56 f8f5a5c7a6
commit 2e8ac8de98
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 183 additions and 150 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

333
content/zh-cn/docs/concepts/configuration/secret.md
View File

@ -330,8 +330,8 @@ Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用
则你必须满足为该类型所定义的所有要求。
<!--
If you are defining a type of secret that's for public use, follow the convention
and structure the secret type to have your domain name before the name, separated
If you are defining a type of Secret that's for public use, follow the convention
and structure the Secret type to have your domain name before the name, separated
by a `/`. For example: `cloud-hosting.example.net/cloud-api-credentials`.
-->
如果你要定义一种公开使用的 Secret 类型，请遵守 Secret 类型的约定和结构，
@ -339,19 +339,19 @@ by a `/`. For example: `cloud-hosting.example.net/cloud-api-credentials`.
例如：`cloud-hosting.example.net/cloud-api-credentials`。
<!--
### Opaque secrets
### Opaque Secrets
`Opaque` is the default Secret type if omitted from a Secret configuration file.
When you create a Secret using `kubectl`, you will use the `generic`
subcommand to indicate an `Opaque` Secret type. For example, the following
command creates an empty Secret of type `Opaque`.
`Opaque` is the default Secret type if you don't explicitly specify a type in
a Secret manifest. When you create a Secret using `kubectl`, you must use the
`generic` subcommand to indicate an `Opaque` Secret type. For example, the
following command creates an empty Secret of type `Opaque`:
-->
### Opaque Secret
当 Secret 配置文件中未作显式设定时，默认的 Secret 类型是 `Opaque`。
当你使用 `kubectl` 来创建一个 Secret 时，你会使用 `generic`
子命令来标明要创建的是一个 `Opaque` 类型 Secret。
例如，下面的命令会创建一个空的 `Opaque` 类型 Secret 对象：
当你未在 Secret 清单中显式指定类型时，默认的 Secret 类型是 `Opaque`。
当你使用 `kubectl` 来创建一个 Secret 时，你必须使用 `generic`
子命令来标明要创建的是一个 `Opaque` 类型的 Secret。
例如，下面的命令会创建一个空的 `Opaque` 类型的 Secret：
```shell
kubectl create secret generic empty-secret
@ -361,7 +361,7 @@ kubectl get secret empty-secret
<!--
The output looks like:
-->
输出类似于
输出类似于：
```
NAME TYPE DATA AGE
@ -376,89 +376,87 @@ In this case, `0` means you have created an empty Secret.
在这个例子中，`0` 意味着你刚刚创建了一个空的 Secret。
<!--
### Service account token Secrets
### ServiceAccount token Secrets
A `kubernetes.io/service-account-token` type of Secret is used to store a
token credential that identifies a
{{< glossary_tooltip text="service account" term_id="service-account" >}}.
{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}. This
is a legacy mechanism that provides long-lived ServiceAccount credentials to
Pods.
-->
### 服务账号令牌 Secret {#service-account-token-secrets}
### ServiceAccount 令牌 Secret {#service-account-token-secrets}
类型为 `kubernetes.io/service-account-token` 的 Secret
用来存放标识某{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌凭据。
类型为 `kubernetes.io/service-account-token` 的 Secret 用来存放标识某
{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}} 的令牌凭据。
这是为 Pod 提供长期有效 ServiceAccount 凭据的传统机制。
<!--
In Kubernetes v1.22 and later, the recommended approach is to obtain a
short-lived, automatically rotating ServiceAccount token by using the
[`TokenRequest`](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
API instead. You can get these short-lived tokens using the following methods:
-->
在 Kubernetes v1.22 及更高版本中，推荐的方法是通过使用
[`TokenRequest`](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API
来获取短期自动轮换的 ServiceAccount 令牌。你可以使用以下方法获取这些短期令牌：
<!--
* Call the `TokenRequest` API either directly or by using an API client like
`kubectl`. For example, you can use the
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
command.
* Request a mounted token in a
[projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
in your Pod manifest. Kubernetes creates the token and mounts it in the Pod.
The token is automatically invalidated when the Pod that it's mounted in is
deleted. For details, see
[Launch a Pod using service account token projection](/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection).
-->
- 直接调用 `TokenRequest` API，或者使用像 `kubectl` 这样的 API 客户端。
例如，你可以使用
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 命令。
- 在 Pod 清单中请求使用[投射卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)挂载的令牌。
Kubernetes 会创建令牌并将其挂载到 Pod 中。
当挂载令牌的 Pod 被删除时，此令牌会自动失效。
更多细节参阅[启动使用服务账号令牌投射的 Pod](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection)。
{{< note >}}
<!--
Versions of Kubernetes before v1.22 automatically created credentials for
accessing the Kubernetes API. This older mechanism was based on creating token
Secrets that could then be mounted into running Pods.
In more recent versions, including Kubernetes v{{< skew currentVersion >}}, API
credentials are obtained directly by using the
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
API, and are mounted into Pods using a
[projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).
The tokens obtained using this method have bounded lifetimes, and are
automatically invalidated when the Pod they are mounted into is deleted.
-->
Kubernetes 在 v1.22 版本之前都会自动创建用来访问 Kubernetes API 的凭据。
这一老的机制是基于创建可被挂载到运行中 Pod 内的令牌 Secret 来实现的。
在最近的版本中，包括 Kubernetes v{{< skew currentVersion >}} 中，API 凭据是直接通过
[TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
API 来获得的，这一凭据会使用[投射卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)挂载到
Pod 中。使用这种方式获得的令牌有确定的生命期，并且在挂载它们的 Pod 被删除时自动作废。
<!--
You can still
[manually create](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
a service account token Secret; for example, if you need a token that never
expires. However, using the
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
subresource to obtain a token to access the API is recommended instead.
You can use the
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
command to obtain a token from the `TokenRequest` API.
-->
你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
服务账号令牌。例如，当你需要一个永远都不过期的令牌时。
不过，仍然建议使用 [TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
子资源来获得访问 API 服务器的令牌。
你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
命令调用 `TokenRequest` API 获得令牌。
{{< /note >}}
<!--
You should only create a service account token Secret object
You should only create a ServiceAccount token Secret
if you can't use the `TokenRequest` API to obtain a token,
and the security exposure of persisting a non-expiring token credential
in a readable API object is acceptable to you.
in a readable API object is acceptable to you. For instructions, see
[Manually create a long-lived API token for a ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token).
-->
只有在你无法使用 `TokenRequest` API 来获取令牌，
并且你能够接受因为将永不过期的令牌凭据写入到可读取的 API 对象而带来的安全风险时，
才应该创建服务账号令牌 Secret 对象。
才应该创建 ServiceAccount 令牌 Secret。
更多细节参阅[为 ServiceAccount 手动创建长期有效的 API 令牌](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)。
{{< /note >}}
<!--
When using this Secret type, you need to ensure that the
`kubernetes.io/service-account.name` annotation is set to an existing
service account name. If you are creating both the ServiceAccount and
ServiceAccount name. If you are creating both the ServiceAccount and
the Secret objects, you should create the ServiceAccount object first.
-->
使用这种 Secret 类型时，你需要确保对象的注解 `kubernetes.io/service-account-name`
被设置为某个已有的服务账号名称。
如果你同时负责 ServiceAccount 和 Secret 对象的创建，应该先创建 ServiceAccount 对象。
被设置为某个已有的 ServiceAccount 名称。
如果你同时创建 ServiceAccount 和 Secret 对象，应该先创建 ServiceAccount 对象。
<!--
After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}}
fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the
`token` key in the `data` field, which is set to contain an authentication token.
`token` key in the `data` field, which is populated with an authentication token.
The following example configuration declares a service account token Secret:
The following example configuration declares a ServiceAccount token Secret:
-->
当 Secret 对象被创建之后，某个 Kubernetes{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写
Secret 的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的
`token` 键值，使之包含实际的令牌内容。
当 Secret 对象被创建之后，某个 Kubernetes
{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写
Secret 的其它字段，例如 `kubernetes.io/service-account.uid` 注解和
`data` 字段中的 `token` 键值（该键包含一个身份认证令牌）。
下面的配置实例声明了一个服务账号令牌 Secret：
下面的配置实例声明了一个 ServiceAccount 令牌 Secret：
<!--
```yaml
@ -493,18 +491,18 @@ After creating the Secret, wait for Kubernetes to populate the `token` key in th
创建了 Secret 之后，等待 Kubernetes 在 `data` 字段中填充 `token` 主键。
<!--
See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
documentation for more information on how service accounts work.
See the [ServiceAccount](/docs/concepts/security/service-accounts/)
documentation for more information on how ServiceAccounts work.
You can also check the `automountServiceAccountToken` field and the
`serviceAccountName` field of the
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
for information on referencing service account credentials from within Pods.
for information on referencing ServiceAccount credentials from within Pods.
-->
参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
文档了解服务账号的工作原理。你也可以查看
参考 [ServiceAccount](/zh-cn/docs/concepts/security/service-accounts/)
文档了解 ServiceAccount 的工作原理。你也可以查看
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档，
进一步了解从 Pod 中引用服务账号凭据。
进一步了解从 Pod 中引用 ServiceAccount 凭据。
<!--
### Docker config Secrets
@ -517,37 +515,29 @@ you must use one of the following `type` values for that Secret:
如果你要创建 Secret 用来存放用于访问容器镜像仓库的凭据，则必须选用以下 `type`
值之一来创建 Secret：
- `kubernetes.io/dockercfg`
- `kubernetes.io/dockerconfigjson`
<!--
The `kubernetes.io/dockercfg` type is reserved to store a serialized
`~/.dockercfg` which is the legacy format for configuring Docker command line.
When using this Secret type, you have to ensure the Secret `data` field
contains a `.dockercfg` key whose value is content of a `~/.dockercfg` file
encoded in the base64 format.
- `kubernetes.io/dockercfg`: store a serialized `~/.dockercfg` which is the
legacy format for configuring Docker command line. The Secret
`data` field contains a `.dockercfg` key whose value is the content of a
base64 encoded `~/.dockercfg` file.
- `kubernetes.io/dockerconfigjson`: store a serialized JSON that follows the
same format rules as the `~/.docker/config.json` file, which is a new format
for `~/.dockercfg`. The Secret `data` field must contain a
`.dockerconfigjson` key for which the value is the content of a base64
encoded `~/.docker/config.json` file.
-->
`kubernetes.io/dockercfg` 是一种保留类型，用来存放 `~/.dockercfg` 文件的序列化形式。
该文件是配置 Docker 命令行的一种老旧形式。使用此 Secret 类型时，你需要确保
Secret 的 `data` 字段中包含名为 `.dockercfg` 的主键，其对应键值是用 base64
编码的某 `~/.dockercfg` 文件的内容。
- `kubernetes.io/dockercfg`：存放 `~/.dockercfg` 文件的序列化形式，它是配置 Docker
命令行的一种老旧形式。Secret 的 `data` 字段包含名为 `.dockercfg` 的主键，
其值是用 base64 编码的某 `~/.dockercfg` 文件的内容。
- `kubernetes.io/dockerconfigjson`：存放 JSON 数据的序列化形式，
该 JSON 也遵从 `~/.docker/config.json` 文件的格式规则，而后者是 `~/.dockercfg`
的新版本格式。使用此 Secret 类型时，Secret 对象的 `data` 字段必须包含
`.dockerconfigjson` 键，其键值为 base64 编码的字符串包含 `~/.docker/config.json`
文件的内容。
<!--
The `kubernetes.io/dockerconfigjson` type is designed for storing a serialized
JSON that follows the same format rules as the `~/.docker/config.json` file
which is a new format for `~/.dockercfg`.
When using this Secret type, the `data` field of the Secret object must
contain a `.dockerconfigjson` key, in which the content for the
`~/.docker/config.json` file is provided as a base64 encoded string.
Below is an example for a `kubernetes.io/dockercfg` type of Secret:
-->
类型 `kubernetes.io/dockerconfigjson` 被设计用来保存 JSON 数据的序列化形式，
该 JSON 也遵从 `~/.docker/config.json` 文件的格式规则，而后者是 `~/.dockercfg`
的新版本格式。使用此 Secret 类型时，Secret 对象的 `data` 字段必须包含
`.dockerconfigjson` 键，其键值为 base64 编码的字符串包含 `~/.docker/config.json`
文件的内容。
下面是一个 `kubernetes.io/dockercfg` 类型 Secret 的示例：
```yaml
@ -570,20 +560,20 @@ If you do not want to perform the base64 encoding, you can choose to use the
{{< /note >}}
<!--
When you create these types of Secrets using a manifest, the API
When you create Docker config Secrets using a manifest, the API
server checks whether the expected key exists in the `data` field, and
it verifies if the value provided can be parsed as a valid JSON. The API
server doesn't validate if the JSON actually is a Docker config file.
When you do not have a Docker config file, or you want to use `kubectl`
to create a Secret for accessing a container registry, you can do:
You can also use `kubectl` to create a Secret for accessing a container
registry, such as when you don't have a Docker configuration file:
-->
当你使用清单文件来创建这两类 Secret 时，API 服务器会检查 `data` 字段中是否存在所期望的主键，
当你使用清单文件通过 Docker 配置来创建 Secret 时，API 服务器会检查 `data` 字段中是否存在所期望的主键，
并且验证其中所提供的键值是否是合法的 JSON 数据。
不过，API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。
当你没有 Docker 配置文件，或者你想使用 `kubectl` 创建一个 Secret
来访问容器仓库时，你可以这样做：
你还可以使用 `kubectl` 创建一个 Secret 来访问容器仓库时，
当你没有 Docker 配置文件时你可以这样做：
```shell
kubectl create secret docker-registry secret-tiger-docker \
@ -594,22 +584,24 @@ kubectl create secret docker-registry secret-tiger-docker \
```
<!--
That command creates a Secret of type `kubernetes.io/dockerconfigjson`.
If you dump the `.data.dockerconfigjson` field from that new Secret and then
decode it from base64:
This command creates a Secret of type `kubernetes.io/dockerconfigjson`.
Retrieve the `.data.dockerconfigjson` field from that new Secret and decode the
data:
-->
上面的命令创建一个类型为 `kubernetes.io/dockerconfigjson` 的 Secret。
如果你对 `.data.dockerconfigjson` 内容进行转储并执行 base64 解码：
此命令创建一个类型为 `kubernetes.io/dockerconfigjson` 的 Secret。
从这个新的 Secret 中获取 `.data.dockerconfigjson` 字段并执行数据解码：
```shell
kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d
```
<!--
then the output is equivalent to this JSON document (which is also a valid
The output is equivalent to the following JSON document (which is also a valid
Docker configuration file):
-->
那么输出等价于这个 JSON 文档（这也是一个有效的 Docker 配置文件）：
输出等价于以下 JSON 文档（这也是一个有效的 Docker 配置文件）：
```json
{
@ -657,16 +649,29 @@ Secret must contain one of the following two keys:
- `password`: 用于身份认证的密码或令牌。
<!--
Both values for the above two keys are base64 encoded strings. You can, of
course, provide the clear text content using the `stringData` for Secret
creation.
Both values for the above two keys are base64 encoded strings. You can
alternatively provide the clear text content using the `stringData` field in the
Secret manifest.
The following manifest is an example of a basic authentication Secret:
-->
以上两个键的键值都是 base64 编码的字符串。
当然你也可以在创建 Secret 时使用 `stringData` 字段来提供明文形式的内容。
当然你也可以在 Secret 清单中的使用 `stringData` 字段来提供明文形式的内容。
以下清单是基本身份验证 Secret 的示例：
<!--
```yaml
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
username: admin # required field for kubernetes.io/basic-auth
password: t0p-Secret # required field for kubernetes.io/basic-auth
```
-->
```yaml
apiVersion: v1
kind: Secret
@ -693,7 +698,7 @@ The Kubernetes API verifies that the required keys are set for a Secret of this
API 服务器会检查 Secret 配置中是否提供了所需要的主键。
<!--
### SSH authentication secrets
### SSH authentication Secrets
The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in
SSH authentication. When using this Secret type, you will have to specify a
@ -711,6 +716,19 @@ Kubernetes 所提供的内置类型 `kubernetes.io/ssh-auth` 用来存放 SSH
下面的清单是一个 SSH 公钥/私钥身份认证的 Secret 示例：
<!--
```yaml
apiVersion: v1
kind: Secret
metadata:
name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
# the data is abbreviated in this example
ssh-privatekey: |
MIIEpQIBAAKCAQEAulqb/Y ...
```
-->
```yaml
apiVersion: v1
kind: Secret
@ -724,18 +742,18 @@ data:
```
<!--
The SSH authentication Secret type is provided only for user's convenience.
You could instead create an `Opaque` type Secret for credentials used for SSH authentication.
The SSH authentication Secret type is provided only for convenience.
You can create an `Opaque` type for credentials used for SSH authentication.
However, using the defined and public Secret type (`kubernetes.io/ssh-auth`) helps other
people to understand the purpose of your Secret, and sets a convention for what key names
to expect.
and the API server does verify if the required keys are provided in a Secret configuration.
The Kubernetes API verifies that the required keys are set for a Secret of this type.
-->
提供 SSH 身份认证类型的 Secret 仅仅是出于用户方便性考虑。
你也可以使用 `Opaque` 类型来保存用于 SSH 身份认证的凭据。
提供 SSH 身份认证类型的 Secret 仅仅是出于方便性考虑。
你可以使用 `Opaque` 类型来保存用于 SSH 身份认证的凭据。
不过，使用预定义的、公开的 Secret 类型（`kubernetes.io/ssh-auth`）
有助于其他人理解你的 Secret 的用途，也可以就其中包含的主键名形成约定。
API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。
Kubernetes API 会验证这种类型的 Secret 中是否设定了所需的主键。
{{< caution >}}
<!--
@ -749,26 +767,28 @@ SSH 私钥自身无法建立 SSH 客户端与服务器端之间的可信连接
{{< /caution >}}
<!--
### TLS secrets
### TLS Secrets
Kubernetes provides a builtin Secret type `kubernetes.io/tls` for storing
The `kubernetes.io/tls` Secret type is for storing
a certificate and its associated key that are typically used for TLS.
One common use for TLS secrets is to configure encryption in transit for
One common use for TLS Secrets is to configure encryption in transit for
an [Ingress](/docs/concepts/services-networking/ingress/), but you can also use it
with other resources or directly in your workload.
When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided
in the `data` (or `stringData`) field of the Secret configuration, although the API
server doesn't actually validate the values for each key.
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.
As an alternative to using `stringData`, you can use the `data` field to provide
the base64 encoded certificate and private key. For details, see
[Constraints on Secret names and data](#restriction-names-data).
The following YAML contains an example config for a TLS Secret:
-->
### TLS Secret
Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS
场合通常要使用的证书及其相关密钥。
`kubernetes.io/tls` Secret 类型用来存放 TLS 场合通常要使用的证书及其相关密钥。
TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。
当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含
@ -779,6 +799,23 @@ TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-n
下面的 YAML 包含一个 TLS Secret 的配置示例：
<!--
```yaml
apiVersion: v1
kind: Secret
metadata:
name: secret-tls
type: kubernetes.io/tls
stringData:
# the data is abbreviated in this example
tls.crt: |
--------BEGIN CERTIFICATE-----
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
tls.key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
```
-->
```yaml
apiVersion: v1
kind: Secret
@ -796,21 +833,20 @@ stringData:
```
<!--
The TLS Secret type is provided for user's convenience. You can create an `Opaque`
for credentials used for TLS server and/or client. However, using the builtin Secret
type helps ensure the consistency of Secret format in your project; the API server
does verify if the required keys are provided in a Secret configuration.
The TLS Secret type is provided only for convenience.
You can create an `Opaque` type for credentials used for TLS authentication.
However, using the defined and public Secret type (`kubernetes.io/ssh-auth`)
helps ensure the consistency of Secret format in your project. The API server
verifies if the required keys are set for a Secret of this type.
When creating a TLS Secret using `kubectl`, you can use the `tls` subcommand
as shown in the following example:
To create a TLS Secret using `kubectl`, use the `tls` subcommand:
-->
提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑。
你也可以使用 `Opaque` 类型来保存用于 TLS 服务器与/或客户端的凭据。
不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且
API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。
提供 TLS 类型的 Secret 仅仅是出于方便性考虑。
你可以创建 `Opaque` 类型的 Secret 来保存用于 TLS 身份认证的凭据。
不过，使用已定义和公开的 Secret 类型有助于确保你自己项目中的 Secret 格式的一致性。
API 服务器会验证这种类型的 Secret 是否设定了所需的主键。
当使用 `kubectl` 来创建 TLS Secret 时，你可以像下面的例子一样使用 `tls`
子命令：
要使用 `kubectl` 创建 TLS Secret，你可以使用 `tls` 子命令：
```shell
kubectl create secret tls my-tls-secret \
@ -828,15 +864,13 @@ and must match the given private key for `--key`.
<!--
### Bootstrap token Secrets
A bootstrap token Secret can be created by explicitly specifying the Secret
`type` to `bootstrap.kubernetes.io/token`. This type of Secret is designed for
The `bootstrap.kubernetes.io/token` Secret type is for
tokens used during the node bootstrap process. It stores tokens used to sign
well-known ConfigMaps.
-->
### 启动引导令牌 Secret {#bootstrap-token-secrets}
通过将 Secret 的 `type` 设置为 `bootstrap.kubernetes.io/token`
可以创建启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。
`bootstrap.kubernetes.io/token` Secret 类型针对的是节点启动引导过程所用的令牌。
其中包含用来为周知的 ConfigMap 签名的令牌。
<!--
@ -870,7 +904,7 @@ data:
```
<!--
A bootstrap type Secret has the following keys specified under `data`:
A bootstrap token Secret has the following keys specified under `data`:
- `token-id`: A random 6 character string as the token identifier. Required.
- `token-secret`: A random 16 character string as the actual token secret. Required.
@ -895,8 +929,8 @@ A bootstrap type Secret has the following keys specified under `data`:
`system:bootstrappers` 组之外，还会被添加到所列的用户组中。
<!--
The above YAML may look confusing because the values are all in base64 encoded
strings. In fact, you can create an identical Secret using the following YAML:
You can alternatively provide the values in the `stringData` field of the Secret
without base64 encoding them:
```yaml
apiVersion: v1
@ -919,8 +953,7 @@ stringData:
usage-bootstrap-signing: "true"
```
-->
上面的 YAML 文件可能看起来令人费解，因为其中的数值均为 base64 编码的字符串。
实际上，你完全可以使用下面的 YAML 来创建一个一模一样的 Secret：
你也可以在 Secret 的 `stringData` 字段中提供值，而无需对其进行 base64 编码：
```yaml
apiVersion: v1