mumoshu/aws-secret-operator Docker 镜像 - 轩辕镜像 | Docker 镜像高效稳定拉取服务

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": ***.306,
       "LastAccessedDate": ***.0,
       "VersionIdsToStages": {
           "c43e66cb-d0fe-44c5-9b7e-d450441a04be": ["AWSCURRENT"]
       }
   }
   

注意：aws-secret-operator不允许省略VersionId或指定VersionStage，因为这会导致难以响应AWS密钥变化触发Pod更新。可使用update-aws-secret-ids脚本自动更新配置文件中的VersionId。

创建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速率限制过低，在大规模使用时易触发限流，已有多个社区讨论证实此问题（如segmentio/chamber#84）。

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

优点：可扩展性好，支持按前缀高效批量获取（如chamber项目曾因SSM限流问题转向S3）。
缺点：工具支持较少，Secrets Manager作为专用密钥管理服务，有更多开发者关注和工具支持，用户体验更优。

与其他工具结合使用

与sops结合

在独立CI/CD流水线中使用sops，将密钥的“主数据”版本控制在Git仓库中。每次PR修改主数据时，CI工作流自动将更新部署到AWS Secrets Manager。仅授予CI KMS加密权限，即使凭证泄露也无法解密密钥。

替代方案

bitnami-labs/sealed-secrets

适用于：

• 需要云厂商无关方案
• 可接受私钥可能被窃取的理论风险

future-simple/helm-secrets

适用于：

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

致谢

本项目基于operator-framework构建，感谢该框架提供的强大支持。