Table of Contents【免费下载链接】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// autogen please这里的 !-- toc -- 与 !-- /toc -- 是自动化工具的锚点用于在 PR 提交时自动生成或更新目录避免手工维护目录带来的漂移。已实现提案如 [001-design-crd-v1beta1.md](https://link.gitcode.com/i/8fb8fb3c6c0ae7edd70a534f9c40c493)中可以看到最终生成的带锚点链接目录效果。 ## 三、Summary 与 Motivation说清楚做什么与为什么做 ### 3.1 Summary一段话讲清提案全貌 模板要求 Please provide a summary of this proposal. 这一节用一两段话概括提案要解决什么问题、核心思路是什么。看真实范例 [002-pushsecret.md](https://link.gitcode.com/i/2911b0a899d205187b998b0e230af143) The Secret Sink is a feature to allow Secrets from Kubernetes to be saved back into some providers. Where ExternalSecret is responsible to download a Secret from a Provider into Kubernetes (as a K8s Secret), PushSecret will upload a Kubernetes Secret to a Provider. 短短两句话就把反向同步这一核心定位讲清楚了ExternalSecret 负责从 Provider 下载到 KubernetesPushSecret 则负责把 Kubernetes Secret 上传回 Provider——读者立刻能建立对功能在大局中的坐标认知。 ### 3.2 Motivation阐述价值与适用场景 模板要求 What is the motivation of this proposal? Why is it useful and relevant? 以 PushSecret 为例[002-pushsecret.md](https://link.gitcode.com/i/15c5884ace6b2dae898040236fc6fab3)动机写了两个具体场景 - 让集群内生成的 Secret如各类生成器产生的 Secret也能同步到外部 Secret Provider实现双向可用 - 让同一个 Secret 同时存在于多个 Provider从而在某个 Provider 宕机或被攻破时实现故障切换failover。 这种写法值得借鉴**动机要落到真实用户场景上而不是抽象的口号**。随后在 Goals 与 Non-Goals 中进一步收窄边界 markdown ### Goals - CRD Design for the SecretSink - Define the need for a SinkStore ### Non-Goals Do not implement full compatibility mechanisms with each provider (we are not Terraform neither Crossplane)Goals 列出要达成什么Non-Goals 明确明确不做、不做全量兼容。后者尤为重要——ESO 在提案阶段就划清了与 Terraform、Crossplane 这类基础设施编排工具的边界避免功能无边界膨胀。四、Proposal提案核心回答怎么做Proposal 是整个模板篇幅最大、技术含量最高的部分模板将其细分为 User Stories、API、Behavior、Drawbacks、Acceptance Criteria 五个子章节。4.1 User Stories从用户视角描述需求模板要求How would users use this feature, what are their needs?用作为……我想要……以便……的用户故事句式从使用者视角罗列需求。PushSecret 提案写了两个用户故事002-pushsecret.md作为 ESO 运维者我希望将集群内的 Secret 与外部 Provider 同步作为 ESO 运维者我希望即使 Secret 没有绑定任何 ExternalSecret也能被同步。第二点直接定义了 PushSecret 独立于 ExternalSecret 存在的必要性为后面的 CRD 设计提供了需求依据。4.2 API给出 CRD 设计草案与示例 YAML模板要求Please describe the API (CRD or other) and show some examples.这是提案中最硬核的部分需要给出完整的 YAML 示例。PushSecret 提案给出了两类 API 示例一是 SecretStore 的扩展草案展示各 Provider 需要补充的写侧sink配置。以 AWS 为例002-pushsecret.mdapiVersion: external-secrets.io/v1alpha1 kind: SecretStore metadata: name: example namespace: example-ns spec: controller: dev retrySettings: maxRetries: 5 retryInterval: 10s provider: aws: service: SecretsManager role: iam-role region: eu-central-1 encryptionConfig: {} # Specific config for Creating Secrets on AWS auth: secretRef: accessKeyID: name: awssm-secret key: access-key secretAccessKey: name: awssm-secret key: secret-access-key同一个示例还涵盖了 Vault含tokenSecretRef、appRole、kubernetes多种认证方式与caProvider证书配置和 GCP Secret ManagerprojectID与secretAccessKeySecretRef的写法完整展示了多 Provider 下写能力配置的通用形态。二是 PushSecret 自定义资源的草案002-pushsecret.mdapiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: hello-world namespace: my-ns # Same of the SecretStores spec: secretStoreRefs: - name: secret-store kind: SecretStore - name: cluster-secret-store kind: ClusterSecretStore refreshInterval: 1h selector: secret: name: foobar data: - match: secretKey: foobar remoteRefs: - remoteKey: my/path/foobar property: my-property #optional. To allow coming back from a dataFrom rewrite: secretKey: game-(.).(.) remoteRefs: - remoteKey: my/path/($1) property: prop-($2) status: refreshTime: 2019-08-12T12:33:02Z conditions: - type: Ready status: True reason: SecretSynced message: Secret was synced #Fully synced这个示例已经勾勒出后来真实实现的几乎所有核心概念多 SecretStore 引用secretStoreRefs、刷新周期refreshInterval、源 Secret 选择selector、键匹配与远程键重写match/rewrite支持正则捕获组($1)、($2)、以及带conditions的 status 结构。注意 YAML 里作者还贴心地用# Same of the SecretStores、#optional这样的注释标注关键约束——在提案中为 YAML 写清注释是提高评审效率的实用技巧。4.3 Behavior描述运行时行为与边界情况模板要求How should the new CRD or feature behave? Are there edge cases?PushSecret 提案的 Behavior 一节002-pushsecret.md描述了三条关键行为规则检查源 Secret 上已有的 SecretStore 引用标签——如果该引用存在于 PushSecret 的 SecretStore 列表中则发出SecretSyncError因为不能把 Secret 同步回它来源的那个 SecretStore防止回环若 SecretStores 均正常或 Secret 没有标签由用户或其他工具创建则对每个 SecretStore 获取其同步状态New、SecretSynced、SecretSyncedErr若是新 Secret或SecretSynced状态且 refreshInterval 已过期则从 secretStore 拉取远端 Secret 比对内容不一致则创建新 Secret尽可能提升版本号出错则发出SecretSyncedErr。这些描述直接对应了模板对边界情况的要求并且可以在最终实现的源码中找到印证——在 pushsecret_types.go 中定义了ReasonSynced、ReasonErrored、ReasonSourceDeleted三个条件原因常量以及在 apis/externalsecrets/v1alpha1/pushsecret_types.go 中定义的PushSecretStoreRef结构含Name、LabelSelector、Kind字段Kind限定为SecretStore或ClusterSecretStore。提案中的行为设计到最终源码常量、字段的一一对应正是这套流程价值的直接体现。4.4 Drawbacks诚实评估方案的代价模板要求If we implement this feature, what are drawbacks and disadvantages of this approach?PushSecret 提案的 Drawbacks 写得非常坦诚002-pushsecret.md列出了三点讨论过程中发现若拆成两个独立 CRD会存在大量重复字段该方案意味着 SecretStore 需要具备写入能力且没有其他替代机制可能加重协调循环reconciliation loop负担因为 1×N 的 Secret 同步大多发生在集群之外跨网络。这种自曝其短的写法看似吃亏实则是社区评审中最受信任的部分——它表明作者考虑过方案的真实成本也帮助评审者聚焦在可接受这些代价的前提下做决策。4.5 Acceptance Criteria定义生产就绪的验收标准模板对这一节给出了非常详细的思考清单What does it take to make this feature producation ready? Please take the time to think about:how would you rollout this feature and rollback if it causes harm?Test Roadmap: what kinds of tests do we want to ensure a good user experience?observability: Do users need to get insights into the inner workings of that feature?monitoring: How can users tell whether the feature is working as expected or not? can we provide dashboards, metrics, reasonable SLIs/SLOs or example alerts for this feature?troubleshooting: How would users want to troubleshoot this particular feature? Think about different failure modes of this feature.翻译过来验收标准至少要覆盖五个维度维度要回答的问题发布与回滚如何灰度上线如果造成危害如何回滚测试路线图需要哪些层级的测试单元、集成、e2e来保证体验可观测性observability用户能否洞察该功能内部运行情况监控monitoring用户如何判断功能是否按预期工作能否提供 Dashboard、指标、合理的 SLI/SLO 或告警示例故障排查troubleshooting用户如何排查该功能要考虑不同的失败模式。PushSecret 提案给出的验收标准简洁而具体002-pushsecret.md ExternalSecrets create appropriate labels on generated Secrets PushSecrets can read labels on source Secrets PushSecrets cannot have same references to SecretStores PushSecrets respect refreshInterval【免费下载链接】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），仅供参考
Table of Contents
Table of Contents【免费下载链接】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// autogen please这里的 !-- toc -- 与 !-- /toc -- 是自动化工具的锚点用于在 PR 提交时自动生成或更新目录避免手工维护目录带来的漂移。已实现提案如 [001-design-crd-v1beta1.md](https://link.gitcode.com/i/8fb8fb3c6c0ae7edd70a534f9c40c493)中可以看到最终生成的带锚点链接目录效果。 ## 三、Summary 与 Motivation说清楚做什么与为什么做 ### 3.1 Summary一段话讲清提案全貌 模板要求 Please provide a summary of this proposal. 这一节用一两段话概括提案要解决什么问题、核心思路是什么。看真实范例 [002-pushsecret.md](https://link.gitcode.com/i/2911b0a899d205187b998b0e230af143) The Secret Sink is a feature to allow Secrets from Kubernetes to be saved back into some providers. Where ExternalSecret is responsible to download a Secret from a Provider into Kubernetes (as a K8s Secret), PushSecret will upload a Kubernetes Secret to a Provider. 短短两句话就把反向同步这一核心定位讲清楚了ExternalSecret 负责从 Provider 下载到 KubernetesPushSecret 则负责把 Kubernetes Secret 上传回 Provider——读者立刻能建立对功能在大局中的坐标认知。 ### 3.2 Motivation阐述价值与适用场景 模板要求 What is the motivation of this proposal? Why is it useful and relevant? 以 PushSecret 为例[002-pushsecret.md](https://link.gitcode.com/i/15c5884ace6b2dae898040236fc6fab3)动机写了两个具体场景 - 让集群内生成的 Secret如各类生成器产生的 Secret也能同步到外部 Secret Provider实现双向可用 - 让同一个 Secret 同时存在于多个 Provider从而在某个 Provider 宕机或被攻破时实现故障切换failover。 这种写法值得借鉴**动机要落到真实用户场景上而不是抽象的口号**。随后在 Goals 与 Non-Goals 中进一步收窄边界 markdown ### Goals - CRD Design for the SecretSink - Define the need for a SinkStore ### Non-Goals Do not implement full compatibility mechanisms with each provider (we are not Terraform neither Crossplane)Goals 列出要达成什么Non-Goals 明确明确不做、不做全量兼容。后者尤为重要——ESO 在提案阶段就划清了与 Terraform、Crossplane 这类基础设施编排工具的边界避免功能无边界膨胀。四、Proposal提案核心回答怎么做Proposal 是整个模板篇幅最大、技术含量最高的部分模板将其细分为 User Stories、API、Behavior、Drawbacks、Acceptance Criteria 五个子章节。4.1 User Stories从用户视角描述需求模板要求How would users use this feature, what are their needs?用作为……我想要……以便……的用户故事句式从使用者视角罗列需求。PushSecret 提案写了两个用户故事002-pushsecret.md作为 ESO 运维者我希望将集群内的 Secret 与外部 Provider 同步作为 ESO 运维者我希望即使 Secret 没有绑定任何 ExternalSecret也能被同步。第二点直接定义了 PushSecret 独立于 ExternalSecret 存在的必要性为后面的 CRD 设计提供了需求依据。4.2 API给出 CRD 设计草案与示例 YAML模板要求Please describe the API (CRD or other) and show some examples.这是提案中最硬核的部分需要给出完整的 YAML 示例。PushSecret 提案给出了两类 API 示例一是 SecretStore 的扩展草案展示各 Provider 需要补充的写侧sink配置。以 AWS 为例002-pushsecret.mdapiVersion: external-secrets.io/v1alpha1 kind: SecretStore metadata: name: example namespace: example-ns spec: controller: dev retrySettings: maxRetries: 5 retryInterval: 10s provider: aws: service: SecretsManager role: iam-role region: eu-central-1 encryptionConfig: {} # Specific config for Creating Secrets on AWS auth: secretRef: accessKeyID: name: awssm-secret key: access-key secretAccessKey: name: awssm-secret key: secret-access-key同一个示例还涵盖了 Vault含tokenSecretRef、appRole、kubernetes多种认证方式与caProvider证书配置和 GCP Secret ManagerprojectID与secretAccessKeySecretRef的写法完整展示了多 Provider 下写能力配置的通用形态。二是 PushSecret 自定义资源的草案002-pushsecret.mdapiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: hello-world namespace: my-ns # Same of the SecretStores spec: secretStoreRefs: - name: secret-store kind: SecretStore - name: cluster-secret-store kind: ClusterSecretStore refreshInterval: 1h selector: secret: name: foobar data: - match: secretKey: foobar remoteRefs: - remoteKey: my/path/foobar property: my-property #optional. To allow coming back from a dataFrom rewrite: secretKey: game-(.).(.) remoteRefs: - remoteKey: my/path/($1) property: prop-($2) status: refreshTime: 2019-08-12T12:33:02Z conditions: - type: Ready status: True reason: SecretSynced message: Secret was synced #Fully synced这个示例已经勾勒出后来真实实现的几乎所有核心概念多 SecretStore 引用secretStoreRefs、刷新周期refreshInterval、源 Secret 选择selector、键匹配与远程键重写match/rewrite支持正则捕获组($1)、($2)、以及带conditions的 status 结构。注意 YAML 里作者还贴心地用# Same of the SecretStores、#optional这样的注释标注关键约束——在提案中为 YAML 写清注释是提高评审效率的实用技巧。4.3 Behavior描述运行时行为与边界情况模板要求How should the new CRD or feature behave? Are there edge cases?PushSecret 提案的 Behavior 一节002-pushsecret.md描述了三条关键行为规则检查源 Secret 上已有的 SecretStore 引用标签——如果该引用存在于 PushSecret 的 SecretStore 列表中则发出SecretSyncError因为不能把 Secret 同步回它来源的那个 SecretStore防止回环若 SecretStores 均正常或 Secret 没有标签由用户或其他工具创建则对每个 SecretStore 获取其同步状态New、SecretSynced、SecretSyncedErr若是新 Secret或SecretSynced状态且 refreshInterval 已过期则从 secretStore 拉取远端 Secret 比对内容不一致则创建新 Secret尽可能提升版本号出错则发出SecretSyncedErr。这些描述直接对应了模板对边界情况的要求并且可以在最终实现的源码中找到印证——在 pushsecret_types.go 中定义了ReasonSynced、ReasonErrored、ReasonSourceDeleted三个条件原因常量以及在 apis/externalsecrets/v1alpha1/pushsecret_types.go 中定义的PushSecretStoreRef结构含Name、LabelSelector、Kind字段Kind限定为SecretStore或ClusterSecretStore。提案中的行为设计到最终源码常量、字段的一一对应正是这套流程价值的直接体现。4.4 Drawbacks诚实评估方案的代价模板要求If we implement this feature, what are drawbacks and disadvantages of this approach?PushSecret 提案的 Drawbacks 写得非常坦诚002-pushsecret.md列出了三点讨论过程中发现若拆成两个独立 CRD会存在大量重复字段该方案意味着 SecretStore 需要具备写入能力且没有其他替代机制可能加重协调循环reconciliation loop负担因为 1×N 的 Secret 同步大多发生在集群之外跨网络。这种自曝其短的写法看似吃亏实则是社区评审中最受信任的部分——它表明作者考虑过方案的真实成本也帮助评审者聚焦在可接受这些代价的前提下做决策。4.5 Acceptance Criteria定义生产就绪的验收标准模板对这一节给出了非常详细的思考清单What does it take to make this feature producation ready? Please take the time to think about:how would you rollout this feature and rollback if it causes harm?Test Roadmap: what kinds of tests do we want to ensure a good user experience?observability: Do users need to get insights into the inner workings of that feature?monitoring: How can users tell whether the feature is working as expected or not? can we provide dashboards, metrics, reasonable SLIs/SLOs or example alerts for this feature?troubleshooting: How would users want to troubleshoot this particular feature? Think about different failure modes of this feature.翻译过来验收标准至少要覆盖五个维度维度要回答的问题发布与回滚如何灰度上线如果造成危害如何回滚测试路线图需要哪些层级的测试单元、集成、e2e来保证体验可观测性observability用户能否洞察该功能内部运行情况监控monitoring用户如何判断功能是否按预期工作能否提供 Dashboard、指标、合理的 SLI/SLO 或告警示例故障排查troubleshooting用户如何排查该功能要考虑不同的失败模式。PushSecret 提案给出的验收标准简洁而具体002-pushsecret.md ExternalSecrets create appropriate labels on generated Secrets PushSecrets can read labels on source Secrets PushSecrets cannot have same references to SecretStores PushSecrets respect refreshInterval【免费下载链接】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），仅供参考