使用 AWS Secrets Manager 根金鑰管理系統的伺服器端物件加密

MinIO 伺服器端加密 (SSE) 會在寫入操作中保護物件，讓用戶端能夠利用伺服器處理能力來保護儲存層的物件（靜態加密）。SSE 還為安全鎖定和清除的法規和合規要求提供金鑰功能。

MinIO SSE 使用金鑰加密服務 (KES) 和外部根金鑰管理服務 (KMS)，以大規模執行安全的加密操作。根 KMS 提供外部金鑰 (EK) 的有狀態且安全儲存，而 KES 則是無狀態的，並從根管理的 EK 衍生其他加密金鑰。

此程序假設單一主機執行 MinIO 和 KES 容器，並以 AWS Secrets Manager 作為外部根 KMS。在此程序中，您將

部署一個 KES 容器，該容器已設定為使用 AWS Secrets Manager 作為根 KMS。
在 Vault 上建立新的 EK，以用於 SSE。
在單節點單磁碟模式中部署 MinIO 伺服器容器，該容器已設定為使用 KES 容器來支援 SSE。
設定自動儲存桶預設 SSE-KMS。

對於生產協調環境，請使用 MinIO Kubernetes Operator 部署一個已啟用 SSE 並設定為與 AWS 金鑰管理服務一起使用的租戶。

對於生產裸機環境，請參閱 MinIO on Linux 文件，以取得有關設定 MinIO 與 KES 和 AWS 金鑰管理服務的教學課程。

重要事項

在 MinIO 部署上啟用 SSE 會使用預設加密金鑰自動加密該部署的後端資料。

MinIO 需要存取 KES 和根 KMS 才能解密後端並正常啟動。您無法稍後停用 KES，也無法在稍後「還原」SSE 設定。

先決條件

確保存取 AWS Secrets Manager 和金鑰管理服務

此程序假設已存取並熟悉 AWS Secrets Manager 和 AWS 金鑰管理服務。

MinIO 特別需要以下 AWS 設定或組態

具有對應存取金鑰和私密金鑰的新 AWS 程式設計存取使用者。

授予所建立使用者存取 AWS Secrets Manager 和 AWS 金鑰管理服務的原則。以下原則授予最低限度的必要權限

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "minioSecretsManagerAccess",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:GetSecretValue",
        "secretsmanager:ListSecrets"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Sid": "minioKmsAccess",
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:Encrypt"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWS 提供 SecretsManagerReadWrite 和 AWSKeyManagementServicePowerUser 標準角色，這些角色符合並超過最低限度的必要權限。

安裝 Podman 或類似的容器管理介面

本程序假設您已安裝並設定好可於「Rootfull」模式下運作的 Podman。

「Rootless」模式可能無法提供足夠的權限，以必要的安全設定執行 KES。請參閱相關的「rootless」文件，以取得更多資訊。

(Podman) 使用 AWS Secrets Manager 部署具備伺服器端加密的 MinIO 和 KES

開始這些步驟之前，請先建立下列資料夾

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

對於 Windows 主機，請將路徑替換為 Windows 樣式的路徑，例如 C:\minio-kes-vault\。

1) 為 KES 和 MinIO 產生 TLS 憑證

以下命令會建立兩個 TLS 憑證，其有效期為建立後 30 天內

一個用於 KES 的 TLS 憑證，以保護其與 AWS Secrets Manager 服務之間的通訊安全。
一個用於 MinIO 的 TLS 憑證，以執行與 KES 的 mTLS 驗證。

在生產環境中謹慎使用

請勿在任何長期開發或生產環境中使用此程序中產生的 TLS 憑證。

請遵循組織/產業在 TLS 憑證產生和管理方面的最佳實務。建立有效憑證（例如，格式正確、最新且受信任）的完整指南超出本程序的範圍。

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

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

                             # In production environments, each client connecting to KES must
                             # Have their TLS hash listed under at least one `policy`.

# Specify the connection information for the KMS and Secrets Manager endpoint.
# The endpoint should be resolvable from the host.
# This example assumes that the associated AWS account has the necessary
# access key and secret key
keystore:
  aws:
    secretsmanager:
      endpoint: secretsmanager.REGION.amazonaws.com # use the Secrets Manager endpoint for your region
      region: REGION # e.g. us-east-1
      kmskey: "" # Optional. The root AWS KMS key to use for cryptographic operations. Formerly described as the "Customer Master Key".
      credentials:
        accesskey: "AWSACCESSKEY" # AWS Access Key
        secretkey: "AWSSECRETKEY" # AWS Secret Key

將 MINIO_IDENTITY_HASH 設定為 MinIO mTLS 憑證的身分雜湊值。

以下命令會計算必要的雜湊值

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

將 MINIO_IDENTITY_HASH 設定為 MinIO mTLS 憑證的身分雜湊值。

以下命令會計算必要的雜湊值

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

將 REGION 替換為 AWS Secrets Manager 的適當區域。 endpoint 和 region 的值必須相符。
將 AWSACCESSKEY 和 AWSSECRETKEY 設定為適當的AWS 憑證。

建立 MinIO 環境檔

使用您偏好的文字編輯器建立環境檔。以下範例使用 nano
```
nano ~/minio-kes-aws/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 伺服器容器，設定為使用 AWS Secrets Manager 作為根KMS。
一個在單節點單磁碟機模式下運行的 MinIO 伺服器容器。

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

sudo podman run -dt  \
  --cap-add IPC_LOCK  \
  --name kes-server  \
  --pod "minio-kes-aws"  \
  -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-aws"  \
  -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 需要根 KMS 上已存在 EK，才能使用該金鑰執行 SSE 操作。請使用 kes key create 或 mc admin kms key create 建立新的 EK 以用於 SSE。

以下命令使用 kes key create 命令來新增儲存在根 KMS 伺服器上的新外部金鑰 (EK)，以用於加密 MinIO 後端。

sudo podman run --rm  \
  -v ~/minio-kes-aws/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，以確認相關聯的加密中繼資料。

AWS 根 KMS 的設定參考

以下章節說明使用 AWS Secrets Manager 和 AWS 金鑰管理系統作為 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:
  secretsmanager:
    endpoint: secretsmanager.REGION.amazonaws
    region: REGION
    kmskey: ""
    credentials:
      accesskey: "${AWS_ACCESS_KEY}"
      secretkey: "${AWS_SECRET_KEY}"

參考

金鑰	描述
`位址`	KES 伺服器啟動時監聽的網路位址和埠號。預設為所有主機網路介面上的埠號 `7373`。
`根使用者`	KES 超級使用者（`root`）的身分。使用 TLS 憑證連線的用戶端，其憑證雜湊值（`kes identity of client.cert`）與此值相符，即可存取所有 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.aws.secretsmanager`	AWS Secrets Manager 和 AWS KMS 的配置。 `endpoint` - Secrets Manager 服務的端點，包括區域。 `approle` - 用於其他 AWS 服務的 AWS 區域。 `kmskey` - 用於加密操作的根 KMS 金鑰。以前稱為客戶主金鑰。 `credentials` - 用於針對 Secrets Manager 和 KMS 執行驗證操作的 AWS 憑證。指定的憑證必須具有適當的權限