[zh-cn] sync secrets-good-practices download apiserver-encryption.v1.md

Signed-off-by: xin.li <xin.li@daocloud.io>
kubernetes · Nov 26, 2023 · ac64f73 · ac64f73
1 parent 195465c
commit ac64f73
Show file tree

Hide file tree

Showing 3 changed files with 67 additions and 33 deletions.
diff --git a/content/zh-cn/docs/concepts/security/secrets-good-practices.md b/content/zh-cn/docs/concepts/security/secrets-good-practices.md
@@ -24,8 +24,8 @@ application developers. Use these guidelines to improve the security of your
 sensitive information in Secret objects, as well as to more effectively manage
 your Secrets.
 -->
-以下良好实践适用于集群管理员和应用开发者。遵从这些指导方针有助于提高 Secret 对象中敏感信息的安全性，
-还可以更有效地管理你的 Secret。
+以下良好实践适用于集群管理员和应用开发者。遵从这些指导方针有助于提高 Secret
+对象中敏感信息的安全性，还可以更有效地管理你的 Secret。
 
 <!-- body -->
 
@@ -112,6 +112,20 @@ recommendations include:
 * 使用生命期短暂的 Secret
 * 实现对特定事件发出警报的审计规则，例如同一用户并发读取多个 Secret 时发出警报
 
+<!--
+#### Additional ServiceAccount annotations for Secret management
+
+You can also use the `kubernetes.io/enforce-mountable-secrets` annotation on
+a ServiceAccount to enforce specific rules on how Secrets are used in a Pod.
+For more details, see the [documentation on this annotation](/docs/reference/labels-annotations-taints/#enforce-mountable-secrets).
+-->
+#### 用于 Secret 管理的附加 ServiceAccount 注解
+
+你还可以在 ServiceAccount 上使用 `kubernetes.io/enforce-mountable-secrets`
+注解来强制执行有关如何在 Pod 中使用 Secret 的特定规则。
+
+更多详细信息，请参阅[有关此注解的文档](/zh-cn/docs/reference/labels-annotations-taints/#enforce-mountable-secrets)。
+
 <!--
 ### Improve etcd management policies
 

diff --git a/content/zh-cn/docs/reference/config-api/apiserver-encryption.v1.md b/content/zh-cn/docs/reference/config-api/apiserver-encryption.v1.md
@@ -1,5 +1,5 @@
 ---
-title: kube-apiserver 加密配置 (v1)
+title: kube-apiserver 加密配置（v1）
 content_type: tool-reference
 package: apiserver.config.k8s.io/v1
 auto_generated: true
@@ -29,8 +29,8 @@ Package v1 is the v1 version of the API.
 ## `EncryptionConfiguration`     {#apiserver-config-k8s-io-v1-EncryptionConfiguration}
 
 <!--
-Use '<em>.<!!-- raw HTML omitted -->' to encrypt all resources within a group or '</em>.<em>' to encrypt all resources.
-'</em>.' can be used to encrypt all resource in the core group.  '<em>.</em>' will encrypt all
+Use '&ast;&lt;group&gt;o encrypt all resources within a group or '&ast;.&ast;' to encrypt all resources.
+'&ast;.' can be used to encrypt all resource in the core group.  '&ast;.&ast;' will encrypt all
 resources, even custom resources that are added after API server start.
 Use of wildcards that overlap within the same resource list or across multiple
 entries are not allowed since part of the configuration would be ineffective.
@@ -232,7 +232,7 @@ KMSConfiguration 包含基于 KMS 的封套转换器的名称、缓存大小以
    <!--
    timeout for gRPC calls to kms-plugin (ex. 5s). The default is 3 seconds.
    -->
-   对 KMS 插件执行 gRPC 调用的超时时长（例如，'5s'）。默认值为 3 秒。
+   对 KMS 插件执行 gRPC 调用的超时时长（例如：'5s'）。默认值为 3 秒。
    </p>
 </td>
 </tr>
@@ -398,9 +398,9 @@ ResourceConfiguration 中保存资源配置。
    <!--
    resources is a list of kubernetes resources which have to be encrypted. The resource names are derived from <code>resource</code> or <code>resource.group</code> of the group/version/resource.
    eg: pandas.awesome.bears.example is a custom resource with 'group': awesome.bears.example, 'resource': pandas.
-   Use '<em>.</em>' to encrypt all resources and '<em>.< raw HTML omitted >' to encrypt all resources in a specific group.
-   eg: '</em>.awesome.bears.example' will encrypt all resources in the group 'awesome.bears.example'.
-   eg: '*.' will encrypt all resources in the core group (such as pods, configmaps, etc).</p>
+   Use '&ast;.&ast;' to encrypt all resources and '&ast;.&lt;group&gt;' to encrypt all resources in a specific group.
+   eg: '&ast;.awesome.bears.example' will encrypt all resources in the group 'awesome.bears.example'.
+   eg: '&ast;.' will encrypt all resources in the core group (such as pods, configmaps, etc).</p>
    -->
    <code>resources</code> 是必须要加密的 Kubernetes 资源的列表。
    资源名称来自于组/版本/资源的 <code>resource</code> 或 <code>resource.group</code>。
@@ -457,7 +457,7 @@ SecretboxConfiguration 包含用于某 Secretbox 转换器的 API 配置。
    keys is a list of keys to be used for creating the Secretbox transformer.
    Each key has to be 32 bytes long.
    -->
-   <code>keys</code> 是一个密钥列表，用来创建 Secretbox 转换器。每个密钥必须是 32 字节长。
+   <code>keys</code> 是一个密钥列表，用来创建 Secretbox 转换器。每个密钥长度必须是 32 字节。
    </p>
 </td>
 </tr>

diff --git a/content/zh-cn/releases/download.md b/content/zh-cn/releases/download.md
@@ -55,7 +55,7 @@ kubectl 可安装在各种 Linux 平台、macOS 和 Windows 上。
 - [在 Windows 上安装 kubectl](/zh-cn/docs/tasks/tools/install-kubectl-windows)
 
 <!--
-## Container Images
+## Container images
 
 All Kubernetes container images are deployed to the
 `registry.k8s.io` container image registry.
@@ -64,39 +64,59 @@ All Kubernetes container images are deployed to the
 
 所有 Kubernetes 容器镜像都被部署到 `registry.k8s.io` 容器镜像仓库。
 
-{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
-
 <!--
-For Kubernetes {{< param "version" >}}, the following
-container images are signed using [cosign](https://github.com/sigstore/cosign)
-signatures:
+| Container Image                                                           | Supported Architectures          |
 -->
-对于 Kubernetes {{< param "version" >}}，以下容器镜像使用
-[cosign](https://github.com/sigstore/cosign) 进行签名：
-
-<!--
-| Container Image                                                    | Supported Architectures            |
--->
-| 容器镜像                                                             | 支持架构                           |
-| ------------------------------------------------------------------- | --------------------------------- |
+| 容器镜像                                                                   | 支持架构                           |
+| ------------------------------------------------------------------------- | --------------------------------- |
 | registry.k8s.io/kube-apiserver:v{{< skew currentPatchVersion >}}          | amd64, arm, arm64, ppc64le, s390x |
 | registry.k8s.io/kube-controller-manager:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
 | registry.k8s.io/kube-proxy:v{{< skew currentPatchVersion >}}              | amd64, arm, arm64, ppc64le, s390x |
 | registry.k8s.io/kube-scheduler:v{{< skew currentPatchVersion >}}          | amd64, arm, arm64, ppc64le, s390x |
 | registry.k8s.io/conformance:v{{< skew currentPatchVersion >}}             | amd64, arm, arm64, ppc64le, s390x |
 
+<!--
+### Container image architectures
+-->
+### 容器镜像架构
+
 <!--
 All container images are available for multiple architectures, whereas the
 container runtime should choose the correct one based on the underlying
 platform. It is also possible to pull a dedicated architecture by suffixing the
 container image name, for example
-`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. All
-those derivations are signed in the same way as the multi-architecture manifest lists.
+`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. 
 -->
 所有容器镜像都支持多架构，而容器运行时应根据下层平台选择正确的镜像。
 也可以通过给容器镜像名称加后缀来拉取适合特定架构的镜像，例如
 `registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`。
-所有这些派生镜像都以与多架构清单列表相同的方式签名。
+
+<!--
+### Container image signatures
+-->
+### 容器镜像签名
+
+{{< feature-state for_k8s_version="v1.26" state="beta" >}}
+
+<!--
+For Kubernetes {{< param "version" >}},
+container images are signed using [sigstore](https://sigstore.dev)
+signatures:
+-->
+对于 Kubernetes {{< param "version" >}}，容器镜像使用
+[sigstore](https://sigstore.dev) 进行签名：
+
+{{< note >}}
+<!--
+Container image sigstore signatures do currently not match between different geographical locations.
+More information about this problem is available in the corresponding
+[GitHub issue](https://github.com/kubernetes/registry.k8s.io/issues/187).
+-->
+目前，不同地理位置之间的容器镜像 sigstore 签名不匹配。
+有关此问题的更多信息，请参阅相应的
+[GitHub Issue](https://github.com/kubernetes/registry.k8s.io/issues/187)。
+{{< /note >}}
+
 
 <!--
 The Kubernetes project publishes a list of signed Kubernetes container images
@@ -111,18 +131,18 @@ curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/r
 ```
 
 <!--
-For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that
-you can verify integrity for is a container image, using the experimental
-signing support.
-
 To manually verify signed container images of Kubernetes core components, refer to
 [Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
 -->
-对于 Kubernetes v{{< skew currentVersion >}}，唯一可以验证完整性的代码工件就是容器镜像，它使用实验性签名支持。
-
 如需手动验证 Kubernetes 核心组件的签名容器镜像，
 请参考[验证签名容器镜像](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts)。
 
+<!--
+If you pull a container image for a specific architecture, the single-architecture image
+is signed in the same way as for the multi-architecture manifest lists.
+-->
+如果你要拉取特定架构的容器镜像，则单架构镜像的签名方式与多架构清单列表相同。
+
 <!--
 ## Binaries
 -->