mumoshu/aws-secret-operator

aws-secret-operator

镜像概述和主要用途

aws-secret-operator是一个Kubernetes operator，用于根据AWS Secrets Manager中存储的密钥自动创建和更新Kubernetes secrets。通过自定义资源（CR）将AWS密钥映射到Kubernetes secrets，Kubernetes secrets在此过程中作为AWS密钥的缓存，始终保持最新状态。

核心功能和特性

安全性

采用“静态解密”机制，无需通过手动、helm、kustomize或其他需要在CI或本地解密原始密钥的方式创建Kubernetes secrets，降低密钥泄露风险。

可扩展性

依赖AWS Secrets Manager而非SSM Parameter Store，减少因SSM API速率限制导致的限流问题。Kubernetes secrets作为Secrets Manager密钥的缓存，最大限度减少对Secrets Manager的API调用次数。

使用场景和适用范围

适用于需要在Kubernetes环境中安全管理密钥的场景，特别是：

• 不希望在CI系统或本地环境处理密钥解密的场景
• 需要将AWS Secrets Manager中的密钥自动同步到Kubernetes的场景
• 对API调用频率和稳定性有较高要求的大规模部署环境

使用方法和配置说明

前提条件

• 已在AWS Secrets Manager中创建密钥
• Kubernetes集群已配置，且具有适当的RBAC权限
• 集群可访问AWS Secrets Manager（需配置AWS凭证，如通过IAM角色或环境变量）

创建AWS Secrets Manager密钥

1. 获取现有密钥（若已存在）：

   console
   aws secretsmanager get-secret-value --secret-id prod/mysecret
   

2. 创建新密钥：

   console
   aws secretsmanager create-secret --name prod/mysecret
   

   输出示例：

   json
   {
       "ARN": "arn:aws:secretsmanager:REGION:ACCOUNT:secret:prod/mysecret-Ld0PUs",
       "Name": "prod/mysecret"
   }
   

3. 设置密钥值：

   console
   aws secretsmanager put-secret-value --secret-id prod/mysecret --secret-string '{"foo":"bar"}'
   

4. 获取密钥ID和版本ID（用于后续配置）：

   console
   aws secretsmanager describe-secret --secret-id prod/mysecret
   

   输出示例（关注VersionIdsToStages中的版本ID）：

   json
   {
       "ARN": "arn:aws:secretsmanager:REGION:ACCOUNT:secret:prod/mysecret-Ld0PUs",
       "Name": "prod/mysecret",
       "LastChangedDate": 1543636981.306,
       "LastAccessedDate": 1543622400.0,
       "VersionIdsToStages": {
           "c43e66cb-d0fe-44c5-9b7e-d450441a04be": ["AWSCURRENT"]
       }
   }
   

注意：aws-secret-operator不允许省略VersionId或指定VersionStage，因为这会导致难以响应AWS密钥变化触发Pod更新。可使用https://github.com/mumoshu/aws-secret-operator/blob/master/scripts/update-aws-secret-ids%E8%87%AA%E5%8A%A8%E6%9B%B4%E6%96%B0%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6%E4%B8%AD%E7%9A%84VersionId%E3%80%82

创建AWSSecret自定义资源

创建your_example_awssecret.yaml文件，指定AWS密钥的引用：

yaml
apiVersion: mumoshu.github.io/v1alpha1
kind: AWSSecret
metadata:
  name: example
spec:
  stringDataFrom:
    secretsManagerSecretRef:
      secretId: prod/mysecret
      versionId: c43e66cb-d0fe-44c5-9b7e-d450441a04be

应用该配置：

console
kubectl create -f your_example_awssecret.yaml

生成的Kubernetes Secret

operator将自动创建名为example的Kubernetes Secret，内容如下：

• 键值对格式（当AWS密钥内容为JSON键值映射时）：

  json
  {
    "apiVersion": "v1",
    "data": {
      "foo": "YmFyCg=="
    },
    "kind": "Secret",
    "metadata": {
      "name": "example",
      "namespace": "default",
      "creationTimestamp": "2018-05-04T20:55:43Z"
    },
    "type": "Opaque"
  }
  

• 纯文本格式（当AWS密钥为原始字符串时）：

  json
  {
    "apiVersion": "v1",
    "data": {
      "data": "Zm9vXG5iYXIK"
    },
    "kind": "Secret",
    "metadata": {
      "name": "example",
      "namespace": "default",
      "creationTimestamp": "2020-06-29T10:35:32Z"
    },
    "type": "Opaque"
  }
  

在Pod中使用生成的Secret

可通过卷挂载或环境变量方式在Pod中使用该Secret：

yaml
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    env:
    - name: FOO
      valueFrom:
        secretKeyRef:
          name: example
          key: foo
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
  volumes:
  - name: secret-volume
    secret:
      secretName: example

安装步骤

1. 设置RBAC权限：

   • 命名空间级（更安全）：

     console
     kubectl create -f deploy/namespaced/rbac.yaml
     

   • 集群级（易于使用）：

     console
     kubectl create -f deploy/cluster_scoped/rbac.yaml
     

2. 创建CRD：

   console
   kubectl create -f deploy/crds/mumoshu_v1alpha1_awssecret_crd.yaml
   

3. 部署operator：

   • 命名空间级（替换REPLACE_THIS_WITH_YOUR_REGION为实际区域，如us-west-2）：

     console
     cat deploy/namespaced/deployment.yaml | sed -e 's/REPLACE_THIS_WITH_YOUR_REGION/ap-northeast-1/' | kubectl create -f -
     

   • 集群级：

     console
     cat deploy/cluster_scoped/deployment.yaml | sed -e 's/REPLACE_THIS_WITH_YOUR_REGION/ap-northeast-1/' | kubectl create -f -
     

4. 验证部署：

   console
   kubectl get pod -l app=aws-secret-operator
   

5. 清理：

   console
   kubectl delete -f your_example_awssecret.yaml
   kubectl delete -f deploy/namespaced/deployment.yaml  # 或对应集群级部署文件
   kubectl delete -f deploy/namespaced/rbac.yaml  # 或对应集群级RBAC文件
   kubectl delete -f deploy/crds/mumoshu_v1alpha1_awssecret_crd.yaml
   

为什么选择aws-secret-operator

为何不使用helm-secrets或sops结合kubectl？

这些工具通过在CI中解密密钥文件（如values.yaml）供helm使用，这要求CI系统具有解密权限。若CI凭证泄露，***者可解密所有密钥，尤其在公共SaaS CI系统中风险更高。aws-secret-operator仅让CI提交AWS Secrets Manager的引用，由operator在集群内解密生成Kubernetes Secret，降低泄露风险。

为何不使用AWS SSM Parameter Store作为密钥源？

优点：支持批量获取同一前缀的多个密钥，API高效。
缺点：API速率限制过低，在大规模使用时易触发限流，已有多个社区讨论证实此问题（如https://github.com/segmentio/chamber/issues/84#issuecomment-437728047%EF%BC%89%E3%80%82

为何不使用S3作为密钥源？

优点：可扩展性好，支持按前缀高效批量获取（如https://github.com/segmentio/chamber%E9%A1%B9%E7%9B%AE%E6%9B%BE%E5%9B%A0SSM%E9%99%90%E6%B5%81%E9%97%AE%E9%A2%98%E8%BD%AC%E5%90%91S3%EF%BC%89%E3%80%82
缺点：工具支持较少，Secrets Manager作为专用密钥管理服务，有更多开发者关注和工具支持，用户体验更优。

与其他工具结合使用

与sops结合

在独立CI/CD流水线中使用https://github.com/mozilla/sops%EF%BC%8C%E5%B0%86%E5%AF%86%E9%92%A5%E7%9A%84%E2%80%9C%E4%B8%BB%E6%95%B0%E6%8D%AE%E2%80%9D%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6%E5%9C%A8Git%E4%BB%93%E5%BA%93%E4%B8%AD%E3%80%82%E6%AF%8F%E6%AC%A1PR%E4%BF%AE%E6%94%B9%E4%B8%BB%E6%95%B0%E6%8D%AE%E6%97%B6%EF%BC%8CCI%E5%B7%A5%E4%BD%9C%E6%B5%81%E8%87%AA%E5%8A%A8%E5%B0%86%E6%9B%B4%E6%96%B0%E9%83%A8%E7%BD%B2%E5%88%B0AWS Secrets Manager。仅授予CI KMS加密权限，即使凭证泄露也无法解密密钥。

替代方案

bitnami-labs/sealed-secrets

适用于：

• 需要云厂商无关方案
• 可接受https://github.com/bitnami-labs/sealed-secrets/issues/123

future-simple/helm-secrets

适用于：

• 无需跨应用、命名空间或环境共享密钥（密钥需在多个Git项目中复制和重新加密）

致谢

本项目基于https://github.com/operator-framework/operator-sdk%E6%9E%84%E5%BB%BA%EF%BC%8C%E6%84%9F%E8%B0%A2%E8%AF%A5%E6%A1%86%E6%9E%B6%E6%8F%90%E4%BE%9B%E7%9A%84%E5%BC%BA%E5%A4%A7%E6%94%AF%E6%8C%81%E3%80%82