使用 KES 的服务器端对象加密

本程序假设您使用一台单一的主机机器来运行 MinIO 和 KES 容器。有关运行 KES 的说明，请参阅 KES 文档。

作为此过程的一部分，您将：

创建一个新的 EK 以用于 SSE。
在单节点单驱动器模式下部署一个MinIO服务器容器，并配置其使用 KES 容器来支持 SSE。
配置自动桶默认的 SSE-KMS。

对于生产环境的编排，请使用 MinIO Kubernetes Operator 来部署一个启用了 SSE 并配置为与您的 KMS 一起使用的租户。

对于生产裸机环境，请参阅 MinIO on Linux文档，了解如何配置 MinIO 与 KES 和您的 KMS 一起使用的教程。

对于生产环境的裸机系统，请参阅 MinIO on Linux documentation，了解如何使用 KES 和您的 KMS 配置 MinIO 的教程。

重要

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

MinIO 需要访问 KES 和外部 KMS 以解密后端并正常启动。 KMS 必须维护并提供对 MINIO_KMS_KES_KEY_NAME 的访问。

先决条件

确保 KES 访问支持的 KMS 目标

此过程假设现有 KES 安装连接到受支持的 KMS 可安装，均可从本地主机访问。请参考您所使用支持的关键管理系统目标的安装说明，以部署 KES 并将其连接到 KMS 解决方案。

KES Operations Require Unsealed Target

一些支持 KMS 目标允许您密封或解封保管库实例。如果配置 KMS，KES 将返回错误服务是密封的。

如果您重新启动或以其他方式密封您的保管库实例，KES 将无法针对该保管库执行任何加密操作。您必须开启保管库才能确保正常运行。

请参阅您选择的 KMS 解决方案的文档，以获取有关是否需要解封的更多信息。

请参考您选择的受支持 KMS 的 KES 文档中的配置说明。

安装 Podman 或类似的容器管理界面

本过程假定您已经配置好了可在 “Rootfull” 模式下运行的 Podman。

“Rootless” 模式可能不具备运行带有必要安全设置的KES所需的足够权限。有关更多信息，请参阅相关的 “rootless”文档。

使用服务器端加密部署 MinIO 和 KES

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

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

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

先决条件

根据您选择的 supported KMS target 配置，您可能需要将 kes-server.cert 作为可信 Certificate Authority (CA) 传递。请参考客户端文档中有关信任第三方 CA 的说明。

1) 创建 KES 和 MinIO 配置

创建 KES配置文件

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

nano ~/minio-kes-vault/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-vault/certs/certs:/certs                                \
   kes:2025-03-12T09-35-18Z tool identity of /certs/minio-kes.cert

请参考为您的支持的 KMS 解决方案设置 KES 的说明，以获取定义您选择的 KMS 目标特定的额外变量。

创建MinIO环境变量文件

Create the 环变变量配置文件 using your preferred text editor. 以下示例使用 nano ：
```
nano ~/minio-kes-vault/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_API_KEY=<API-key-identity-string-from-KES> # Replace with the key string for your credentials
MINIO_KMS_KES_CAPATH=/certs/server.cert
MINIO_KMS_KES_KEY_NAME=minio-backend-default-key
```
备注
- API 密钥是与 KES 服务器进行身份验证的首选方式，因为它提供了一个简化、安全的 KES 服务器身份验证过程。
- 或者，指定 MINIO_KMS_KES_KEY_FILE 和 MINIO_KMS_KES_CERT_FILE 而不是 MINIO_KMS_KES_API_KEY 。
  
  API 密钥与基于证书的身份验证相互排斥。指定 API 密钥变量或密钥文件和证书文件变量。
- 本网站的文档使用 API 密钥。
MinIO 使用 MINIO_KMS_KES_KEY_NAME 环境变量指定的密钥进行以下密码操作：
- 加密 MinIO 后端（IAM、配置等）
- 如果请求不包含特定的 EK ，则使用 SSE-KMS 加密对象。
- 使用 SSE-S3 加密对象。
minio-kes 证书仅允许 MinIO 部署与 KES 服务器之间进行 mTLS（多路传输层安全性）通信。

它们不会为 MinIO 的其他客户端连接启用 TLS（传输层安全性）。

如果根 KMS（密钥管理服务）上尚不存在此密钥，KES 会自动创建它。

2) 创建 Pod 和容器。

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

一个 Podman 容器 Pod，以促进容器间的通信。
一个配置有选择的受支持 KMS 解决方案的 KES 服务器容器。
一个运行在单节点单硬盘模式的 MinIO 服务器容器。

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

sudo podman run -dt  \
  --cap-add IPC_LOCK  \
  --name kes-server  \
  --pod "minio-kes-vault"  \
  -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:2025-03-12T09-35-18Z server  \
    --auth  \
    --config=/etc/default/kes-config.yaml  \

sudo podman run -dt  \
  --name minio-server  \
  --pod "minio-kes-vault"  \
  -e "MINIO_CONFIG_ENV_FILE=/etc/default/minio"  \
  quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z server  \
    --console-address ":9001"

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

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

如果所有 pod 都是运行状态（operational），您可以通过在浏览器中打开 http://127.0.0.1:9000 来连接到 MinIO 部署，并使用在 MinIO 环境变量配置文件中指定的根凭据登录。

3) 生成一个新的加密密钥

Unseal Vault Before Creating Key

如果您选择的提供商需要，您必须在创建新加密密钥之前解封后端 KMS 实例。有关更多信息，请参阅您选择的 KMS 解决方案的文档。

MinIO 要求在执行使用该密钥的 |SSE|（服务器端加密）操作之前，|EK|（加密密钥）必须存在于根 KMS（密钥管理服务）上。使用 :kes-docs:`kes key create <cli/kes-key/create/>` 命令或 :mc-cmd:`mc admin kms key create` 命令来创建一个新的 |EK| ，用于使用 SSE 。

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

sudo podman run --rm  \
  -v ~/minio-kes-vault/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:2025-03-12T09-35-18Z key create -k my-new-encryption-key

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

4) 为存储桶启用 SSE-KMS

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

MinIO控制台

通过在您喜欢的浏览器中输入 http://127.0.0.1:9001 并使用指定给 MinIO 容器的 root 凭据登录，打开 MinIO 控制台。

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

选择铅笔图标，位于 Encryption 加密字段旁边，以打开配置存储桶默认 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 以确认关联的加密元数据。

商业支持购买咨询