使用 GCP Secret Manager 根 KMS 进行服务器端对象加密

MinIO 服务器端加密 (SSE) 在写入操作过程中保护对象，允许客户端利用服务器处理能力在存储层（静态加密）保护对象。SSE 还为围绕安全锁定和擦除的监管和合规性要求提供关键功能。

MinIO SSE 使用密钥加密服务 (KES) 和外部根密钥管理服务 (KMS) 来大规模执行安全的加密操作。根 KMS 提供外部密钥 (EK) 的有状态和安全存储，而 KES 是无状态的，并从根管理的 EK 派生其他加密密钥。

此过程假设一台运行 MinIO 和 KES 容器的单主机。在此过程中，您将

部署一个配置为使用 GCP Secret Manager 作为根 KMS 的 KES 容器。
在 Vault 上创建一个新的 EK，用于 SSE。
以单节点单驱动器模式部署 MinIO 服务器容器，并配置为使用 KES 容器支持 SSE。
配置自动存储桶默认 SSE-KMS。

对于生产编排环境，请使用 MinIO Kubernetes 运算符部署启用了 SSE 并配置为使用 GCP Secret Manager 的租户。

对于生产裸机环境，请参阅 Linux 上的 MinIO 文档，了解有关将 MinIO 与 KES 和 GCP Secret Manager 配置在一起的教程。

重要

在 MinIO 部署上启用 SSE 会自动使用默认加密密钥加密该部署的后端数据。

MinIO *需要* 访问 KES *和* 根 KMS 才能解密后端并正常启动。您以后无法禁用 KES 或“撤消”SSE 配置。

先决条件

GCP Secret Manager

此过程假定您熟悉 GCP Secret Manager。 Secret Manager 快速入门为此过程提供了足够的基础。

MinIO 特别需要以下 GCP 设置或配置

在项目中启用 Secret Manager。
创建一个新的 GCP 服务帐号以支持 KES。确保用户具有至少具有以下权限的角色
```
secretmanager.secrets.create
secretmanager.secrets.delete
secretmanager.secrets.get
```
Secret manager Admin 角色满足最低所需的权限。

GCP 应返回一组与新访问密钥关联的凭据，包括私钥。将这些凭据复制到安全的位置，以供此过程使用。

安装 Podman 或类似的容器管理接口

此过程假设您已安装并配置了可正常工作的 Podman，并以“Rootfull”模式运行。

“Rootless”模式可能无法提供足够的权限来以必要的安全设置运行 KES。有关更多信息，请参阅相关的 “rootless” 文档。

(Podman) 使用 GCP Secrets Manager 部署支持服务器端加密的 MinIO 和 KES

在开始这些步骤之前，请创建以下文件夹

mkdir -P ~/minio-kes-gcp/certs
mkdir -P ~/minio-kes-gcp/config
mkdir -P ~/minio-kes-gcp/minio

对于 Windows 主机，请使用 Windows 样式路径替换路径，例如 C:\minio-kes-vault\。

1) 为 KES 和 MinIO 生成 TLS 证书

以下命令创建两个在创建后 30 天内过期的 TLS 证书

用于 KES 的 TLS 证书，以确保它与Google Cloud Platform 密钥管理器服务之间的通信安全。
用于 MinIO 的 TLS 证书，以对 KES 执行 mTLS 身份验证。

在生产环境中谨慎使用

**不要**将作为此过程的一部分生成的 TLS 证书用于任何长期开发或生产环境。

遵循组织/行业关于 TLS 证书生成和管理的最佳实践。创建有效证书（例如，格式正确、最新且可信）的完整指南超出了此过程的范围。

# These commands output keys to ~/minio-kes-gcp/certs and ~/minio-kes-gcp/certs on the host operating system

podman run --rm  \
  -v ~/minio-kes-gcp/certs:/certs  \
  quay.io/minio/kes:2024-01-11T13-09-29Z identity new  kes_server \
    --key  /certs/kes-server.key  \
    --cert /certs/kes-server.cert  \
    kes-server

podman run --rm  \
  -v ~/minio-kes-gcp/certs:/certs  \
  quay.io/minio/kes:2024-01-11T13-09-29Z identity new minio_server \
    --key  /certs/minio-kes.key  \
    --cert /certs/minio-kes.cert  \
    minio-server

根据您的 Vault 配置，您可能需要将kes-server.cert作为受信任的证书颁发机构传递。有关更多信息，请参阅Hashicorp Vault 配置文档。请参阅客户端文档以获取有关信任第三方 CA 的说明。

2) 创建 KES 和 MinIO 配置

创建 KES 配置文件

使用您喜欢的文本编辑器创建配置文件。以下示例使用nano

nano ~/minio-kes-gcp/config/kes-config.yaml

KES 使用 YAML 格式的配置文件。以下 YAML 提供了使用 Hashicorp Vault 作为根KMS所需的最小字段。您必须修改此 YAML 以反映您的部署环境。

address: 0.0.0.0:7373

# Disable the root administrator identity, as we do not need that level of access for
# supporting SSE operations.
admin:
  identity: disabled

# Specify the TLS keys generated in the previous step here
# For production environments, use keys signed by a known and trusted Certificate Authority (CA).
tls:
  key:  /certs/kes-server.key
  cert: /certs/kes-server.cert

  # Specify the path to CAs used by KES for validating client certificates
  # This can alternatively be a single CA
  # KES uses these CAs in addition to the system trust store for validating client certificates.

  ca: /certs/CAs/

# Sets access policies for KES
# The `minio` policy grants access to the listed APIs.
policy:
  minio:
    allow:
    - /v1/key/create/*   # You can replace these wildcard '*' with a string prefix to restrict key names
    - /v1/key/generate/* # e.g. '/minio-'
    - /v1/key/decrypt/*
    - /v1/key/bulk/decrypt
    - /v1/key/list/*
    - /v1/status
    - /v1/metrics
    - /v1/log/audit
    - /v1/log/error
    identities:
    - MINIO_API_KEY_HASH # Replace with the hash output returned from kes identity new

# Specify the connection information for the Vault server.
# The endpoint should be resolvable from the host.
# This example assumes that Vault is configured with an AppRole ID and
# Secret for use with KES.
keystore:
  vault:
    endpoint: https://HOSTNAME:8200
    engine: "/path/to/engine" # Replace with the path to the K/V Engine
    version: "v1|v2" # Specify v1 or v2 depending on the version of the K/V Engine
    approle:
      id: "VAULTAPPID"     # Hashicorp Vault AppRole ID
      secret: "VAULTAPPSECRET" # Hashicorp Vault AppRole Secret ID
      retry: 15s
    status:
      ping: 10s
    # Required if Vault uses certificates signed by an unknown CA,
    # e.g. self-signed or internal (non-globally trusted).
    # Replace this value with the full path to the Vault CA certificate.
    tls:
      ca: vault-tls-CA.cert

将MINIO_IDENTITY_HASH设置为 MinIO mTLS 证书的身份哈希。

以下命令计算必要的哈希值

podman run --rm                                             \
   -v ~/minio-kes-gcp/certs/certs:/certs                                \
   kes:2024-01-11T13-09-29Z tool identity of /certs/minio-kes.cert

将vault.endpoint替换为 Vault 服务器的主机名。
将VAULTAPPID和VAULTAPPSECRET替换为相应的Vault AppRole 凭据。

创建 MinIO 环境文件

使用您喜欢的文本编辑器创建环境文件。以下示例使用nano
```
nano ~/minio-kes-gcp/config/minio
```
此命令假设minio-kes.cert、minio-kes.key和kes-server.cert证书可在指定位置访问
```
MINIO_ROOT_USER=myminioadmin
MINIO_ROOT_PASSWORD=minio-secret-key-change-me
MINIO_VOLUMES="/mnt/data"

# KES Configurations

MINIO_KMS_KES_ENDPOINT=https://127.0.0.1:7373
MINIO_KMS_KES_CERT_FILE=/certs/minio-kes.cert
MINIO_KMS_KES_KEY_FILE=/certs/minio-kes.key
MINIO_KMS_KES_CAPATH=/certs/server.cert
MINIO_KMS_KES_KEY_NAME=minio-backend-default-key
MINIO_KMS_KES_ENCLAVE=<name>
```
MinIO 使用MINIO_KMS_KES_KEY_NAME密钥进行以下加密操作
- 加密 MinIO 后端（IAM、配置等）。
- 如果请求不包含特定的EK，则使用SSE-KMS加密对象。
- 使用SSE-S3加密对象。
MinIO 使用MINIO_KMS_KES_ENCLAVE密钥来定义要使用的 KES 隔离区的名称。
- 将<name>替换为要使用的隔离区的名称。
- 如果未定义，MinIO 不会发送任何隔离区信息。这可能导致使用有状态 KES 服务器的默认隔离区。
  
  KES 隔离区将其关联的密钥与有状态 KES 服务器上的其他隔离区隔离开来。
minio-kes证书仅启用 MinIO 部署和 KES 服务器之间的 mTLS。它们不会以其他方式为其他客户端连接到 MinIO 启用 TLS。

如果根 KMS 上尚不存在此密钥，KES 会自动创建它。

3) 创建 Pod 和容器

本节中的命令创建以下资源

一个 Podman Pod，以促进容器之间的通信
一个用于 KES 服务器的容器，配置为使用Google Cloud Platform 密钥管理器作为根KMS。
一个用于 MinIO 服务器的容器，在单节点单驱动器模式下运行。

sudo podman pod create  \
  -p 9000:9000 -p 9001:9001 -p 7373:7373  \
  -v ~/minio-kes-gcp/certs:/certs  \
  -v ~/minio-kes-gcp/minio:/mnt/minio  \
  -v ~/minio-kes-gcp/config:/etc/default/  \
  -n minio-kes-gcp

sudo podman run -dt  \
  --cap-add IPC_LOCK  \
  --name kes-server  \
  --pod "minio-kes-gcp"  \
  -e KES_SERVER=https://127.0.0.1:7373  \
  -e KES_CLIENT_KEY=/certs/kes-server.key  \
  -e KES_CLIENT_CERT=/certs/kes-server.cert  \
  quay.io/minio/kes:2024-01-11T13-09-29Z server  \
    --auth  \
    --config=/etc/default/kes-config.yaml  \

sudo podman run -dt  \
  --name minio-server  \
  --pod "minio-kes-gcp"  \
  -e "MINIO_CONFIG_ENV_FILE=/etc/default/minio"  \
  quay.io/minio/minio:RELEASE.2024-02-17T01-15-57Z server  \
    --console-address ":9001"

您可以使用以下命令验证容器的状态

# Should show three pods - one for the Pod, one for KES, and one for MinIO
sudo podman container ls

如果所有 Pod 都处于运行状态，则可以通过在浏览器中打开http://127.0.0.1:9000并使用 MinIO 环境文件中指定的根凭据登录来连接到 MinIO 部署。

4) 生成新的加密密钥

在创建密钥之前解封 Vault

在创建新的加密密钥之前，必须先解封后备 Vault 实例。有关更多信息，请参阅 Vault 文档中的密封/解封。

MinIO 要求EK在使用该密钥执行SSE操作之前存在于根 KMS 上。使用kes key create或mc admin kms key create创建新的EK以用于SSE。

以下命令使用kes key create命令添加一个新的外部密钥（EK），该密钥存储在根 KMS 服务器上，用于加密 MinIO 后端。

sudo podman run --rm  \
  -v ~/minio-kes-gcp/certs:/certs  \
  -e KES_SERVER=https://127.0.0.1:7373  \
  -e KES_CLIENT_KEY=/certs/minio-kes.key  \
  -e KES_CLIENT_CERT=/certs/minio-kes.cert  \
  kes:2024-01-11T13-09-29Z key create -k my-new-encryption-key

您可以根据您的用例指定任何密钥名称，例如特定于存储桶的密钥minio-mydata-key。

5) 为存储桶启用 SSE-KMS

您可以使用 MinIO 控制台或 MinIO mc CLI 来使用生成的密钥启用存储桶默认的 SSE-KMS

MinIO 控制台

通过在您喜欢的浏览器中导航到http://127.0.0.1:9001并使用为 MinIO 容器指定的根凭据登录来打开 MinIO 控制台。

登录后，创建一个新的存储桶并根据您的喜好命名。选择齿轮图标以打开管理视图。

选择铅笔图标，位于“加密”字段旁边，以打开配置存储桶默认 SSE 方案的模态窗口。

选择SSE-KMS，然后输入上一步中创建的密钥的名称。

保存更改后，尝试将文件上传到存储桶。在对象浏览器中查看该文件时，请注意，在侧边栏中，元数据包含 SSE 加密方案和有关用于加密该对象密钥的信息。这表示对象已成功加密。

MinIO CLI

以下命令

为 MinIO 部署创建一个新的别名
创建一个用于存储加密数据的新的存储桶
在该存储桶上启用 SSE-KMS 加密

mc alias set local http://127.0.0.1:9000 ROOTUSER ROOTPASSWORD

mc mb local/encryptedbucket
mc encrypt set SSE-KMS encrypted-bucket-key ALIAS/encryptedbucket

使用mc cp或任何具有PutObject功能的与 S3 兼容的 SDK 将文件写入存储桶。然后，您可以对该文件运行mc stat以确认关联的加密元数据。

GCP 密钥管理器根 KMS 的配置参考

以下部分描述了每个密钥加密服务 (KES)配置设置，这些设置用于将 GCP Secrets Manager 用作SSE的根密钥管理服务 (KMS)

重要

从https://github.com/minio/minio/releases/tag/RELEASE.2023-02-17T17-52-43Z开始，MinIO 需要扩展的 KES 权限才能实现功能。本节中的示例配置包含所有必需的权限。

YAML 概述

带有${<STRING>}的字段使用与<STRING>值匹配的环境变量。您可以使用此功能设置凭据，而无需将其写入配置文件。

YAML 假设访问 KES 的 MinIO 部署具有最少的权限集。或者，您可以省略policy.minio-server部分，而是将${MINIO_IDENTITY}哈希设置为${ROOT_IDENTITY}。

address: 0.0.0.0:7373
root: ${ROOT_IDENTITY}

tls:
  key: kes-server.key
  cert: kes-server.cert

policy:
  minio-server:
    allow:
    - /v1/key/create/*
    - /v1/key/generate/*
    - /v1/key/decrypt/*
    - /v1/key/bulk/decrypt
    - /v1/key/list/*
    - /v1/status
    - /v1/metrics
    - /v1/log/audit
    - /v1/log/error
    identities:
    - ${MINIO_IDENTITY}

keys:
  - name: "minio-encryption-key-alpha"
  - name: "minio-encryption-key-baker"
  - name: "minio-encryption-key-charlie"

keystore:
  gcp:
    secretmanager:
      project_id: "${GCPPROJECTID}"
      credentials:
        client_email: "${GCPCLIENTEMAIL}"
        client_id: "${GCPCLIENTID}"
        private_key_id: "${GCPPRIVATEKEYID}"
        private_key: "${GCPPRIVATEKEY}"

参考

键	描述
`地址`	KES 服务器启动时监听的网络地址和端口。默认为所有主机网络接口上的端口 `7373`。
`root`	KES 超级用户 (`root`) 的身份。使用其哈希值 (`kes identity of client.cert`) 与此值匹配的 TLS 证书连接的客户端可以访问所有 KES API 操作。指定 `disabled` 以移除 root 身份，并仅依赖于 `policy` 配置来控制 KES 的身份和访问管理。
`tls`	KES 用于建立 TLS 安全通信的 TLS 私钥和证书。分别为私钥 `.key` 和公钥 `.cert` 指定完整路径到 `key` 和 `cert` 字段。
`policy`	指定一个或多个策略来控制对 KES 服务器的访问。 MinIO SSE 需要访问以下 KES 加密 API `/v1/key/create/` `/v1/key/generate/` `/v1/key/decrypt/` 指定其他密钥不会扩展 MinIO SSE 功能，并且可能会违反有关向客户端提供不必要的加密密钥操作访问权限的安全最佳实践。您可以通过在 `` 之前指定前缀来限制 MinIO 可以创建的密钥名称范围，作为执行 SSE 的一部分。例如，`minio-sse-*` 仅授予使用 `minio-sse-` 前缀创建、生成或解密密钥的访问权限。 KES 使用 mTLS 通过将 TLS 证书的哈希值与每个配置策略的 `identities` 进行比较来授权连接的客户端。使用 `kes identity of` 命令计算 MinIO mTLS 证书的身份，并将其添加到 `policy.<NAME>.identities` 数组中，以将 MinIO 与 `<NAME>` 策略关联。
`keys`	指定一个密钥数组，这些密钥必须存在于根 KMS 上，KES 才能成功启动。如果密钥不存在，KES 会尝试创建这些密钥，如果创建任何密钥失败，则会退出并显示错误。在完成所有指定密钥的验证之前，KES 不会接受任何客户端请求。
`keystore.gcp.secretmanager`	GCP Secret Manager 的配置 `project_id` - Secret Manager 实例的 GCP 项目。 `credentials` - 将 `credentials` 替换为具有所需权限的项目用户的凭据。