External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成 Kubernetes Secret 值【免费下载链接】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生成器Generator是 External Secrets OperatorESO提供的一组内置值生成能力它允许你在不依赖第三方密钥管理服务的前提下通过ExternalSecret.spec.DataFrom动态生成密码、Token、SSH 密钥、UUID 等值并注入为 Kubernetes Secret。本文将以仓库中的 generator.md 为核心骨架结合 apis/generators/v1alpha1 下的类型定义、generators/v1 下的各生成器实现以及 docs/snippets 中的示例清单系统讲解生成器的引用方式、刷新语义、ClusterGenerator集群级用法与完整参数体系读完你即可在真实集群中配置并复用各类生成器。生成器是什么值的来源而非值的存储从概念上讲生成器负责产出值generate values它通过ExternalSecret的spec.DataFrom被引用引用方式是在dataFrom条目中填写sourceRef.generatorRef。与直接引用密钥存储SecretStore不同生成器不需要访问任何外部密钥管理服务而是按照你定义的spec现场生成一组键值对。有几个关键语义需要先厘清每次调用都产生一组全新的值当ExternalSecret依据spec.refreshInterval触发刷新时生成器以generator.spec作为输入重新生成一份值映射map。生成器本身不追踪、不记忆之前产出的值因此同一个生成器在两次刷新之间产出的值可能完全不同。值不可跨 Secret 共享一个生成器调用产出的值只属于当次调用你不能把同一次生成的结果同时复用到多个ExternalSecret或多个dataFrom[]条目中。生成的值可以继续参与后续加工生成结果与普通拉取到的密钥值一样可以被 ESO 的rewrite重写或template模板化等特性继续处理例如按需修改、编码、解码、打包。这一设计在源码层面体现为Generator接口。在 apis/generators/v1alpha1/generator_interfaces.go 中每个生成器都必须实现两个方法Generate( ctx context.Context, obj *apiextensions.JSON, kube client.Client, namespace string, ) (map[string][]byte, GeneratorProviderState, error) Cleanup( ctx context.Context, obj *apiextensions.JSON, status GeneratorProviderState, kube client.Client, namespace string, ) errorGenerate返回map[string][]byte即密钥名 → 值的映射GeneratorProviderState是可选状态可留待Cleanup阶段使用Cleanup用于删除Generate阶段创建的外部资源且要求幂等资源已被删除时不报错——例如 Webhook、Vault 动态密钥这类生成器可能会在外部系统中创建资源刷新后需要回收。所有生成器通过注册表机制登记在 pkg/register/generators.go 的init()中逐一调用genv1alpha1.Register(kind, generator)注册 ECR、Fake、GCR、GitHub、GitLab、Grafana、MFA、Password、SSHKey、STS、UUID、Vault、Webhook、ACR、BeyondtrustWorkloadCredentials、Cloudsmith、Quay 共 17 个生成器而 apis/generators/v1alpha1/generator_schema.go 中的Register/GetGeneratorByName则实现了按 kind 字符串的查找分发。由此可见生成器本质上是把值从哪里来从密钥存储抽象中解耦出来的一种插件化能力。通过 Custom Resource 引用生成器Reference Custom Resource生成器可以定义为独立的 Custom ResourceCR供多个ExternalSecret复用定义。不过要再次强调定义可以复用产出的值不能复用——每次调用都会生成一组新值。下面的示例引用了一个名为my-ecr的ECRAuthorizationToken生成器将其产出的值通过dataFrom注入到名为ecr-token的 Secret 中apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: ecr-token spec: refreshInterval: 30m0s target: name: ecr-token dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: ECRAuthorizationToken name: my-ecr这里sourceRef.generatorRef需要同时给出三个字段字段取值说明apiVersion生成器 CR 的 API 版本固定为generators.external-secrets.io/v1alpha1kind生成器类型如Password、ECRAuthorizationToken、UUID等必须与生成器 CR 的 kind 精确一致name生成器 CR 的名称指向同命名空间下已创建的生成器对象作为对照docs/snippets/generator-password-example.yaml 给出了引用Password生成器的同构写法tests/password_test.yaml、tests/ecrauthorizationtoken_test.yaml、tests/uuid_test.yaml 等测试文件也验证了各生成器从 CR 定义到 Secret 产出的端到端链路。生成器类型一览generatorRef.kind可用的取值即ClusterGeneratorSpec.Kind枚举也与 apis/generators/v1alpha1/types_cluster.go 中的常量一一对应。当前仓库支持以下生成器kind功能概要典型产出键ACRAccessToken获取 Azure Container Registry 访问令牌token 等ECRAuthorizationToken调用 AWSGetAuthorizationToken获取 ECR 授权令牌有效期 12 小时username、password、proxy_endpoint、expires_atGCRAccessToken获取 Google Container Registry 访问令牌token 等GithubAccessToken生成 GitHub 访问令牌token 等GitlabDeployToken生成 GitLab Deploy Tokenusername、password、token 等QuayAccessToken获取 Quay 访问令牌token 等CloudsmithAccessToken获取 Cloudsmith 访问令牌token 等Password生成随机密码password或secretKeys指定的多个键SSHKey生成 RSA/ECDSA SSH 密钥对私钥、公钥、指纹等STSSessionToken通过 AWS STS 生成临时会话令牌accessKeyId、secretAccessKey、sessionToken 等UUID生成 UUIDuuid 等VaultDynamicSecret从 HashiCorp Vault 获取动态密钥由 Vault 后端决定Webhook调用外部 HTTP 接口获取值由接口返回决定Grafana生成 Grafana 服务账号令牌token 等MFA生成多因素认证相关值由配置决定BeyondtrustWorkloadCredentialsDynamicSecret从 BeyondTrust Workload Credentials 获取动态密钥由配置决定Fake返回spec.data中硬编码的键值对仅用于调试与测试自定义每个生成器的详细参数与示例见 docs/api/generator 目录下对应的独立文档如 password.md、ecr.md、cluster.md。集群级生成器ClusterGeneratorClusterGenerator是生成器的集群级包装wrapper其价值在于一次定义、全集群复用用户无需在每个命名空间里重复定义相同的生成器只需在集群中定义一次即可被任意命名空间中的ExternalSecret通过generatorRef引用。需要注意一个重要限制原文明确指出当前版本的ClusterGenerator只负责在集群范围内定位生成器并不意味着生成器可以在所有命名空间中创建资源——它仍然只在引用它的ExternalSecret所在的命名空间中创建资源。定义ClusterGenerator的配置如下apiVersion: generators.external-secrets.io/v1alpha1 kind: ClusterGenerator metadata: name: my-generator spec: kind: Password generator: passwordSpec: length: 42 digits: 5 symbols: 5 symbolCharacters: -_$ noUpper: false allowRepeat: true对应仓库中的实际示例可见 docs/snippets/generator-cluster.yaml。ClusterGeneratorSpec在 apis/generators/v1alpha1/types_cluster.go 中定义只有两个字段字段说明spec.kind内嵌生成器的类型必须与 Generator 的 kind 精确匹配GeneratorKind枚举spec.generator内嵌生成器的完整 spec必须与kind对应cluster.md 还补充了两条限制说明生成器依旧在引用它的ExternalSecret所在命名空间内创建对象该行为在未来版本中可能调整ClusterGenerator内引用的其他对象如 Secret 引用也必须与引用它的ExternalSecret位于同一命名空间这源于内嵌生成器类型本质上的命名空间作用域特性。GeneratorSpec 支持的全部字段ClusterGenerator的spec.generator本质上是GeneratorSpec结构体其中每个字段对应一种生成器的 spec且同一时刻只能设置其中一个apis/generators/v1alpha1/types_cluster.go 中带有MaxProperties1/MinProperties1的校验约束。完整字段如下对应原文中的 Go 定义type GeneratorSpec struct { ACRAccessTokenSpec *ACRAccessTokenSpec json:acrAccessTokenSpec,omitempty BeyondtrustWorkloadCredentialsDynamicSecretSpec *BeyondtrustWorkloadCredentialsDynamicSecretSpec json:beyondtrustWorkloadCredentialsDynamicSecretSpec,omitempty CloudsmithAccessTokenSpec *CloudsmithAccessTokenSpec json:cloudsmithAccessTokenSpec,omitempty ECRAuthorizationTokenSpec *ECRAuthorizationTokenSpec json:ecrAuthorizationTokenSpec,omitempty FakeSpec *FakeSpec json:fakeSpec,omitempty GCRAccessTokenSpec *GCRAccessTokenSpec json:gcrAccessTokenSpec,omitempty GithubAccessTokenSpec *GithubAccessTokenSpec json:githubAccessTokenSpec,omitempty GitlabDeployTokenSpec *GitlabDeployTokenSpec json:gitlabDeployTokenSpec,omitempty QuayAccessTokenSpec *QuayAccessTokenSpec json:quayAccessTokenSpec,omitempty PasswordSpec *PasswordSpec json:passwordSpec,omitempty SSHKeySpec *SSHKeySpec json:sshKeySpec,omitempty STSSessionTokenSpec *STSSessionTokenSpec json:stsSessionTokenSpec,omitempty UUIDSpec *UUIDSpec json:uuidSpec,omitempty VaultDynamicSecretSpec *VaultDynamicSecretSpec json:vaultDynamicSecretSpec,omitempty WebhookSpec *WebhookSpec json:webhookSpec,omitempty GrafanaSpec *GrafanaSpec json:grafanaSpec,omitempty MFASpec *MFASpec json:mfaSpec,omitempty }对照可见所有 Namespaced 作用域的生成器都可以原样嵌入ClusterGeneratorSpec使用JSON 标签即 YAML 中generator下的字段名如passwordSpec、fakeSpec、webhookSpec。深入生成器参数以 Password 为例为了说明生成器 spec 的参数体系这里以最常用的Password生成器为例展开。apis/generators/v1alpha1/types_password.go 中的PasswordSpec定义了以下参数及默认值参数默认值说明length24生成密码的长度kubebuilder 默认值 24digits长度的 25%密码中数字字符的个数省略时按长度 25% 计算symbols长度的 25%密码中符号字符的个数省略时按长度 25% 计算symbolCharacters~!#$%^*()_-{}\|[]\\:?,./生成密码时使用的符号字符集noUpperfalse设为true时禁用大写字母allowRepeatfalse设为true时允许字符重复secretKeys[password]输出键列表每个键填充一个独立的随机密码键必须非空且唯一encodingraw输出编码格式合法值raw、base64、base64url、base32、hex其中encoding枚举在源码中有明确的 OpenAPI 校验Enumbase64;base64url;base32;hex;raw。对同一个密码TestPass??word各编码输出如下详见 password.mdraw默认TestPass??word原始字符串base64VGVzdD4UGFzcz8/d29yZA标准 Base64含、/、填充base64urlVGVzdD4-UGFzcz8_d29yZAURL 安全 Base64-、_替代、/仍保留填充base32ORSXG5BRGIYTEMJQGQYQBase32 编码hex546573743e3e506173733f3f776f7264十六进制编码一次生成多个密码若希望单个KindSecret中同时包含多个独立密码可在spec.secretKeys中列出多个输出键每个键都会被填充一个独有的随机密码。参考 docs/snippets/generator-password-multiple-keys.yamlapiVersion: generators.external-secrets.io/v1alpha1 kind: Password metadata: name: multiple-passwords spec: length: 36 secretKeys: - key1 - key2 --- apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: auth-secrets spec: refreshInterval: 30m target: name: auth-secrets dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: Password name: multiple-passwords最终生成的 Secret 将同时包含key1与key2两个键各自持有不同的密码length、symbols、encoding等参数对所有键统一生效。若只是想把单个键改名而非生成多个更推荐的做法是配合dataFrom的rewrite能力source: password,target: your-key参见 datafrom-rewrite 指南。生成结果示例使用默认参数生成 24 位密码时实际产出类似2CpO*8x6sdwM!74G_gUz5 -MSe#n24K|h5A6q9Yv7Cj ZRv-k!y6x/V29:43aErSf$1使用 42 位长度、symbolCharacters: -_$的配置即上文ClusterGenerator示例时产出类似RMngCHKtZh3aja$WZDuDVhkCkN48JBa9OF8jH$R VB$pX8SSUMIlk9K8gXxJAhGz$0$ktbJ1ArMukg-bD注意密码是完全随机化的存在生成结果不符合应用期望字符集的可能请在应用中做好兼容。其他代表性生成器速览ECRAuthorizationToken通过 AWSGetAuthorizationTokenAPI 获取授权令牌令牌有效期 12 小时。产出username、password、proxy_endpoint、expires_atUNIX 时间戳四个键可用于docker login支持静态凭据spec.auth.secretRef、IRSA Service Accountspec.auth.jwt以及控制器环境的 SDK 默认凭据链三种认证方式见 ecr.md。Fake直接原样返回spec.data中硬编码的键值对定位是调试与测试场景见 fake.md 与 docs/snippets/generator-fake.yamlapiVersion: generators.external-secrets.io/v1alpha1 kind: Fake metadata: name: fake-key spec: data: foo: bar baz: bangUUID、SSHKey、STS 等分别用于生成 UUID、SSH 密钥对支持 RSA/ECDSA 与编码示例见 docs/snippets/generator-sshkey-example.yaml和 AWS STS 临时会话令牌参数细节可查阅 docs/api/generator 下对应文档及 tests 中的测试清单。生成器与模板、重写的组合使用生成器产出的值与其他来源的密钥值地位相同因此可以直接与template模板组合。例如在ExternalSecret的dataFrom中引用生成器后再通过spec.target.template将生成值嵌入 JSON、YAML 或任意文本结构如生成.dockerconfigjson供 imagePullSecret 使用。典型应用包括用ECRAuthorizationToken/GCRAccessToken生成docker login凭据并模板化为imagePullSecret用SSHKey生成部署密钥模板化为 SSHknown_hosts/私钥文件用Password生成数据库口令配合rewrite调整键名后写入 Secret。模板语法细节参见 templating 指南 与 templating-v1键名重写参见 datafrom-rewrite 指南。总结何时使用生成器生成器最适合以下场景应用需要自产自销的随机凭据密码、UUID、SSH 密钥无需接入外部密钥管理服务需要为镜像仓库ECR、GCR、ACR、Quay签发短期访问令牌并注入为imagePullSecret需要从 Vault/Webhook 等外部系统动态获取一次性凭据并通过Cleanup钩子回收资源希望以ClusterGenerator形式在集群内统一声明、按命名空间复用生成器定义。需要清醒认知的是由于生成器每次调用都产出全新值且不追踪历史它适合每次刷新重新生成的语义若需要跨 Secret 共享同一份稳定值则应改用 SecretStore 从外部密钥管理服务拉取而不是依赖生成器。【免费下载链接】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），仅供参考 External Secrets Operator 生成器（Generator）完全指南：通过 DataFrom 与 ClusterGenerator 动态生成 Kubernetes Secret 值
External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成 Kubernetes Secret 值【免费下载链接】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生成器Generator是 External Secrets OperatorESO提供的一组内置值生成能力它允许你在不依赖第三方密钥管理服务的前提下通过ExternalSecret.spec.DataFrom动态生成密码、Token、SSH 密钥、UUID 等值并注入为 Kubernetes Secret。本文将以仓库中的 generator.md 为核心骨架结合 apis/generators/v1alpha1 下的类型定义、generators/v1 下的各生成器实现以及 docs/snippets 中的示例清单系统讲解生成器的引用方式、刷新语义、ClusterGenerator集群级用法与完整参数体系读完你即可在真实集群中配置并复用各类生成器。生成器是什么值的来源而非值的存储从概念上讲生成器负责产出值generate values它通过ExternalSecret的spec.DataFrom被引用引用方式是在dataFrom条目中填写sourceRef.generatorRef。与直接引用密钥存储SecretStore不同生成器不需要访问任何外部密钥管理服务而是按照你定义的spec现场生成一组键值对。有几个关键语义需要先厘清每次调用都产生一组全新的值当ExternalSecret依据spec.refreshInterval触发刷新时生成器以generator.spec作为输入重新生成一份值映射map。生成器本身不追踪、不记忆之前产出的值因此同一个生成器在两次刷新之间产出的值可能完全不同。值不可跨 Secret 共享一个生成器调用产出的值只属于当次调用你不能把同一次生成的结果同时复用到多个ExternalSecret或多个dataFrom[]条目中。生成的值可以继续参与后续加工生成结果与普通拉取到的密钥值一样可以被 ESO 的rewrite重写或template模板化等特性继续处理例如按需修改、编码、解码、打包。这一设计在源码层面体现为Generator接口。在 apis/generators/v1alpha1/generator_interfaces.go 中每个生成器都必须实现两个方法Generate( ctx context.Context, obj *apiextensions.JSON, kube client.Client, namespace string, ) (map[string][]byte, GeneratorProviderState, error) Cleanup( ctx context.Context, obj *apiextensions.JSON, status GeneratorProviderState, kube client.Client, namespace string, ) errorGenerate返回map[string][]byte即密钥名 → 值的映射GeneratorProviderState是可选状态可留待Cleanup阶段使用Cleanup用于删除Generate阶段创建的外部资源且要求幂等资源已被删除时不报错——例如 Webhook、Vault 动态密钥这类生成器可能会在外部系统中创建资源刷新后需要回收。所有生成器通过注册表机制登记在 pkg/register/generators.go 的init()中逐一调用genv1alpha1.Register(kind, generator)注册 ECR、Fake、GCR、GitHub、GitLab、Grafana、MFA、Password、SSHKey、STS、UUID、Vault、Webhook、ACR、BeyondtrustWorkloadCredentials、Cloudsmith、Quay 共 17 个生成器而 apis/generators/v1alpha1/generator_schema.go 中的Register/GetGeneratorByName则实现了按 kind 字符串的查找分发。由此可见生成器本质上是把值从哪里来从密钥存储抽象中解耦出来的一种插件化能力。通过 Custom Resource 引用生成器Reference Custom Resource生成器可以定义为独立的 Custom ResourceCR供多个ExternalSecret复用定义。不过要再次强调定义可以复用产出的值不能复用——每次调用都会生成一组新值。下面的示例引用了一个名为my-ecr的ECRAuthorizationToken生成器将其产出的值通过dataFrom注入到名为ecr-token的 Secret 中apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: ecr-token spec: refreshInterval: 30m0s target: name: ecr-token dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: ECRAuthorizationToken name: my-ecr这里sourceRef.generatorRef需要同时给出三个字段字段取值说明apiVersion生成器 CR 的 API 版本固定为generators.external-secrets.io/v1alpha1kind生成器类型如Password、ECRAuthorizationToken、UUID等必须与生成器 CR 的 kind 精确一致name生成器 CR 的名称指向同命名空间下已创建的生成器对象作为对照docs/snippets/generator-password-example.yaml 给出了引用Password生成器的同构写法tests/password_test.yaml、tests/ecrauthorizationtoken_test.yaml、tests/uuid_test.yaml 等测试文件也验证了各生成器从 CR 定义到 Secret 产出的端到端链路。生成器类型一览generatorRef.kind可用的取值即ClusterGeneratorSpec.Kind枚举也与 apis/generators/v1alpha1/types_cluster.go 中的常量一一对应。当前仓库支持以下生成器kind功能概要典型产出键ACRAccessToken获取 Azure Container Registry 访问令牌token 等ECRAuthorizationToken调用 AWSGetAuthorizationToken获取 ECR 授权令牌有效期 12 小时username、password、proxy_endpoint、expires_atGCRAccessToken获取 Google Container Registry 访问令牌token 等GithubAccessToken生成 GitHub 访问令牌token 等GitlabDeployToken生成 GitLab Deploy Tokenusername、password、token 等QuayAccessToken获取 Quay 访问令牌token 等CloudsmithAccessToken获取 Cloudsmith 访问令牌token 等Password生成随机密码password或secretKeys指定的多个键SSHKey生成 RSA/ECDSA SSH 密钥对私钥、公钥、指纹等STSSessionToken通过 AWS STS 生成临时会话令牌accessKeyId、secretAccessKey、sessionToken 等UUID生成 UUIDuuid 等VaultDynamicSecret从 HashiCorp Vault 获取动态密钥由 Vault 后端决定Webhook调用外部 HTTP 接口获取值由接口返回决定Grafana生成 Grafana 服务账号令牌token 等MFA生成多因素认证相关值由配置决定BeyondtrustWorkloadCredentialsDynamicSecret从 BeyondTrust Workload Credentials 获取动态密钥由配置决定Fake返回spec.data中硬编码的键值对仅用于调试与测试自定义每个生成器的详细参数与示例见 docs/api/generator 目录下对应的独立文档如 password.md、ecr.md、cluster.md。集群级生成器ClusterGeneratorClusterGenerator是生成器的集群级包装wrapper其价值在于一次定义、全集群复用用户无需在每个命名空间里重复定义相同的生成器只需在集群中定义一次即可被任意命名空间中的ExternalSecret通过generatorRef引用。需要注意一个重要限制原文明确指出当前版本的ClusterGenerator只负责在集群范围内定位生成器并不意味着生成器可以在所有命名空间中创建资源——它仍然只在引用它的ExternalSecret所在的命名空间中创建资源。定义ClusterGenerator的配置如下apiVersion: generators.external-secrets.io/v1alpha1 kind: ClusterGenerator metadata: name: my-generator spec: kind: Password generator: passwordSpec: length: 42 digits: 5 symbols: 5 symbolCharacters: -_$ noUpper: false allowRepeat: true对应仓库中的实际示例可见 docs/snippets/generator-cluster.yaml。ClusterGeneratorSpec在 apis/generators/v1alpha1/types_cluster.go 中定义只有两个字段字段说明spec.kind内嵌生成器的类型必须与 Generator 的 kind 精确匹配GeneratorKind枚举spec.generator内嵌生成器的完整 spec必须与kind对应cluster.md 还补充了两条限制说明生成器依旧在引用它的ExternalSecret所在命名空间内创建对象该行为在未来版本中可能调整ClusterGenerator内引用的其他对象如 Secret 引用也必须与引用它的ExternalSecret位于同一命名空间这源于内嵌生成器类型本质上的命名空间作用域特性。GeneratorSpec 支持的全部字段ClusterGenerator的spec.generator本质上是GeneratorSpec结构体其中每个字段对应一种生成器的 spec且同一时刻只能设置其中一个apis/generators/v1alpha1/types_cluster.go 中带有MaxProperties1/MinProperties1的校验约束。完整字段如下对应原文中的 Go 定义type GeneratorSpec struct { ACRAccessTokenSpec *ACRAccessTokenSpec json:acrAccessTokenSpec,omitempty BeyondtrustWorkloadCredentialsDynamicSecretSpec *BeyondtrustWorkloadCredentialsDynamicSecretSpec json:beyondtrustWorkloadCredentialsDynamicSecretSpec,omitempty CloudsmithAccessTokenSpec *CloudsmithAccessTokenSpec json:cloudsmithAccessTokenSpec,omitempty ECRAuthorizationTokenSpec *ECRAuthorizationTokenSpec json:ecrAuthorizationTokenSpec,omitempty FakeSpec *FakeSpec json:fakeSpec,omitempty GCRAccessTokenSpec *GCRAccessTokenSpec json:gcrAccessTokenSpec,omitempty GithubAccessTokenSpec *GithubAccessTokenSpec json:githubAccessTokenSpec,omitempty GitlabDeployTokenSpec *GitlabDeployTokenSpec json:gitlabDeployTokenSpec,omitempty QuayAccessTokenSpec *QuayAccessTokenSpec json:quayAccessTokenSpec,omitempty PasswordSpec *PasswordSpec json:passwordSpec,omitempty SSHKeySpec *SSHKeySpec json:sshKeySpec,omitempty STSSessionTokenSpec *STSSessionTokenSpec json:stsSessionTokenSpec,omitempty UUIDSpec *UUIDSpec json:uuidSpec,omitempty VaultDynamicSecretSpec *VaultDynamicSecretSpec json:vaultDynamicSecretSpec,omitempty WebhookSpec *WebhookSpec json:webhookSpec,omitempty GrafanaSpec *GrafanaSpec json:grafanaSpec,omitempty MFASpec *MFASpec json:mfaSpec,omitempty }对照可见所有 Namespaced 作用域的生成器都可以原样嵌入ClusterGeneratorSpec使用JSON 标签即 YAML 中generator下的字段名如passwordSpec、fakeSpec、webhookSpec。深入生成器参数以 Password 为例为了说明生成器 spec 的参数体系这里以最常用的Password生成器为例展开。apis/generators/v1alpha1/types_password.go 中的PasswordSpec定义了以下参数及默认值参数默认值说明length24生成密码的长度kubebuilder 默认值 24digits长度的 25%密码中数字字符的个数省略时按长度 25% 计算symbols长度的 25%密码中符号字符的个数省略时按长度 25% 计算symbolCharacters~!#$%^*()_-{}\|[]\\:?,./生成密码时使用的符号字符集noUpperfalse设为true时禁用大写字母allowRepeatfalse设为true时允许字符重复secretKeys[password]输出键列表每个键填充一个独立的随机密码键必须非空且唯一encodingraw输出编码格式合法值raw、base64、base64url、base32、hex其中encoding枚举在源码中有明确的 OpenAPI 校验Enumbase64;base64url;base32;hex;raw。对同一个密码TestPass??word各编码输出如下详见 password.mdraw默认TestPass??word原始字符串base64VGVzdD4UGFzcz8/d29yZA标准 Base64含、/、填充base64urlVGVzdD4-UGFzcz8_d29yZAURL 安全 Base64-、_替代、/仍保留填充base32ORSXG5BRGIYTEMJQGQYQBase32 编码hex546573743e3e506173733f3f776f7264十六进制编码一次生成多个密码若希望单个KindSecret中同时包含多个独立密码可在spec.secretKeys中列出多个输出键每个键都会被填充一个独有的随机密码。参考 docs/snippets/generator-password-multiple-keys.yamlapiVersion: generators.external-secrets.io/v1alpha1 kind: Password metadata: name: multiple-passwords spec: length: 36 secretKeys: - key1 - key2 --- apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: auth-secrets spec: refreshInterval: 30m target: name: auth-secrets dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: Password name: multiple-passwords最终生成的 Secret 将同时包含key1与key2两个键各自持有不同的密码length、symbols、encoding等参数对所有键统一生效。若只是想把单个键改名而非生成多个更推荐的做法是配合dataFrom的rewrite能力source: password,target: your-key参见 datafrom-rewrite 指南。生成结果示例使用默认参数生成 24 位密码时实际产出类似2CpO*8x6sdwM!74G_gUz5 -MSe#n24K|h5A6q9Yv7Cj ZRv-k!y6x/V29:43aErSf$1使用 42 位长度、symbolCharacters: -_$的配置即上文ClusterGenerator示例时产出类似RMngCHKtZh3aja$WZDuDVhkCkN48JBa9OF8jH$R VB$pX8SSUMIlk9K8gXxJAhGz$0$ktbJ1ArMukg-bD注意密码是完全随机化的存在生成结果不符合应用期望字符集的可能请在应用中做好兼容。其他代表性生成器速览ECRAuthorizationToken通过 AWSGetAuthorizationTokenAPI 获取授权令牌令牌有效期 12 小时。产出username、password、proxy_endpoint、expires_atUNIX 时间戳四个键可用于docker login支持静态凭据spec.auth.secretRef、IRSA Service Accountspec.auth.jwt以及控制器环境的 SDK 默认凭据链三种认证方式见 ecr.md。Fake直接原样返回spec.data中硬编码的键值对定位是调试与测试场景见 fake.md 与 docs/snippets/generator-fake.yamlapiVersion: generators.external-secrets.io/v1alpha1 kind: Fake metadata: name: fake-key spec: data: foo: bar baz: bangUUID、SSHKey、STS 等分别用于生成 UUID、SSH 密钥对支持 RSA/ECDSA 与编码示例见 docs/snippets/generator-sshkey-example.yaml和 AWS STS 临时会话令牌参数细节可查阅 docs/api/generator 下对应文档及 tests 中的测试清单。生成器与模板、重写的组合使用生成器产出的值与其他来源的密钥值地位相同因此可以直接与template模板组合。例如在ExternalSecret的dataFrom中引用生成器后再通过spec.target.template将生成值嵌入 JSON、YAML 或任意文本结构如生成.dockerconfigjson供 imagePullSecret 使用。典型应用包括用ECRAuthorizationToken/GCRAccessToken生成docker login凭据并模板化为imagePullSecret用SSHKey生成部署密钥模板化为 SSHknown_hosts/私钥文件用Password生成数据库口令配合rewrite调整键名后写入 Secret。模板语法细节参见 templating 指南 与 templating-v1键名重写参见 datafrom-rewrite 指南。总结何时使用生成器生成器最适合以下场景应用需要自产自销的随机凭据密码、UUID、SSH 密钥无需接入外部密钥管理服务需要为镜像仓库ECR、GCR、ACR、Quay签发短期访问令牌并注入为imagePullSecret需要从 Vault/Webhook 等外部系统动态获取一次性凭据并通过Cleanup钩子回收资源希望以ClusterGenerator形式在集群内统一声明、按命名空间复用生成器定义。需要清醒认知的是由于生成器每次调用都产出全新值且不追踪历史它适合每次刷新重新生成的语义若需要跨 Secret 共享同一份稳定值则应改用 SecretStore 从外部密钥管理服务拉取而不是依赖生成器。【免费下载链接】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），仅供参考