注意

本文档适用于 Ceph 开发版本。

HashiCorp Vault Integration 

HashiCorpVault可以用作安全的密钥管理服务服务器端加密(SSE-KMS).

下面的一些示例使用 Vault 命令行工具与 Vault 交互。您可能需要设置以下环境变量，使用您的 Vault 服务器的正确地址来使用此工具：

export VAULT_ADDR='https://vault-server-fqdn:8200'

Vault 密钥引擎 

Vault 提供多个密钥引擎，可以存储、生成和加密数据。目前，对象网关支持：

KV 密钥引擎版本 2
Transit 引擎

KV 密钥引擎

KV 密钥引擎用于在 Vault 中存储任意的键/值密钥。要在 Vault 中启用 KV 引擎版本 2，请使用以下命令：

vault secrets enable -path secret kv-v2

对象网关可以配置为使用 KV 引擎版本 2，使用以下设置：

rgw crypt vault secret engine = kv

Transit 密钥引擎

Transit 引擎处理传输中数据的加密功能。要在 Vault 中启用它，请使用以下命令：

vault secrets enable transit

对象网关可以配置为使用 Transit 引擎，使用以下设置：

rgw crypt vault secret engine = transit

Vault 身份验证 

Vault 支持多种身份验证机制。目前，对象网关可以配置为使用令牌身份验证方法 or a Vault 代理.

Vault 中的大多数令牌都有有限的生命周期和权限。只有一种 Vault 令牌没有生命周期，即 root 令牌。对于所有其他令牌，必须定期刷新它们，可以通过执行初始身份验证或更新令牌来完成。Ceph 没有任何逻辑来执行这些操作。使用 Vault 令牌与 Ceph 的最简单最佳方法是同时运行 Vault 代理并让它刷新令牌文件。在这种模式下使用 Vault 代理时，可以使用文件系统权限来限制谁可以使用令牌。

与其让 Vault 代理刷新令牌文件，不如让它充当代理服务器。在这种模式下，当需要时 Vault 会添加令牌，并在转发到真实服务器之前将其添加到传递给它的请求中。Vault 代理仍然会像在文件系统中存储令牌时一样处理令牌更新。在这种模式下，必须正确保护 RGW 用于访问 Vault 代理的网络路径，例如让 Vault 代理仅监听 localhost。

对象网关的令牌策略

所有 Vault 令牌都具有附加到该令牌的策略指定的权限。多个策略可以与一个令牌相关联。您应该仅使用您的配置所需的策略。

当使用 KV 密钥引擎与对象网关一起使用时：

vault policy write rgw-kv-policy -<<EOF
  path "secret/data/*" {
    capabilities = ["read"]
  }
EOF

当使用 Transit 密钥引擎与对象网关一起使用时：

vault policy write rgw-transit-policy -<<EOF
  path "transit/keys/*" {
    capabilities = [ "create", "update" ]
    denied_parameters = {"exportable" = [], "allow_plaintext_backup" = [] }
  }

  path "transit/keys/*" {
    capabilities = ["read", "delete"]
  }

  path "transit/keys/" {
    capabilities = ["list"]
  }

  path "transit/keys/+/rotate" {
    capabilities = [ "update" ]
  }

  path "transit/*" {
    capabilities = [ "update" ]
  }
EOF

如果您之前使用较旧版本的 Ceph 与 Transit 引擎一起使用，您可能需要以下策略：

vault policy write old-rgw-transit-policy -<<EOF
  path "transit/export/encryption-key/*" {
    capabilities = ["read"]
  }
EOF

如果您同时使用 SSE-KMS 和 SSE-S3，则应该将它们指向不同的容器。您可以使用单独的 Vault 实例，或者使用单独挂载的 Transit 实例，或者使用公共 Transit 点下的不同分支。如果您不使用单独的 Vault 实例，您可以使用这些来将 SSE-KMS 和 SSE-S3 指向不同的容器：rgw_crypt_vault_prefix和/或rgw_crypt_sse_s3_vault_prefix。当授予 SSE-KMS 桶所有者 Vault 权限时，您不应该给他们权限去弄乱 SSE-S3 密钥；只有 Ceph 本身应该做这些。

令牌身份验证

令牌身份验证方法期望一个明文文件中存在 Vault 令牌。对象网关可以配置为使用令牌身份验证，使用以下设置：

rgw crypt vault auth = token
rgw crypt vault token file = /run/.rgw-vault-token
rgw crypt vault addr = https://vault-server-fqdn:8200

调整这些设置以匹配您的配置。出于安全原因，令牌文件必须仅对对象网关可读。

Vault 代理

Vault 代理是一个客户端守护进程，提供对 Vault 的身份验证并管理令牌更新和缓存。它通常在对象网关所在的同一主机上运行。使用 Vault 代理，可以使用其他 Vault 身份验证机制，如 AppRole、AWS、Certs、JWT 和 Azure。

对象网关可以配置为使用 Vault 代理，使用以下设置：

rgw crypt vault auth = agent
rgw crypt vault addr = http://127.0.0.1:8100

您可以按如下方式设置 Vault 代理：

vault write auth/approle/role/rgw-ap \
  token_policies=rgw-transit-policy,default \
  token_max_ttl=60m

在此处更改策略以匹配您的配置。

获取 role-id：

vault read auth/approle/role/rgw-ap/role-id -format=json | \
  jq -r .data.role_id

将输出存储在某个文件中，例如/usr/local/etc/vault/.rgw-ap-role-id.

获取 secret-id：

vault read auth/approle/role/rgw-ap/role-id -format=json | \
  jq -r .data.role_id

将输出存储在某个文件中，例如/usr/local/etc/vault/.rgw-ap-secret-id.

创建 Vault 代理的配置，例如：

pid_file = "/run/rgw-vault-agent-pid"
auto_auth {
  method "AppRole" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path ="/usr/local/etc/vault/.rgw-ap-role-id"
      secret_id_file_path ="/usr/local/etc/vault/.rgw-ap-secret-id"
      remove_secret_id_file_after_reading ="false"
    }
  }
}
cache {
  use_auto_auth_token = true
}
listener "tcp" {
  address = "127.0.0.1:8100"
  tls_disable = true
}
vault {
  address = "https://vault-server-fqdn:8200"
}

然后，使用 systemctl 或您选择的其他方法来运行具有以下参数的持久守护进程：

/usr/local/bin/vault agent -config=/usr/local/etc/vault/rgw-agent.hcl

一旦 Vault 代理正在运行，您应该会发现它在 localhost 的 8100 端口上监听，并且您应该能够使用vault command.

Vault 命名空间 

在企业版中，Vault 支持命名空间的概念namespaces，这允许组织内的团队进行集中管理，同时确保这些团队在称为租户的隔离环境中运行。

对象网关可以配置为在特定命名空间内访问 Vault，使用以下配置设置：

rgw crypt vault namespace = tenant1

在 Vault 中创建密钥 

Note

用于服务器端加密的密钥必须是 256 位长并 base-64 编码。

使用 KV 引擎

可以使用命令行工具在 KV 版本 2 引擎中创建服务器端加密密钥，如下面的示例所示：

vault kv put secret/myproject/mybucketkey key=$(openssl rand -base64 32)

示例输出：

====== Metadata ======
Key              Value
---              -----
created_time     2019-08-29T17:01:09.095824999Z
deletion_time    n/a
destroyed        false
version          1

注意，在 KV 密钥引擎中，密钥存储为键值对，对象网关期望键名为key，即密钥必须为以下形式key=<secret key>.

使用 Transit 引擎

用于 Transit 引擎的密钥不应再标记为可导出。它们可以创建为：

vault write -f transit/keys/mybucketkey

上述命令创建一个密钥环，其中包含默认类型为aes256-gcm96的密钥。要验证密钥是否正确创建，请使用以下命令：

vault read transit/keys/mybucketkey

示例输出：

Key     Value
---     -----
derived                   false
exportable                false
name                      mybucketkey
type                      aes256-gcm96

配置 Ceph 对象网关 

编辑 Ceph 配置文件以启用 Vault 作为服务器端加密的 KMS 后端：

rgw crypt s3 kms backend = vault

选择 Vault 身份验证方法，例如：

rgw crypt vault auth = token
rgw crypt vault token file = /run/.rgw-vault-token
rgw crypt vault addr = https://vault-server-fqdn:8200

或：

rgw crypt vault auth = agent
rgw crypt vault addr = http://localhost:8100

选择密钥引擎：

rgw crypt vault secret engine = kv

或：

rgw crypt vault secret engine = transit

可选地，设置 Vault 命名空间，其中将获取加密密钥：

rgw crypt vault namespace = tenant1

最后，对象网关将从中获取加密密钥的 Vault URL 可以通过设置路径前缀来限制。例如，对象网关可以限制为按如下方式获取 KV 密钥：

rgw crypt vault prefix = /v1/secret/data

或者，当使用 Transit 密钥引擎时：

rgw crypt vault prefix = /v1/transit

在上面的示例中，对象网关将仅获取https://vault-server:8200/v1/transit.

您可以使用自定义 SSL 证书帮助以下选项与 Vault 进行身份验证：

rgw crypt vault verify ssl = true
rgw crypt vault ssl cacert = /etc/ceph/vault.ca
rgw crypt vault ssl clientcert = /etc/ceph/vault.crt
rgw crypt vault ssl clientkey = /etc/ceph/vault.key

其中vault.ca是 CA 证书，vault.key/vault.crt是为 RGW 访问 Vault 服务器生成的私钥和 SSL 证书。强烈建议将此选项设置为true，设置false非常危险，需要避免，因为这在非常安全的环境中运行。

Transit 引擎兼容性支持

Transit 引擎对之前使用 Transit 引擎作为简单密钥存储的 Ceph 版本提供兼容性支持，

输出的末尾有一个compat选项可以提供给 Transit 引擎以配置兼容性支持，

要完全禁用向后兼容性，使用：

rgw crypt vault secret engine = transit compat=0

这将是未来版本的默认设置。并且对于使用当前版本的新安装是安全的。

这是当前版本的正常默认设置：

rgw crypt vault secret engine = transit compat=1

这启用了新引擎用于新创建的对象，但仍然允许旧引擎用于旧对象。为了访问旧对象和新对象，提供给 Ceph 的 Vault 令牌必须具有旧的和新的 Transit 策略。

要强制仅使用旧引擎，使用：

rgw crypt vault secret engine = transit compat=2

如果 Vault 前缀以export/encryption-key结尾，这将是之前记录的设置，该模式将自动选择。

上传对象 

当将对象上传到对象网关时，在请求中提供 SSE 密钥 ID。例如，对于 KV 引擎，使用 AWS 命令行客户端：

aws --endpoint=http://radosgw:8000 s3 cp plaintext.txt s3://mybucket/encrypted.txt --sse=aws:kms --sse-kms-key-id myproject/mybucketkey

例如，对于 Transit 引擎（新版本），使用 AWS 命令行客户端：

aws --endpoint=http://radosgw:8000 s3 cp plaintext.txt s3://mybucket/encrypted.txt --sse=aws:kms --sse-kms-key-id mybucketkey

对象网关将从 Vault 中获取密钥，加密对象并将其存储在桶中。对下载对象的任何请求都会使对象网关自动从 Vault 中检索相应的密钥并解密对象。

注意，密钥将使用通过将基本地址 (rgw crypt vault addr)、（可选的）rgw crypt vault prefix）和最后密钥 ID 连接起来的 URL 从 Vault 中获取。

在上面的 KV 引擎示例中，对象网关将从：

http://vaultserver:8200/v1/secret/data/myproject/mybucketkey

在上面的 Transit 引擎示例中，对象网关将使用此密钥加密密钥：

http://vaultserver:8200/v1/transit/mybucketkey

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.

HashiCorp Vault Integration

Vault 密钥引擎