patoarvizu/kms-vault-operator

KMS Vault operator

!Black Lives Matter !CircleCI !GitHub tag (latest SemVer) !Docker Pulls !Keybase BTC !Keybase PGP !GitHub

• 简介
• 描述
• 配置
  • AWS
  • Vault
    • Kubernetes认证方式（--vault-authentication-method=k8s）
    • Vault令牌认证方式（--vault-authentication-method=token）
    • Vault用户密码认证方式（--vault-authentication-method=userpass）
    • Vault AppRole认证方式（--vault-authentication-method=approle）
    • Vault GitHub认证方式（--vault-authentication-method=github）
    • Vault IAM认证方式（--vault-authentication-method=iam）
  • 命令行标志
  • 创建秘密
  • 部分秘密
  • 空秘密
  • 验证Webhook
    • 证书自动重载
  • 监控
• 安全相关说明
  • Docker镜像已签名并发布到Docker Hub的Notary服务器
  • Docker镜像包含Git和GPG元数据标签
• 多架构镜像
• 项目重要注意事项
  • Kubernetes命名空间与Vault命名空间
  • 多个秘密写入同一位置
  • 不对目标路径进行验证
  • 删除KMSVaultSecret时移除秘密
  • 解密或解码错误将被忽略（但会记录日志）
  • 对K/V V2的支持有限（当前版本）
  • 部分秘密不验证键
  • 部分秘密尚不支持终结器
• 寻求帮助！

简介

我们都知道（或应该知道）在源代码控制中以明文形式存储秘密绝对是大忌。这迫使我们以其他方式存储敏感文本，例如密码管理器，或者更糟的是，将加密文件存储在同一存储库中（但加密文件的密码又该存放在哪里？！）。因此，我们要么面临“首个秘密”问题，要么面临“真相源”问题，要么面临自动化问题。

KMS 为加密/解密问题提供了一个很好的解决方案，使我们可以将加密的秘密存储在源代码控制中（从而更接近依赖它的代码）。但通常情况下，这些秘密本身价值不高，需要解密后放置在运行时可访问的位置，例如 Vault。

一种可行的模式是 KMS + Vault + Terraform。通过创建 KMS 密钥（可使用 Terraform 完成），我们可以加密秘密并安全地存储在源代码控制中。然后，可通过 Terraform 的 aws_kms_secrets 数据源解密，并传递给 vault_generic_secret 资源写入 Vault。再配合 inmem 存储后端，秘密将永远不会以明文形式存在于持久存储中。

虽然这种方式可以安全地存储秘密，但不利于自动化。Terraform Enterprise 等选项通常价格昂贵，而像通过 cron 作业运行 terraform apply 这样的临时解决方案则脆弱且不安全。

本 operator 的目标是最小化秘密暴露的安全风险，同时利用 Kubernetes 提供自动化以减少配置漂移。

描述

该 operator 管理包含 KMS 密钥加密（并经 base64 编码）秘密的 KMSVaultSecret CRD，并将这些秘密存储在 Vault 中。这允许您在源代码控制中安全管理 Vault 秘密，且仅在运行时解密，秘密仅存在于 operator 内存中，从而最小化明文秘密的暴露。operator 资源和脚手架代码通过 https://github.com/operator-framework/operator-sdk 自动管理和生成。

用于执行解密操作的 AWS 凭据使用 https://github.com/aws/aws-sdk-go%EF%BC%8C%E5%B9%B6%E9%81%B5%E5%BE%AA%E9%BB%98%E8%AE%A4%E7%9A%84 凭据优先级顺序。因此，若要注入环境变量或配置文件，应在 operator 的 Deployment 清单中进行（例如 deploy/operator.yaml）。

每个秘密定义包含 path、一组 kvSettings 和一个 secrets 列表。每个 secret 包含 key（字符串类型）、encryptedSecret（字符串类型）字段，以及 secretContext 字段（对应秘密加密时使用的 加密上下文 的任意键值对集合）。

operator 的第一个版本支持通过 Kubernetes 认证方式、Userpass 认证方式 或直接通过 Vault 令牌 向 Vault 认证。未来将添加对更多认证方式的支持。请注意，operator 执行 KMS 和 Vault 操作所需的配置不是在 KMSVaultSecret CR 上完成，而是在 operator Deployment 本身进行，具体配置如下文所述。

配置

AWS

如上所述，允许 operator 解密秘密所需的配置应通过 operator Deployment 清单注入（作为 AWS_* 环境变量或 ~/.aws/credentials/~/.aws/config 文件）。aws-sdk-go 库还会在运行时发现 EC2 实例上的 IAM 角色（如果 operator 在具有实例角色的 EC2 实例上运行），此时无需在 operator 上进行额外配置。

Vault

除 AWS 配置外，还应注入 Vault 配置。https://github.com/hashicorp/vault/tree/master/api 将读取并使用常见的 VAULT_* 环境变量。根据环境不同，需要设置的变量会有所差异，但通常至少需要设置 VAULT_ADDR，以及 VAULT_CACERT/VAULT_CAPATH（指向相应的挂载文件或目录）或 VAULT_SKIP_VERIFY。这些均在 operator Deployment 清单中完成。

以下部分记录了每种认证方式使用的环境变量及其默认值，它们将与前面描述的 AWS 和基础 Vault 变量一起使用。

Kubernetes认证方式（--vault-authentication-method=k8s）

Vault令牌认证方式（--vault-authentication-method=token）

此方式遵循约定，使用 VAULT_TOKEN 环境变量进行认证。

Vault用户密码认证方式（--vault-authentication-method=userpass）

Vault AppRole认证方式（--vault-authentication-method=approle）

Vault GitHub认证方式（--vault-authentication-method=github）

Vault IAM认证方式（--vault-authentication-method=iam）

此认证方式使用 Vault AWS 认证方式，但仅支持 iam 方法。未来可能添加对 ec2 方法的支持。

由于 operator 本身假定已通过某种方式（环境变量、https://github.com/jtblin/kube2iam%E3%80%81https://github.com/uswitch/kiam 等）获得解密操作所需的 IAM 凭据，默认情况下，这些凭据可用于通过 aws 方法登录 Vault。但如果希望将解密凭据与登录凭据分开，也可通过以下环境变量注入静态凭据。

注意： 远程 Vault 实例还需要运行时权限来执行 IAM 验证操作。这些凭据无法由 operator 设置，必须通过其他方式直接在目标 Vault 集群中设置。有关推荐的 IAM 策略，请参考官方 Vault 文档。

命令行标志

创建秘密

加密/解密 KMS 秘密所需的 AWS 资源设置超出本文档范围（但您可在 此处 了解 KMS），因此我们假设 KMS 密钥已存在，且用于离线加密秘密的凭据以及运行时解密的凭据具有执行这些操作所需的权限。如果您使用 Terraform，可能会发现 https://github.com/patoarvizu/terraform-kms-encryption/tree/master/modules 对处理 KMS 很有用。

从命令行，您可以使用 aws kms encrypt 命令，例如：

bash
aws kms encrypt --key-id <key-id-or-alias> --plaintext "Hello world" --output text --query CiphertextBlob

然后将输出作为 KMSVaultSecret 资源的 spec.secrets 数组项，例如：

yaml
apiVersion: k8s.patoarvizu.dev/v1alpha1
kind: KMSVaultSecret
metadata:
  name: example-kmsvaultsecret
  namespace: default
spec:
  path: secret/test/kms-vault-secret
  kvSettings:
    engineVersion: v1
  secrets:
    - key: test
      encryptedSecret: <kms-encrypted-secret>

之后，假设资源位于 deploy/example-kms-vault-secret.yaml，运行：

bash
kubectl apply -f deploy/example-kms-vault-secret.yaml

部分秘密

除管理 KMSVaultSecret 自定义资源外，该 operator 还处理第二种资源类型 PartialKMSVaultSecret。此 CRD 与 KMSVaultSecret 类似，但仅支持 secrets 字段，且没有自己的控制器。相反，此资源的目的是保存可通过 includeSecrets 字段包含在 KMSVaultSecret 中的秘密。kmsvaultsecret_controller.go 将聚合包含的秘密以及资源本身的秘密，并将它们一起作为单个项写入 Vault。为简单起见，此功能的第一版不支持嵌套 PartialKMSVaultSecret（例如在其他 PartialKMSVaultSecret 中包含 PartialKMSVaultSecret）。相反，包含多个部分秘密的方法是在 KMSVaultSecret 资源的 includeSecrets 字段中列出所有部分秘密。

由于其抽象性质，PartialKMSVaultSecret 没有路径、Vault 认证方法或 KV 设置，但支持 KMS 秘密加密上下文，该上下文会传递给具体的 KMSVaultSecret 对象。

空秘密

尽管很少需要空字符串作为秘密，但有时出于向后兼容性或作为占位符需要。由于空字符串不是有效的 KMS 加密字符串，CRD 包含一个字段，用于向 operator 指示应在指定路径和字段中放置空字符串。为此，只需为 secrets 下要注入为空字符串的每个项设置 emptySecret: true。请注意，执行此操作时，operator 将忽略 encryptedSecret 字段中设置的任何内容，即使它是有效的 KMS 加密字符串。

验证Webhook

Docker 镜像包含另一个二进制文件（kms-vault-validating-webhook），可用作 ValidatingWebhookConfiguration 调用的服务器，以验证 KMSVaultSecret 或 PartialKMSVaultSecret，并防止它们被控制器获取。由于此二进制文件与主二进制文件分离，因此需要将其部署为 sidecar 或单独的 Deployment，并需要自己的 Service。您可以在 此处 找到将其部署为 sidecar 的示例。

请记住，ValidatingWebhookConfiguration 需要有效的 CA bundle 才能通过 TLS 信任 webhook。虽然这可以是任何离线生成的证书，但您也可以使用 https://github.com/jetstack/cert-manager/ 轻松生成作为 Kubernetes Secret 的证书并挂载到容器（如 webhook），或在 ValidatingWebhookConfiguration 中注入相应的 CA bundle。

证书自动重载

如果磁盘上的基础 TLS 证书（由 -tls-cert-file 标志指示）被修改，则 webhook 会执行热重载。这在使用 cert-manager 等自动证书配置程序时很有用，这些程序会自动轮换证书，但无法控制使用证书的工作负载的生命周期。

实现方式是最初加载证书并将其保存在本地缓存中，然后使用 [radovskyb