加密静态敏感数据

Kubernetes 中所有允许你编写持久性 API 资源数据的 API 都支持静态加密（at-rest encryption）。例如，你可以为Secret启用静态加密。这种静态加密是 etcd 集群或运行 kube-apiserver 的主机文件系统上任何系统级加密之外的额外保护。

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

准备工作

  • 你需要拥有一个 Kubernetes 集群，并且 kubectl 命令行工具已被配置为与你的集群通信。建议在至少有两个非控制平面主机节点的集群上运行本教程。如果你还没有集群，可以使用minikube创建一个，或者使用这些 Kubernetes 演练场中的一个

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

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

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

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

要检查版本，输入 kubectl version。

确定静态加密是否已启用

默认情况下，API 服务器将资源的明文表示形式存储到 etcd 中，不进行静态加密。

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

如果你在带有 --encryption-provider-config 命令行参数的情况下运行 kube-apiserver，并且其引用的文件将 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 中添加一个新的靠前的条目，后跟将 identity 作为提供者的 providers 数组项。更具体的条目必须出现在通配符 '*.*' 条目之前。

新条目看起来类似于

  ...
  - 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 的数据配置静态加密之前，你需要选择要使用的提供者。

下表描述了每个可用提供者。

Kubernetes 静态加密提供者
名称加密方式强度速度密钥长度
identity无不适用不适用不适用
资源原样写入，不加密。当设置为首个提供者时，新值写入时资源将被解密。现有加密资源**不会**自动被明文数据覆盖。identity如果你未另外指定，则 identity 提供者是默认提供者。
aescbc带 PKCS#7 填充的 AES-CBC弱快16、24 或 32 字节
不推荐，因为 CBC 容易受到填充预言攻击。密钥材料可从控制平面主机访问。
aesgcm带随机 nonce 的 AES-GCM必须每写入 20 万次轮换一次最快16、24 或 32 字节
不推荐使用，除非实现了自动密钥轮换方案。密钥材料可从控制平面主机访问。
kmsv1 *(自 Kubernetes v1.28 起已弃用)*对每个资源使用带 DEK 的信封加密方案。最强慢 (*与 kms 版本 2 相比*)32 字节
数据由数据加密密钥（DEK）使用 AES-GCM 加密；DEK 根据密钥管理服务（KMS）中的配置由密钥加密密钥（KEK）加密。简单的密钥轮换，每次加密生成新的 DEK，KEK 轮换由用户控制。
阅读如何配置 KMS V1 提供者。
kmsv2对每个 API 服务器使用带 DEK 的信封加密方案。最强快32 字节
数据由数据加密密钥（DEK）使用 AES-GCM 加密；DEK 根据密钥管理服务（KMS）中的配置由密钥加密密钥（KEK）加密。Kubernetes 根据秘密种子为每次加密生成新的 DEK。种子在 KEK 轮换时进行轮换。
如果使用第三方工具进行密钥管理，这是一个不错的选择。自 Kubernetes v1.29 起稳定可用。
阅读如何配置 KMS V2 提供者。
secretboxXSalsa20 和 Poly1305强更快32 字节
使用了相对较新的加密技术，在需要高度审查的环境中可能不被接受。密钥材料可从控制平面主机访问。

如果你未另外指定，则 identity 提供者是默认提供者。**identity 提供者不会加密存储的数据，并且不提供任何额外的机密性保护。**

密钥存储

本地密钥存储

使用本地管理的密钥加密敏感数据可以防范 etcd 被入侵，但无法防范主机被入侵。

由于加密密钥存储在主机上的 EncryptionConfiguration YAML 文件中，熟练的攻击者可以访问该文件并提取加密密钥。

托管（KMS）密钥存储

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

使用信封加密会依赖于密钥加密密钥，该密钥不存储在 Kubernetes 中。在 KMS 的情况下，想要未经授权访问明文值的攻击者需要同时入侵 etcd **和**第三方 KMS 提供者。

加密密钥的保护

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

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

加密你的数据

生成加密密钥

要了解如何使用 KMS 设置静态加密，请参阅使用 KMS 提供者进行数据加密。你使用的 KMS 提供者插件可能还会附带额外的特定文档。

Windows

head -c 32 /dev/urandom | base64

生成一个 32 字节的随机密钥并进行 base64 编码。你可以使用此命令

Windows

head -c 32 /dev/urandom | base64

Windows

# 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 加密。

加密配置文件可能包含可以解密 etcd 中内容的密钥。如果配置文件包含任何密钥材料，你必须在所有控制平面主机上正确限制权限，以便只有运行 kube-apiserver 的用户才能读取此配置。

---
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），请参阅生成加密密钥。

使用新的加密配置文件

  1. 你需要将新的加密配置文件挂载到 kube-apiserver 静态 Pod。以下是一个示例说明如何实现

  2. 将新的加密配置文件保存到控制平面节点的 /etc/kubernetes/enc/enc.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. 编辑 kube-apiserver 静态 Pod 的清单文件：/etc/kubernetes/manifests/kube-apiserver.yaml，使其类似于

你的配置文件包含可以解密 etcd 中内容的密钥，因此你必须在控制平面节点上正确限制权限，以便只有运行 kube-apiserver 的用户才能读取它。

你现在已经为**一个**控制平面主机配置了加密。典型的 Kubernetes 集群有多个控制平面主机，所以还有更多工作要做。

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

如果控制平面节点之间的加密提供者配置存在差异，这种差异可能意味着 kube-apiserver 无法解密数据。

当你计划更新集群的加密配置时，请这样规划：确保控制平面中的 API 服务器始终能够解密存储的数据（即使在滚动部署更改的过程中也是如此）。

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

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

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

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

  1. 此示例展示了如何检查 Secret API 的加密情况。

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

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

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

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

    其中 [...] 必须是连接到 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. 输出类似于此（已缩写）

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

    kubectl get secret secret1 -n default -o yaml

    验证通过 API 检索时 Secret 是否正确解密

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

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

通常仅仅确保新对象被加密是不够的：你还希望该加密也适用于已经存储的对象。

对于此示例，你已将集群配置为在写入时加密 Secret。对每个 Secret 执行 replace 操作将在静态状态下加密其内容，即使对象本身没有改变。

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

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

对于较大的集群，你可能希望按命名空间细分 Secret，或编写脚本进行更新。

阻止明文检索

当你已为某个 API（例如：API 类型 Secret，表示核心 API 组中的 secrets 资源）配置了静态加密时，你**必须**确保此集群中的所有此类资源确实已静态加密。在继续执行后续步骤之前检查此项。

---
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

集群中的所有 Secret 都加密后，你可以移除加密配置中的 identity 部分。例如

……然后依次重启每个 API 服务器。此更改可防止 API 服务器访问明文 Secret，即使是意外访问。

轮换解密密钥

  1. 在 Kubernetes 中更改加密密钥而不导致停机需要多步操作，尤其是在有多个 kube-apiserver 进程运行的高可用部署中。
  2. 生成新密钥并将其作为当前提供者的第二个密钥条目添加到所有控制平面节点上。
  3. 重启**所有** kube-apiserver 进程，以确保每个服务器都能解密使用新密钥加密的任何数据。
  4. 安全备份新加密密钥。如果你丢失了此密钥的所有副本，则需要删除使用丢失密钥加密的所有资源，并且在静态加密中断期间，工作负载可能无法按预期运行。
  5. 将新密钥设置为 keys 数组中的第一个条目，以便用于新写入操作的静态加密
  6. 重启所有 kube-apiserver 进程，确保每个控制平面主机现在都使用新密钥进行加密
  7. 作为特权用户，运行 kubectl get secrets --all-namespaces -o json | kubectl replace -f - 以使用新密钥加密所有现有 Secret

更新所有现有 Secret 以使用新密钥并安全备份新密钥后，从配置中移除旧解密密钥。

解密所有数据

此示例展示了如何停止对 Secret API 进行静态加密。如果你正在加密其他 API 类型，请相应调整步骤。

---
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"

要禁用静态加密，请将 identity 提供者作为第一个条目放入你的加密配置文件中

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

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

将所有现有加密资源替换为不使用加密的后备数据后，可以从 kube-apiserver 中移除加密设置。

配置自动重载

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

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

感谢你的反馈。如果你有一个关于如何使用 Kubernetes 的具体、可回答的问题，请到Stack Overflow提问。如果你想或，请在GitHub 仓库中打开一个 Issue。