External Secrets Operator PushSecretdataTo完全指南Kubernetes 密钥批量推送、正则过滤与键名重写【免费下载链接】external-secretsExternal Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.项目地址: https://gitcode.com/GitHub_Trending/ex/external-secretsExternal Secrets OperatorESO的 PushSecret 新增了dataTo字段用于将 Kubernetes Secret 中的全部或按正则筛选的子集密钥批量推送到外部 Secret 提供商而无需逐条枚举data。本文以仓库内设计文档 docs/design/pushsecret-datato.md 与实战指南 docs/guides/pushsecret-datato.md 为主线结合 API 类型定义、控制器实现 与 示例清单 等源码证据系统讲解dataTo的两种操作模式、match过滤、rewrite键名重写、provider 差异与错误处理帮助你从逐键推送升级为声明式批量推送。背景与动机为什么 PushSecret 需要dataTo在dataTo出现之前PushSecret 要求对每一个要推送的键显式声明一条data条目。这种逐键枚举模式在实际使用中带来三个问题同步漂移Sync drift——在 Kubernetes Secret 中新增键却没有同步新增 PushSecret 条目该键会被静默忽略永远推不到 provider配置冗长Config verbosity——一个含 20 个键的 Secret 需要 20 行结构雷同的样板 YAML维护负担Maintenance burden——密钥随应用代码演进保持 PushSecret 配置与密钥集合同步很容易被遗忘。值得注意的是ExternalSecret 早已通过dataFrom解决了对应的入站问题从 provider 批量拉取而 PushSecret 此前没有任何对应的出站批量机制。dataTo正是为了补齐这一缺口而设计。设计文档列举的现有变通方案及其缺陷变通方案缺陷在spec.data中逐一枚举每个键冗长键变化时容易失同步用外部工具脚本、Helm helper生成 PushSecret YAML引入构建期依赖不是声明式的每个键一个 PushSecret资源数量爆炸难以推理和维护对于密钥集合动态变化频繁的团队上述方案均不理想。dataTo的目标就是无需逐键枚举即可把 K8s Secret 的全部或过滤后的子集密钥批量推送到 provider并支持在推送前对源键名做转换重写。设计目标与非目标设计文档 docs/design/pushsecret-datato.md 明确了目标与非目标Goals支持将 K8s Secret 中的全部或过滤子集密钥批量推送到 provider无需逐键枚举支持键名转换源键名在到达 provider 前可被重写每条批量推送条目必须限定到特定 store防止误跨 store 推送与显式data条目共存显式条目优先在推送方向上对齐 ExternalSecret 的dataFrom能力。Non-goals不取代spec.data——逐键精确控制仍然可用且优先级更高不实现 ExternalSecret 的Extract或Find——数据源永远是spec.selector选中的 K8s Secret而非 provider 查询不实现Merge重写——PushSecret 只有一个数据源没有可合并的对象不新增RefreshPolicy在 issue #5221 中单独跟踪不修改 provider 接口SecretsClient。API 形状PushSecretDataTo类型详解dataTo的 API 由 apis/externalsecrets/v1alpha1/pushsecret_types.go 中的PushSecretDataTo结构体定义。设计文档中的 Go 类型骨架与仓库实现一致type PushSecretDataTo struct { StoreRef *PushSecretStoreRef // 必填——推送到哪个 store RemoteKey string // 可选——bundle 模式的目标键 Match *PushSecretDataToMatch // 可选——正则键过滤 Rewrite []PushSecretRewrite // 可选——键名转换 Metadata *apiextensionsv1.JSON // 可选——provider 特定元数据 ConversionStrategy PushSecretConversionStrategy // 可选——键名编码 } type PushSecretDataToMatch struct { RegExp string // 空或 nil 匹配所有键 } type PushSecretRewrite struct { // 以下二选一 Regexp *esv1.ExternalSecretRewriteRegexp Transform *esv1.ExternalSecretRewriteTransform }该结构体在仓库中还带有两个 CEL 校验规则pushsecret_types.go L216-L217storeRef必须存在且name与labelSelector至少声明其一否则报错 storeRef must specify either name or labelSelectorremoteKey与rewrite互斥一旦设置remoteKeybundle 模式rewrite必须为空否则报错 remoteKey and rewrite are mutually exclusive。此外PushSecretRewriteL259-L269自身也有一条 XValidationregexp与transform必须恰好设置一个。这些规则在 API Server 层面即拦截非法组合是文档中边界情况一节的实现保障。为什么命名为dataTo命名刻意镜像 ExternalSecret 的dataFromdataFrom 从 provider拉取from数据到 K8sdataTo 从 K8s推送to数据到 provider。方向语义无歧义且这种对称性有助于用户发现与记忆。两种操作模式Per-key 与 BundledataTo的每条条目有两种互斥的展开模式取决于是否设置remoteKey模式触发条件行为适用场景Per-key逐键未设置remoteKey每个匹配的键成为 provider 中独立的 secret/变量环境变量类 providerGitHub Actions、DopplerBundle打包设置remoteKey所有匹配键作为 JSON 对象打包进一个具名 provider secret具名 secret 类 providerAWS SM、Vault、Azure KV、GCP SM关键约束bundle 模式与rewrite互斥。当键被打包进 JSON 对象时JSON 内部的键名是源键名经 conversion 处理后而不是被单独重写的 provider 路径。从控制器源码看这两种模式在 expandSingleDataTo 中分别实现bundle 模式生成一条SecretKey、RemoteKeydataTo.RemoteKey的PushSecretData条目并把过滤后的键值集合通过bundleOverrides映射传出保证推送到 provider 的 JSON 只包含匹配键per-key 模式则为每个匹配键生成一条独立的PushSecretData并保留源键 → 远端键的映射用于状态跟踪。与 ExternalSecretdataFrom的对比维度ExternalSecretdataFromPushSecretdataTo方向Provider → K8sK8s → Provider数据源ProviderExtract、Find、GeneratorRefK8s Secret通过spec.selector源发现在 provider 中按 tags/name Find在 K8s 键名上按正则过滤键转换Regexp、Transform、MergeRegexp、Transform无 Merge——单一数据源Store 定位每个 ES 一个secretStoreRef每条条目一个storeRef必填合并策略多个 dataFrom 合并进一个 SecretdataTo 显式data合并显式优先为什么dataTo比dataFrom更简单没有Extract或Find——数据源始终是 K8s Secret无需查询 provider没有Merge重写——单一数据源意味着不存在多源键冲突需要解决逐条目 store 作用域——每条条目声明自己的目标 store避免推送到所有 store的误操作。Rewrite 类型复用与实现差异PushSecretRewrite复用了 ExternalSecret 的内部类型esv1.ExternalSecretRewriteRegexpsource/target 正则替换esv1.ExternalSecretRewriteTransformGo 模板转换。这种复用避免了类型重复同时有意排除了不适用于推送方向的ExternalSecretRewriteMerge见 pushsecret_types.go。设计文档特别说明控制器使用rewriteWithKeyMapping()而非esutils.RewriteMap()因为 PushSecret 需要源键 → 目标键的映射用于冲突解决与状态跟踪RewriteMap直接原地变换map[string][]byte无法追溯哪个原始键产生了哪个远端键。这一差异是有意设计并在文档中记录的。对应实现位于 pushsecret_controller.go L1168。storeRef必填防止误推送每条dataTo条目必须通过storeRef指定目标 store且name或labelSelector至少其一源码校验。这是维护者反馈后加入的约束当secretStoreRefs含多个条目时防止无意间推送到所有 store。控制器在 reconcile 初期即调用validateDataToStoreRefs与validateDataToMatchesResolvedStoresL261、L305确保每个dataTo.StoreRef都能在secretStoreRefs中解析到真实存在的 store。Metadata 处理逐 store 的自然隔离每条dataTo条目携带独立的Metadata字段。由于不同 provider 需要结构不同的 metadata例如 AWS 的 tags 与 Azure 的 properties而每条条目又通过storeRef锁定特定 store因此为不同 store 建独立dataTo条目即可自然实现按 store 提供各自 metadata。这与备选方案三provider 键控的 metadata map相比无需在 API 中枚举 provider 类型。特性交互一览特性与dataTo的交互Templatespec.templateTemplate 在dataTo展开之前应用dataTo匹配的是 template 输出后的键UpdatePolicyIfNotExists逐条目生效远端 secret 已存在则跳过推送DeletionPolicyDelete所有dataTo展开的条目都记录在status.syncedPushSecrets中源 Secret 被删除时所有被跟踪的 provider secret 被清理ConversionStrategy在键匹配与重写之前应用因此正则模式看到的是转换后的键名显式data同一源键下显式条目覆盖dataTo比较使用原始未转换的 K8s 键名其中Template 先于 dataTo 展开意味着如果你用 template 生成/重命名键dataTo的match.regexp应针对 template 输出后的键编写。而DeletionPolicyDelete的清理语义依赖 PushSecretStatus.SyncedPushSecrets外层 map 键为 store 名内层 map 键为 remote key——dataTo展开出的条目同样进入该跟踪结构。边界情况设计文档规定的行为矩阵场景行为空匹配模式匹配所有键无键匹配Info 日志并继续不是错误正则无效PushSecret 进入错误状态详情写入 status远端键重复条目内或跨条目Reconcile 失败列出所有冲突源同一源键存在显式datadata优先dataTo条目被丢弃模板无效以模板解析错误失败同一 rewrite 上同时出现regexp和transform被 CRD XValidation 拦截storeRef不在secretStoreRefs中校验错误源 Secret 被删除 DeletionPolicyDelete通过 status 跟踪清理 provider secret同一条目同时有remoteKey与rewritebundle 模式下rewrite被忽略有文档说明源码中的对应实现matchKeysL867在正则编译失败时返回错误registerRemoteKeysL971-L981在发现重复 remote key 时返回带冲突源键的错误resolveSourceKeyConflictsL1230以原始 K8s 键名比较、让显式data覆盖dataToexpandSingleDataToL1006-L1008对remoteKey rewrite组合直接报错与 XValidation 双保险。实战如何选择正确的模式Per-key 模式环境变量类 providerGitHub Actions 和 Doppler 将 secret 建模为独立的具名变量——K8s Secret 中的每个键对应 provider 中的一个变量。此时不要设置remoteKey键名本身即成为 provider 变量名。# GitHub Actions / Doppler — 每键一个变量 dataTo: - storeRef: name: github-store # 无 remoteKey —— 每个 K8s 键成为独立的 GitHub secret match: regexp: ^APP_假设 K8s Secret 含APP_TOKEN与APP_ENV则 GitHub Actions 中结果为APP_TOKEN → value of APP_TOKEN APP_ENV → value of APP_ENVBundle 模式具名 secret 类 providerAWS Secrets Manager、Azure Key Vault、GCP Secret Manager 与 HashiCorp Vault 将 secret 建模为承载 JSON 载荷的单个具名对象。使用remoteKey命名该对象所有匹配键被打包为其中的 JSON 对象。# AWS SM / Azure KV / GCP SM / Vault — 所有键 → 一个具名 secret dataTo: - storeRef: name: aws-store remoteKey: my-app/config # AWS Secrets Manager 中的 secret 名 match: regexp: ^DB_AWS Secrets Manager 中的结果为my-app/config → {DB_HOST:localhost,DB_USER:admin,DB_PASS:s3cr3t}警告具名 secret 类 provider 省略remoteKey的后果如果在 AWS Secrets Manager 这类 provider 上省略remoteKeydataTo会回退到 per-key 模式为每个匹配键创建一个独立的 AWS secretDB_HOST、DB_USER、DB_PASS各成一个 secret。这在 AWS 上几乎总不是你想要的结果——面向 AWS SM、Azure KV、GCP SM、Vault 时务必设置remoteKey。Provider 参考secret 模型与remoteKey用法ProviderSecret 模型使用remoteKey说明AWS Secrets Manager具名 secretJSON是remoteKey secret 名storeprefix会被前置AWS Parameter Store具名参数是remoteKey 参数路径AWS Certificate Manager具名证书是remoteKeyexternal-secrets-remote-keytag 值Azure Key Vault具名 secret/key/cert是remoteKey 对象名GCP Secret Manager具名 secret是remoteKey secret IDHashiCorp Vault具名路径JSON是remoteKey Vault 路径Oracle Vault具名 secret是remoteKey secret 名Kubernetes具名 secret是remoteKey 目标 Secret 名Bitwarden具名条目是remoteKey 条目键GitHub Actions环境变量每键一个否键名 Actions secret 名Doppler环境变量每键一个否键名 Doppler 变量名Webhook可配置视实现而定请查阅你的 webhook 实现按 Provider 的完整示例AWS Secrets Manager警告prefix remoteKey 拼接后的名称AWS SecretStore 的prefix会前置到每个remoteKey之前。若 store 配置了prefix: myapp/而dataTo设置remoteKey: db-config最终 AWS secret 名是myapp/db-config而非db-config。常见错误是同时设置prefix: secrets-sync-temp/与remoteKey: secrets-sync-temp结果产生secrets-sync-temp/secrets-sync-temp而非secrets-sync-temp。若希望 secret 名恰好是secrets-sync-temp要么移除 store 的 prefix要么只把后缀部分设为remoteKey。技巧让值在 AWS 控制台可读默认 ESO 以binarySecretBinary存储 secret 值AWS 控制台可能将二进制 secret 显示为空白或不可读。在metadata中加入secretPushFormat: string即可将 JSON 以可读的SecretString形式存储。apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: aws-store spec: provider: aws: service: SecretsManager region: us-east-1 # 无 prefix —— remoteKey 即完整 secret 名。 # 若添加 prefix最终名称为prefix remoteKey。 --- apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: push-to-aws spec: secretStoreRefs: - name: aws-store kind: SecretStore selector: secret: name: app-secrets # 含 DB_HOST、DB_USER、DB_PASS 的 K8s Secret dataTo: - storeRef: name: aws-store remoteKey: my-app/db-config # → AWS secret 名恰为 my-app/db-config match: regexp: ^DB_ metadata: apiVersion: kubernetes.external-secrets.io/v1alpha1 kind: PushSecretMetadata spec: secretPushFormat: string # 以 SecretString 存储控制台可读AWS Secrets Manager 中的结果my-app/db-config → {DB_HOST:localhost,DB_USER:admin,DB_PASS:s3cr3t}警告metadata 必须是完整的 PushSecretMetadata 包装metadata字段不是普通键值 map必须是合法的PushSecretMetadata对象含apiVersion、kind、spec。直接把secretPushFormat: string放在metadata:下会导致解析错误。带 store prefix 时# SecretStore 配置 prefix: myapp/ # dataTo remoteKey: db-config # → AWS secret 名myapp/db-configAWS Certificate ManagerACM 将 TLS 证书作为单个资源导入。源 K8s Secret 必须是kubernetes.io/tls类型且同时包含tls.crtPEM 编码的叶子证书可后接中间证书与tls.keyPEM 编码的私钥。remoteKey成为 ESO 在后续 reconcile 中定位证书所用的external-secrets-remote-keytag 值。警告不要过滤掉tls.crt或tls.keyACM provider 总是从源 secret 读取tls.crt与tls.key。若match.regexp排除了其中任一推送会以key tls.crt not found or empty失败。要么省略match要么写一个同时包含两者的模式如^tls\.。apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: aws-acm-store spec: provider: aws: service: CertificateManager region: us-east-1 --- apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: push-tls-to-acm spec: secretStoreRefs: - name: aws-acm-store kind: SecretStore selector: secret: name: my-tls-cert # 含 tls.crt 与 tls.key 的 kubernetes.io/tls Secret dataTo: - storeRef: name: aws-acm-store remoteKey: my-app-cert # → external-secrets-remote-key tag metadata: apiVersion: kubernetes.external-secrets.io/v1alpha1 kind: PushSecretMetadata spec: tags: # 可选导入证书上的额外 AWS 资源 tag environment: prod team: platformACM 中的结果证书带有managed-byexternal-secrets、external-secrets-remote-keymy-app-cert及metadata.spec.tags中的自定义 tag。保留 tagmanaged-by与external-secrets-remote-key无法通过metadata覆盖。带 store prefix 时# SecretStore 配置 prefix: certs/ # dataTo remoteKey: my-app-cert # → external-secrets-remote-key tag 值certs/my-app-certAzure Key VaultdataTo: - storeRef: name: azure-store remoteKey: app-db-config # Azure Key Vault secret 名 match: regexp: ^DB_GCP Secret ManagerdataTo: - storeRef: name: gcp-store remoteKey: projects/my-project/secrets/app-db-config match: regexp: ^DB_HashiCorp VaultdataTo: - storeRef: name: vault-store remoteKey: secret/data/myapp/db # Vault 路径KV v2 风格 match: regexp: ^DB_GitHub ActionsdataTo: - storeRef: name: github-store # 无 remoteKey —— 每个 K8s 键成为独立的 Actions secret match: regexp: ^DEPLOY_结果独立的 GitHub Actions secret名为DEPLOY_TOKEN、DEPLOY_ENV等。DopplerdataTo: - storeRef: name: doppler-store # 无 remoteKey —— 每个 K8s 键成为独立的 Doppler 变量使用match过滤键match.regexp用于只推送密钥子集省略时包含所有键。dataTo: - storeRef: name: aws-store remoteKey: myapp/db-secrets match: regexp: ^DB_ # 只推送以 DB_ 开头的键dataTo: - storeRef: name: aws-store remoteKey: myapp/all-secrets # 无 match → 源 Secret 中的所有键在控制器中matchKeyspkg/controllers/pushsecret/pushsecret_controller.go L867使用 Go 正则对排序后的键列表做过滤无键命中时expandDataTo仅记录一条 Info 日志dataTo entry matched no keys并继续而非报错——这与边界情况表格中的约定一致。使用rewrite转换键名rewrite只在 per-key 模式无remoteKey下生效在键名成为 provider 变量/secret 名之前对其转换。两种类型正则重写Regexp rewritedataTo: - storeRef: name: github-store match: regexp: ^db- rewrite: - regexp: source: ^db- target: DATABASE_ # db-host → DATABASE_host模板重写Template rewritedataTo: - storeRef: name: github-store rewrite: - transform: template: {{ .value | upper }} # db-host → DB-HOST链式重写Chained rewrites多条 rewrite 按顺序应用每条看到上一条的输出dataTo: - storeRef: name: github-store match: regexp: ^prod-db- rewrite: - regexp: {source: ^prod-, target: } # prod-db-host → db-host - regexp: {source: ^db-, target: DATABASE_} # db-host → DATABASE_host技巧bundle 模式下 rewrite 被忽略设置remoteKey时键名不作为 provider 路径使用——只有键值出现在 JSON 对象中因此 rewrite 条目在此情况下被静默忽略。控制器同样会在expandSingleDataTo入口对remoteKey rewrite组合返回错误源码 L1006-L1008。仓库中另有若干可直接套用的完整示例例如 docs/snippets/pushsecret-datato-rewrite.yamldb-host→myapp/database/host、docs/snippets/pushsecret-datato-chained.yaml先移除db-前缀再加prod/前缀以及 docs/snippets/pushsecret-datato-template.yamlusername→secrets/USERNAME。多条dataTo条目按类别拆分目标在同一条 PushSecret 中把匹配键拆分到不同目标# AWS两个独立 secret各自按类别作用域 dataTo: - storeRef: name: aws-store remoteKey: myapp/database match: regexp: ^DB_ - storeRef: name: aws-store remoteKey: myapp/api match: regexp: ^API_# GitHub不同环境变量组推送到不同 store dataTo: - storeRef: name: github-prod-store match: regexp: ^PROD_ - storeRef: name: github-staging-store match: regexp: ^STAGING_控制器通过filterDataToForStore源码 L887为每个 store 过滤出命中该 store 的dataTo条目支持按namekind或labelSelector匹配再逐条展开跨条目产生重复 remote key 时registerRemoteKeys会报错并列出冲突来源。与显式data组合批量默认值 例外条目显式data条目对同一源键总是覆盖dataTo。可借此实现批量兜底 个别例外spec: dataTo: - storeRef: name: aws-store remoteKey: myapp/config # 默认情况下所有键打包到此 data: - match: secretKey: MASTER_PASSWORD remoteRef: remoteKey: myapp/security/master-password # 该键单独推送对应实现见 docs/snippets/pushsecret-datato-override.yamldataTo推送全部键data覆盖db-host、api-key到自定义路径。合并逻辑resolveSourceKeyConflicts源码 L1230使用原始未转换K8s 键名比较——这是 conversion 与data覆盖之间保持一致性的关键设计。转换策略conversionStrategyconversionStrategy: ReverseUnicode会在匹配与推送前解码 Unicode 转义的键名且应用时机早于match与rewrite即正则模式看到的是转换后的键名dataTo: - storeRef: name: aws-store remoteKey: myapp/config conversionStrategy: ReverseUnicodePushSecretConversionStrategy在 pushsecret_types.go L79-L88 中定义取值为None或ReverseUnicode。控制器在 expandSingleDataTo 中通过esutils.ReverseKeys先转换全部键再建立转换后键名 → 原始键名的反向映射——展开出的条目仍存原始键名从而让后续冲突比较在同一键空间进行。错误处理速查情况行为match中正则无效PushSecret 进入错误状态查看.status.conditionsrewrite 产生空键名Reconcile 失败指名违规的源键两个条目产生同一 remote keyReconcile 失败列出所有冲突源match未命中任何键不是错误Info 日志PushSecret 保持 ReadystoreRef不在secretStoreRefs中Apply 时即校验失败最佳实践具名 secret 类 provider 务必设置remoteKeyAWS SM、Azure KV、GCP SM、Vault——省略会产生每键一个 secret几乎总非所愿环境变量类 provider 绝不设置remoteKeyGitHub Actions、Doppler——键名即变量名打包前先过滤——用match.regexp明确哪些键进入 bundle避免意外纳入敏感键先测试模式——写模式前先检查源 Secret 的键kubectl get secret my-secret -o jsonpath{.data} | jq keys用data处理例外——dataTo覆盖常见场景显式data处理需要自定义路径或属性的键监控状态——用kubectl get pushsecret name -o yaml检查同步错误。备选方案回顾设计文档方案一复用 ExternalSecret 的dataFrom字段名——被否。dataFrom隐含从源拉取而 PushSecret 是推送到目标语义易混淆方案二data为空时隐式推送所有键——被否。对 secret 而言隐式行为太危险一次笔误或误配置可能把键推到非预期 store显式dataTo更安全方案三provider 键控的 metadata map——被否。每条条目的storeRef已天然支持按 store 提供 metadata而 provider 键控 map 要求 API 枚举 provider 类型方案四直接类型别名ExternalSecretRewrite——被否。别名会带入不适用的Merge用共享内部类型的新结构体才能得到正确子集。向后兼容性dataTo完全可选——既有 PushSecret 行为完全不变data字段语义不变v1alpha1 API 纯增量变更无破坏性改动provider 接口无改动既有测试全部继续通过。仓库中的 API 快照 tests/snapshot/pushsecret-v1alpha1.yaml 已包含完整的dataTo字段结构storeRef、remoteKey、match.regexp、rewrite、metadata、conversionStrategy可作为字段合法性的直接参照。深入dataTo的控制器展开流水线从 pkg/controllers/pushsecret/pushsecret_controller.go 可以还原dataTo的完整处理链对应 reconcile 流程 L524-L534校验——validateDataToStoreRefs检查storeRef必填且合法并确认其存在于secretStoreRefs按 store 过滤——filterDataToForStore只保留命中当前 store 的条目展开——expandDataTo逐条调用expandSingleDataTo先做键转换esutils.ReverseKeys再matchKeys正则过滤随后按模式分支——bundle 模式生成单条目并记录bundleOverridesper-key 模式经rewriteWithKeyMapping生成逐键条目冲突检测——registerRemoteKeys跟踪全量 remote key发现重复即报错与显式data合并——resolveSourceKeyConflicts用原始键名让显式条目覆盖dataTo条目。这一流水线同时回答了谁保证只推匹配键bundleOverrides、谁保证不冲突registerRemoteKeys、谁保证覆盖优先级resolveSourceKeyConflicts三个关键问题与设计文档中的边界情况一一对应。相关文档PushSecret 基础指南 —— PushSecret 基本用法PushSecret API 参考 —— 完整 API 规范模板化指南 —— 高级模板用法ExternalSecret dataFrom —— 镜像能力从 provider 批量拉取dataTo 设计文档 —— 本文的设计依据dataTo 示例清单 —— 可直接套用的最小示例另有 regex、rewrite、chained、override、template 共 6 个变体【免费下载链接】external-secretsExternal Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.项目地址: https://gitcode.com/GitHub_Trending/ex/external-secrets创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考