静态加密机密数据

Kubernetes 中所有允许你写入持久 API 资源数据的 API 都支持静态加密。 例如，你可以为 Secret 启用静态加密。 这种静态加密是对 etcd 集群或运行 kube-apiserver 的主机上的文件系统的任何系统级加密的补充。

此页面展示如何启用和配置静态 API 数据加密。

开始之前

• 你需要一个 Kubernetes 集群，并且必须配置 kubectl 命令行工具以与你的集群通信。 建议在至少有两个不充当控制平面主机的节点的集群上运行本教程。 如果你还没有集群，可以使用 minikube 创建一个，或者你可以使用以下 Kubernetes 游乐场之一

  • Killercoda
  • Play with Kubernetes

• 此任务假设你正在每个控制平面节点上将 Kubernetes API 服务器作为静态 Pod运行。

• 你的集群的控制平面**必须**使用 etcd v3.x（主版本 3，任何次版本）。

• 要加密自定义资源，你的集群必须运行 Kubernetes v1.26 或更高版本。

• 要使用通配符来匹配资源，你的集群必须运行 Kubernetes v1.27 或更高版本。

确定是否已启用静态加密

默认情况下，API 服务器将资源的纯文本表示形式存储到 etcd 中，没有静态加密。

kube-apiserver 进程接受一个参数 --encryption-provider-config，该参数指定配置文件的路径。 如果你指定了该文件，则该文件的内容将控制 Kubernetes API 数据如何在 etcd 中加密。 如果你运行 kube-apiserver 时没有 --encryption-provider-config 命令行参数，则你没有启用静态加密。 如果你运行 kube-apiserver 时带有 --encryption-provider-config 命令行参数，并且它引用的文件将 identity 提供程序指定为列表中的第一个加密提供程序，则你没有启用静态加密（**默认的 identity 提供程序不提供任何机密性保护。**）

如果你运行 kube-apiserver 时带有 --encryption-provider-config 命令行参数，并且它引用的文件将 identity 以外的提供程序指定为列表中的第一个加密提供程序，则你已经启用了静态加密。 但是，该检查不会告诉你以前迁移到加密存储是否成功。 如果你不确定，请参阅 确保所有相关数据都已加密。

了解静态加密配置

---
#
# CAUTION: this is an example configuration.
#          Do not use this for your own cluster!
#
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example # a custom resource API
    providers:
      # This configuration does not provide data confidentiality. The first
      # configured provider is specifying the "identity" mechanism, which
      # stores resources as plain text.
      #
      - identity: {} # plain text, in other words NO encryption
      - aesgcm:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - aescbc:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - secretbox:
          keys:
            - name: key1
              secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
  - resources:
      - events
    providers:
      - identity: {} # do not encrypt Events even though *.* is specified below
  - resources:
      - '*.apps' # wildcard match requires Kubernetes 1.27 or later
    providers:
      - aescbc:
          keys:
          - name: key2
            secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
  - resources:
      - '*.*' # wildcard match requires Kubernetes 1.27 or later
    providers:
      - aescbc:
          keys:
          - name: key3
            secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==

每个 resources 数组项都是一个单独的配置，并且包含完整的配置。 resources.resources 字段是一个 Kubernetes 资源名称（resource 或 resource.group）数组，应加密这些资源，例如 Secrets、ConfigMaps 或其他资源。

如果将自定义资源添加到 EncryptionConfiguration，并且集群版本为 1.26 或更高版本，则将加密 EncryptionConfiguration 中提到的任何新创建的自定义资源。 存在于该版本和配置之前的 etcd 中的任何自定义资源都将保持未加密状态，直到下次写入存储为止。 这与内置资源的行为相同。 请参阅确保所有 Secret 都已加密部分。

providers 数组是用于你列出的 API 的可能加密提供程序的有序列表。 每个提供程序都支持多个密钥 - 解密时会按顺序尝试这些密钥，如果提供程序是第一个提供程序，则第一个密钥用于加密。

每个条目只能指定一种提供程序类型（可以提供 identity 或 aescbc，但不能在同一条目中同时提供两者）。 列表中的第一个提供程序用于加密写入存储的资源。 从存储读取资源时，每个与存储的数据匹配的提供程序都会尝试按顺序解密数据。 如果由于格式或密钥不匹配而导致没有提供程序可以读取存储的数据，则会返回一个错误，这会阻止客户端访问该资源。

EncryptionConfiguration 支持使用通配符来指定应加密的资源。使用 '*.<group>' 来加密组内的所有资源（例如上面示例中的 '*.apps'），或者使用 '*.*' 来加密所有资源。'*.' 可用于加密核心组中的所有资源。'*.*' 将加密所有资源，甚至是 API 服务器启动后添加的自定义资源。

如果有一个通配符覆盖了资源，并且你想为特定类型的资源选择不进行静态加密，你可以通过添加一个单独的 resources 数组项来实现，该项包含你想要豁免的资源的名称，然后添加一个 providers 数组项，其中指定 identity 提供程序。你将此项添加到列表时，需要使其出现在你指定加密的配置（一个不是 identity 的提供程序）之前。

例如，如果启用了 '*.*'，并且你想为 Events 和 ConfigMaps 选择不进行加密，请在 resources 中添加一个新的较早的项，然后添加 providers 数组项，其中 provider 为 identity。更具体的条目必须在通配符条目之前。

新条目将类似于：

  ...
  - resources:
      - configmaps. # specifically from the core API group,
                    # because of trailing "."
      - events
    providers:
      - identity: {}
  # and then other entries in resources

确保豁免项在 resources 数组中通配符 '*.*' 项之前列出，以使其具有优先权。

有关 EncryptionConfiguration 结构的更多详细信息，请参阅加密配置 API。

可用的提供程序

在为集群的 Kubernetes API 中的数据配置静态加密之前，你需要选择要使用的提供程序。

下表描述了每个可用的提供程序。

如果不另行指定，identity 提供程序是默认的。identity 提供程序不加密存储的数据，并且不提供任何额外的机密性保护。

密钥存储

本地密钥存储

使用本地管理的密钥加密秘密数据可以防止 etcd 泄露，但无法防止主机泄露。由于加密密钥存储在主机上的 EncryptionConfiguration YAML 文件中，因此熟练的攻击者可以访问该文件并提取加密密钥。

托管 (KMS) 密钥存储

KMS 提供程序使用信封加密：Kubernetes 使用数据密钥加密资源，然后使用托管加密服务加密该数据密钥。Kubernetes 为每个资源生成唯一的数据密钥。API 服务器将数据密钥的加密版本与密文一起存储在 etcd 中；在读取资源时，API 服务器调用托管加密服务并提供密文和（加密的）数据密钥。在托管加密服务中，提供程序使用密钥加密密钥来解密数据密钥，解密数据密钥，最后恢复纯文本。控制平面和 KMS 之间的通信需要传输中保护，例如 TLS。

使用信封加密会产生对密钥加密密钥的依赖性，而密钥加密密钥未存储在 Kubernetes 中。在 KMS 的情况下，打算未经授权访问纯文本值的攻击者需要同时泄露 etcd 和第三方 KMS 提供程序。

加密密钥的保护

你应该采取适当的措施来保护允许解密的机密信息，无论是本地加密密钥还是允许 API 服务器调用 KMS 的身份验证令牌。

即使你依赖提供程序来管理主加密密钥（或多个密钥）的使用和生命周期，你仍然有责任确保托管加密服务的访问控制和其他安全措施适合你的安全需求。

加密你的数据

生成加密密钥

以下步骤假设你未使用 KMS，因此这些步骤还假设你需要生成加密密钥。如果你已经有加密密钥，请跳到编写加密配置文件。

首先生成一个新的加密密钥，然后使用 base64 对其进行编码

• Linux
• macOS
• Windows

head -c 32 /dev/urandom | base64

head -c 32 /dev/urandom | base64

# Do not run this in a session where you have set a random number
# generator seed.
[Convert]::ToBase64String((1..32|%{[byte](Get-Random -Max 256)}))

复制加密密钥

使用安全的文件传输机制，将该加密密钥的副本提供给每个其他控制平面主机。

至少，在传输过程中使用加密 - 例如，安全外壳 (SSH)。为了提高安全性，请在主机之间使用非对称加密，或更改你正在使用的方法，以便你依赖 KMS 加密。

编写加密配置文件

创建一个新的加密配置文件。内容应类似于：

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example
    providers:
      - aescbc:
          keys:
            - name: key1
              # See the following text for more details about the secret value
              secret: <BASE 64 ENCODED SECRET>
      - identity: {} # this fallback allows reading unencrypted secrets;
                     # for example, during initial migration

要创建新的加密密钥（不使用 KMS），请参阅生成加密密钥。

使用新的加密配置文件

你需要将新的加密配置文件挂载到 kube-apiserver 静态 Pod。以下是如何执行此操作的示例：

1. 将新的加密配置文件保存到控制平面节点上的 /etc/kubernetes/enc/enc.yaml。

2. 编辑 kube-apiserver 静态 Pod 的清单：/etc/kubernetes/manifests/kube-apiserver.yaml，使其类似于：

   ---
   #
   # This is a fragment of a manifest for a static Pod.
   # Check whether this is correct for your cluster and for your API server.
   #
   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.20.30.40:443
     creationTimestamp: null
     labels:
       app.kubernetes.io/component: kube-apiserver
       tier: control-plane
     name: kube-apiserver
     namespace: kube-system
   spec:
     containers:
     - command:
       - kube-apiserver
       ...
       - --encryption-provider-config=/etc/kubernetes/enc/enc.yaml  # add this line
       volumeMounts:
       ...
       - name: enc                           # add this line
         mountPath: /etc/kubernetes/enc      # add this line
         readOnly: true                      # add this line
       ...
     volumes:
     ...
     - name: enc                             # add this line
       hostPath:                             # add this line
         path: /etc/kubernetes/enc           # add this line
         type: DirectoryOrCreate             # add this line
     ...
   

3. 重启你的 API 服务器。

你现在为一个控制平面主机启用了加密。典型的 Kubernetes 集群有多个控制平面主机，因此还有更多工作要做。

重新配置其他控制平面主机

如果你的集群中有多个 API 服务器，则应依次将更改部署到每个 API 服务器。

当您计划更新集群的加密配置时，请规划好，以便控制平面中的 API 服务器始终能够解密存储的数据（即使在滚动部署更改的过程中）。

请确保在每个控制平面主机上使用**相同**的加密配置。

验证新写入的数据是否已加密

数据在写入 etcd 时被加密。重启 kube-apiserver 后，任何新创建或更新的 Secret（或其他在 EncryptionConfiguration 中配置的资源类型）在存储时都应被加密。

要检查这一点，您可以使用 etcdctl 命令行程序来检索您的 Secret 数据的内容。

此示例演示如何检查 Secret API 的加密情况。

1. 在 default 命名空间中创建一个名为 secret1 的新 Secret

   kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
   

2. 使用 etcdctl 命令行工具，从 etcd 中读取该 Secret

   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
   

   其中 [...] 必须是连接到 etcd 服务器的附加参数。

   例如

   ETCDCTL_API=3 etcdctl \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt   \
      --cert=/etc/kubernetes/pki/etcd/server.crt \
      --key=/etc/kubernetes/pki/etcd/server.key  \
      get /registry/secrets/default/secret1 | hexdump -C
   

   输出类似于这样（已缩写）

   00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
   00000010  73 2f 64 65 66 61 75 6c  74 2f 73 65 63 72 65 74  |s/default/secret|
   00000020  31 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |1.k8s:enc:aescbc|
   00000030  3a 76 31 3a 6b 65 79 31  3a c7 6c e7 d3 09 bc 06  |:v1:key1:.l.....|
   00000040  25 51 91 e4 e0 6c e5 b1  4d 7a 8b 3d b9 c2 7c 6e  |%Q...l..Mz.=..|n|
   00000050  b4 79 df 05 28 ae 0d 8e  5f 35 13 2c c0 18 99 3e  |.y..(..._5.,...>|
   [...]
   00000110  23 3a 0d fc 28 ca 48 2d  6b 2d 46 cc 72 0b 70 4c  |#:..(.H-k-F.r.pL|
   00000120  a5 fc 35 43 12 4e 60 ef  bf 6f fe cf df 0b ad 1f  |..5C.N`..o......|
   00000130  82 c4 88 53 02 da 3e 66  ff 0a                    |...S..>f..|
   0000013a
   

3. 验证存储的 Secret 是否以 k8s:enc:aescbc:v1: 为前缀，这表明 aescbc 提供程序已加密生成的数据。确认 etcd 中显示的密钥名称与上面提到的 EncryptionConfiguration 中指定的密钥名称匹配。在此示例中，您可以看到在 etcd 和 EncryptionConfiguration 中都使用了名为 key1 的加密密钥。

4. 验证通过 API 检索时，Secret 是否被正确解密

   kubectl get secret secret1 -n default -o yaml
   

   输出应包含 mykey: bXlkYXRh，其中 mydata 的内容使用 base64 编码；请阅读解码 Secret 以了解如何完全解码 Secret。

确保所有相关数据都已加密

仅确保新对象被加密通常是不够的：您还需要将加密应用于已存储的对象。

在此示例中，您已配置您的集群，以便在写入时加密 Secret。对每个 Secret 执行替换操作将在静态时加密该内容，其中对象保持不变。

您可以在集群中的所有 Secret 中进行此更改

# Run this as an administrator that can read and write all Secrets
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

上面的命令读取所有 Secret，然后使用相同的数据更新它们，以便应用服务器端加密。

防止以纯文本方式检索

如果您想确保仅使用加密来访问特定的 API 类型，您可以删除 API 服务器以纯文本方式读取该 API 后端数据的能力。

一旦集群中的所有 Secret 都被加密，您就可以删除加密配置的 identity 部分。例如

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE 64 ENCODED SECRET>
      - identity: {} # REMOVE THIS LINE

...然后依次重启每个 API 服务器。此更改会阻止 API 服务器即使在意外情况下也访问纯文本的 Secret。

轮换解密密钥

在不中断运行的情况下更改 Kubernetes 的加密密钥需要一个多步骤操作，尤其是在运行多个 kube-apiserver 进程的高可用性部署中。

1. 生成一个新密钥，并将其作为所有控制平面节点上当前提供程序的第二个密钥条目添加。
2. 重启**所有** kube-apiserver 进程，以确保每个服务器都可以解密使用新密钥加密的任何数据。
3. 对新加密密钥进行安全备份。如果您丢失了该密钥的所有副本，则需要删除在该丢失密钥下加密的所有资源，并且在静态加密被破坏期间，工作负载可能无法按预期运行。
4. 将新密钥作为 keys 数组中的第一个条目，以便它用于新写入的静态加密
5. 重启所有 kube-apiserver 进程，以确保每个控制平面主机现在都使用新密钥进行加密
6. 作为特权用户，运行 kubectl get secrets --all-namespaces -o json | kubectl replace -f - 以使用新密钥加密所有现有的 Secret
7. 在将所有现有 Secret 更新为使用新密钥并对新密钥进行安全备份后，从配置中删除旧的解密密钥。

解密所有数据

此示例演示如何停止静态加密 Secret API。如果您正在加密其他 API 类型，请调整步骤以匹配。

要禁用静态加密，请将 identity 提供程序作为加密配置文件的第一个条目

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      # list any other resources here that you previously were
      # encrypting at rest
    providers:
      - identity: {} # add this line
      - aescbc:
          keys:
            - name: key1
              secret: <BASE 64 ENCODED SECRET> # keep this in place
                                               # make sure it comes after "identity"

然后运行以下命令以强制解密所有 Secret

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

一旦您将所有现有的加密资源替换为不使用加密的后端数据，就可以从 kube-apiserver 中删除加密设置。

配置自动重载

您可以配置加密提供程序配置的自动重载。该设置确定 API 服务器应该仅在启动时加载您为 --encryption-provider-config 指定的文件，还是在您更改该文件时自动加载。启用此选项允许您在不重启 API 服务器的情况下更改静态加密的密钥。

要允许自动重载，请配置 API 服务器以使用以下参数运行：--encryption-provider-config-automatic-reload=true。启用后，会每分钟轮询文件更改以观察修改。apiserver_encryption_config_controller_automatic_reload_last_timestamp_seconds 指标标识新配置何时生效。这允许在不重启 API 服务器的情况下轮换加密密钥。

下一步

• 阅读有关解密已静态存储的数据的信息
• 了解有关 EncryptionConfiguration 配置 API (v1) 的更多信息。