使用 Azure Key Vault 根 KMS 的服务器端对象加密

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

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

此过程假设单个主机运行 MinIO 和 KES 容器，并使用 Azure Key Vault 作为外部根 KMS。在此过程的一部分中，您将

部署一个 KES 容器，该容器配置为使用 Azure Key Vault 作为根 KMS。
在 Vault 上创建一个新的 EK，用于与 SSE 配合使用。
在单节点单驱动器模式中部署 MinIO 服务器容器，该容器配置为使用 KES 容器来支持 SSE。
配置自动桶默认 SSE-KMS。

对于生产编排环境，使用 MinIO Kubernetes 运算符部署具有启用 SSE 的租户，并配置为与 Azure Key Vault 配合使用。

对于生产裸机环境，请参阅 MinIO 在 Linux 上的文档，了解有关使用 KES 和 Azure Key Vault 配置 MinIO 的教程。

重要

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

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

先决条件

Azure Key Vault

此过程假定您熟悉 Azure Key Vault。 Key Vault 快速入门为此过程提供了足够的基础。

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

注册应用程序用于 KES（例如 minio-kes）。请注意应用程序（客户端）ID、目录（租户）ID 和客户端凭据。您可能需要创建客户端凭据密钥并复制密钥值以用于此过程。
创建一个访问策略供 KES 使用。此策略**必须**具有以下密钥权限
- 获取
- 列出
- 设置
- 删除
- 清除
将新策略的主体设置为 KES 应用程序 ID。

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

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

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

(Podman) 使用 Azure Key Vault 部署具有服务器端加密的 MinIO 和 KES

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

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

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

1) 为 KES 和 MinIO 生成 TLS 证书

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

KES 的 TLS 证书，用于保护它与 Azure Key Vault 服务之间的通信。
MinIO 的 TLS 证书，用于执行对 KES 的 mTLS 身份验证。

在生产环境中谨慎使用

**不要**使用此过程生成的 TLS 证书用于任何长期开发或生产环境。

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

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

podman run --rm  \
  -v ~/minio-kes-azure/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-azure/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

2) 创建 KES 和 MinIO 配置

创建 KES 配置文件

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

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

KES 使用 YAML 格式的配置文件。以下 YAML 示例指定使用 AWS Secrets Manager 启用 SSE 的最小必需字段

address: 0.0.0.0:7373

# Disable the root identity, as we do not need that level of access for
# supporting SSE operations.
root: 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

# Create a policy named 'minio' that grants access to the
# /create, /generate, and /decrypt KES APIs for any key name
# KES uses mTLS to grant access to this policy, where only the client
# whose TLS certificate hash matches one of the "identities" can
# use this policy. Specify the hash of the MinIO server TLS certificate
# hash here.
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_IDENTITY_HASH} # Replace with the output of 'kes identity of minio-kes.cert'

# Specify the connection information for the Key Vualt endpoint.
# The endpoint should be resolvable from the host.
# This example assumes that the specified Key Vault and Azure tenant/client
# have the necessary permissions set.

keystore:
  azure:
    keyvault:
      endpoint: "https://<keyvaultinstance>vault.azure.net" # The Azure Keyvault Instance Endpoint
      credentials:
        tenant_id: "${TENANTID}" # The directory/tenant UUID
        client_id: "${CLIENTID}" # The application/client UUID
        client_secret: "${CLIENTSECRET}" # The Active Directory secret for the application

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

以下命令计算必要的哈希

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

将 endpoint 替换为 Keyvault 实例的 URL。
将 TENANTID、CLIENTID 和 CLIENTSECRET 设置为与具有所需权限的项目用户的凭据匹配。

创建 MinIO 环境文件

使用您喜欢的文本编辑器创建环境文件。以下示例使用 nano
```
nano ~/minio-kes-azure/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、配置等）。
- 使用 SSE-KMS 加密对象，如果请求未包含特定 EK。
- 使用 SSE-S3 加密对象。
MinIO 使用 MINIO_KMS_KES_ENCLAVE 密钥来定义要使用的 KES enclave 的名称。
- 将 <name> 替换为要使用的 enclave 的名称。
- 如果未定义，MinIO 不会发送任何 enclave 信息。这可能导致使用有状态 KES 服务器的默认 enclave。
  
  KES enclave 将其关联的密钥与有状态 KES 服务器上的其他 enclave 隔离。
仅 minio-kes 证书允许在 MinIO 部署和 KES 服务器之间进行 mTLS。它们不会以其他方式为其他客户端连接到 MinIO 启用 TLS。

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

3) 创建 Pod 和容器

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

一个 Podman Pod，用于促进容器通信
一个 KES 服务器容器，配置为使用 Azure Key Vault 作为根 KMS。
一个 MinIO 服务器容器，在单节点单驱动器模式下运行。

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

sudo podman run -dt  \
  --cap-add IPC_LOCK  \
  --name kes-server  \
  --pod "minio-kes-azure"  \
  -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-azure"  \
  -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 存在于根 KMS 上，然后才能使用该密钥执行使用 SSE 的操作。使用 kes key create 或 mc admin kms key create 创建一个新的 EK，供 SSE 使用。

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

sudo podman run --rm  \
  -v ~/minio-kes-azure/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，以确认关联的加密元数据。

Azure Key Vault 根 KMS 的配置参考

以下部分描述了使用 Azure Key Vault 作为 SSE 的根密钥管理服务 (KMS) 的每个密钥加密服务 (KES) 配置设置。

重要

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

YAML 概述

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

此 YAML 假设 MinIO 部署访问 KES 的最小权限集。或者，您可以省略 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:
  azure:
    keyvault:
      endpoint: "https://<keyvaultinstance>.vault.azure.net"
      credentials:
        tenant_id: "${TENANTID}" # The directory/tenant UUID
        client_id: "${CLIENTID}" # The application/client UUID
        client_secret: "${CLIENTSECRET}" # The Active Directory secret for the application

参考

键	描述
`地址`	KES 服务器启动时监听的网络地址和端口。默认情况下，所有主机网络接口上的端口为 `7373`。
`根`	KES 超级用户 (`root`) 身份。使用其哈希值 (`kes identity of client.cert`) 与此值匹配的 TLS 证书连接的客户端可以访问所有 KES API 操作。指定 `disabled` 以删除根身份，并仅依赖于 `policy` 配置来控制 KES 的身份和访问管理。
`tls`	KES 用于建立 TLS 安全通信的 TLS 私钥和证书。分别为私钥 `.key` 和公钥 `.cert` 指定完整路径到 `key` 和 `cert` 字段。
`策略`	指定一个或多个策略来控制对 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>` 策略相关联。
`密钥`	指定一个密钥数组，这些密钥必须存在于根 KMS 上，以便 KES 成功启动。如果密钥不存在，KES 会尝试创建密钥，如果创建任何密钥失败，则会退出并显示错误。在完成对所有指定密钥的验证之前，KES 不会接受任何客户端请求。
`keystore.azure.keyvault`	Azure Key Vault 的配置 `endpoint` - Key Vault 服务的主机名。 `credentials` - 将 `credentials` 替换为 Active Directory 应用程序的凭据，KES 以该应用程序的身份进行身份验证。指定的凭据必须具有适当的权限