测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载导读本文围绕 OpenShiftOrigin仓库中的设计提案文档 secret-annotation-new-app.md 展开深入讲解如何让 Source Build 在克隆私有源代码仓库时通过 Secret 上的一组约定注解build.openshift.io/source-secret-match-uri-*自动发现最相关的既有 Secret 并将其注入为 BuildConfig 的sourceSecret从而免去在oc new-app/oc new-build上继续堆砌新 CLI 参数的负担。读完本文你将掌握该注解模式的完整语法可选通配 URI 模式、相关性判定规则、多 Secret 冲突时的最长匹配优先级算法以及仓库中配套的 e2e 测试如何验证这一注入行为。一、设计动机为什么需要注解驱动的 Secret 发现在 OpenShift 的构建体系中Source Build含 Source-to-Image 与 Docker/Containerfile 构建经常需要从受保护的 Git 仓库拉取源码。传统做法是预先创建好kubernetes.io/basic-auth、kubernetes.io/ssh-auth或 opaque 类型的 Secret在 BuildConfig 的spec.source.sourceSecret字段中显式引用该 Secret通过oc new-app/oc new-build的交互或参数将其绑定。问题在于随着集群中 Secret 数量增长用户在创建 BuildConfig 时往往不知道应该用哪个 Secret且每增加一种认证方式就要扩展 CLI 参数面。本提案对应卡片目标source builds 能够发现相关既有 Secret并在源仓库需要认证时自动尝试使用提出一个更声明式的方案——让 Secret 自己声明它适用于哪些仓库 URI由服务端admission controller在 BuildConfig 创建时自动完成绑定。整个过程不需要修改 CLI 接口符合 OpenShift 一贯的平台侧自动完成配置注入的设计取向。二、核心机制注解前缀与可选通配 URI 模式2.1 约定的注解 Key 前缀提案定义了一个约定俗成的注解 key 前缀build.openshift.io/source-secret-match-uri-*任何一个 Secret 对象都可以携带一条或多条以该前缀开头的注解。为了让注解合法有效每条注解的值都必须是一个可选通配 URI 模式optionally-wildcarded URI pattern其语法定义见下一节。需要特别强调的是注解 key 前缀固定后缀示例中的-1、-2等仅用于区分同一条 Secret 上的多个模式后缀的数值大小对匹配算法没有任何影响详见第五节空模式是非法且无效的它匹配不到任何 URI。2.2 模式语法借鉴 Chrome Match Patterns可选通配 URI 模式的语法被设计为与 Chrome 扩展的 Match Patterns 非常接近目的在于让任何给定 Secret 都能以支持基础通配的方式标注其可用的 URI 集合。该设计被认为在灵活度、直观性、安全性模式本身即约束了 Secret 的使用范围与实现成本之间取得了合适的平衡。提案相对原规范所做的差异调整包括差异点说明不实现all_urls模式避免出现一个模式匹配一切的宽泛授权降低误用风险允许的 scheme 限定为四种仅支持git、http、https、sshscheme 通配符语义*作为 scheme 通配符时匹配以上全部四种 scheme空模式非法且不匹配任何 URI其中第四行特别值得注意*://*.example.com/*这种写法将同时覆盖git://、http://、https://与ssh://四种访问方式方便为同一台服务器同时暴露 HTTP 与 SSH 端点的场景做一次标注。三、Secret 的相关性判定规则一个 Secret 对象对给定的源仓库 URI 而言只有在同时满足以下两个条件时才被视为相关relevant类型匹配访问方式Secret 的 type 必须与访问源仓库所采用的方法一致模式匹配 URI该 Secret 上标注的任意一条可选通配 URI 模式能够匹配源仓库 URI。条件 1 是安全性的关键约束提案明确指出一个basicauthSecret 对通过 SSH 访问的源仓库不相关一个sshauthSecret 对通过非 SSH 方式访问的源仓库不相关。换言之类型不匹配时即使 URI 模式恰好命中该 Secret 也不会被选中防止把用户名密码错误地注入到 SSH 克隆流程或反之。四、多 Secret 冲突最长模式匹配的优先级算法当存在多个相关Secret 时被选中的是其匹配 URI 模式最长的那一个。这一规则让范围更窄、更具体的 Secret 覆盖范围更宽、更通用的 Secret天然支持分环境的覆盖override场景。提案给出了如下示例对于 URIhttps://mydev1.mycorp.com/虽然matches-all-corporate-servers-https-only也相关但override-for-my-dev-servers因为携带了更长的精确匹配模式https://mydev1.mycorp.com/*而被判定为最相关- kind: Secret metadata: name: matches-all-corporate-servers-https-only annotations: build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/* ... - kind: Secret metadata: name: override-for-my-dev-servers annotations: build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/* build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/* ...需要注意上例中注解后缀恰好是数字顺序排列但这跟算法工作方式毫无关系——后缀只是命名空间内的唯一性区分符真正参与比较的是模式字符串本身的长度即匹配的精确度。五、预期使用场景提案明确了三个典型的落地用途批量映射账号凭据将一个或多个sshauth/basicauthSecret 映射到一台或多台承载源码仓库的服务器按服务器域名粒度自动注入对应凭据自动注入自定义 CA 证书将一个或多个 opaque Secret 映射到一台或多台源码服务器用于对目标服务器的 TLS 连接自动使用自定义 CA 证书零 CLI 改动上述能力全部通过注解 admission controller 在服务端完成oc new-app/oc new-build的用户体验与既有命令保持一致无需新增参数。六、仓库源码与测试印证该设计提案并非停留在纸面当前仓库中留有完整的 e2e 测试与测试数据来验证注解驱动 Secret 注入的最终行为。6.1 注入行为的端到端验证测试入口 buildconfigsecretinjector.go 属于[sig-builds][Feature:Builds]套件其核心断言是创建一批 BuildConfig 后分别检查spec.source.sourceSecret.name字段是否被注入预期 Secretbc/test1Git URI 为https://server1.example.com/path应被注入secret1bc/test2Git URI 为ssh://server1.example.com/path应被注入secret2bc/test3Git URI 为https://test.com/path应被注入secret3bc/test4Git URI 为http://test.com/path预期no value即不注入任何 Secret。测试通过oc get bc/testX -o template --template {{.spec.source.sourceSecret.name}}直接读取 BuildConfig 的注入结果证明创建 BuildConfig 时自动补上 sourceSecret 引用是实际生效的平台行为而非文档虚构。6.2 测试数据类型匹配与模式匹配的完整示例配套的清单文件 test-buildconfigsecretinjector.yaml 给出了可直接对照本提案语法的真实用例- kind: Secret apiVersion: v1 type: kubernetes.io/basic-auth metadata: name: secret1 annotations: build.openshift.io/source-secret-match-uri-1: *://*.example.com/* data: username: AA - kind: Secret apiVersion: v1 type: kubernetes.io/ssh-auth metadata: name: secret2 annotations: build.openshift.io/source-secret-match-uri-1: *://*.example.com/* data: ssh-privatekey: AA这份数据恰好演示了类型匹配与模式匹配两个条件缺一不可secret1basic-auth与secret2ssh-auth携带相同的通配模式*://*.example.com/*但test1走 HTTPS只命中 basic-auth 的secret1test2走 SSH只命中 ssh-auth 的secret2——同一个 URI 模式因访问方式不同而选择不同 Secret精确对应提案中basicauth 对 SSH 不相关、sshauth 对非 SSH 不相关的规则。此外secret3使用https://*.com/*精确覆盖https://test.com/path而test4的http://test.com/path因 scheme 不匹配而得不到任何注入进一步验证了 scheme 是模式匹配的参与维度。6.3 手工显式绑定的对照gitauth 测试与自动注入相对照gitauth.go 展示了显式指定 Secret的既有路径测试通过oc new-app -f fixture -p SOURCE_SECRET... -p SOURCE_URL...创建 BuildConfig分别验证HTTPS 场景使用 HTTP tokengithub-http-tokenSSH 场景使用ssh-privatekeygithub-ssh-privatekey并额外覆盖了 SCP 风格 URIgitgithub.com:...。这条测试链路印证了显式 sourceSecret与注解自动发现是并行存在的两条能力也解释了本提案为何强调不增加新的 CLI 参数——因为自动注入走的是 admission controller 侧用户原有的显式绑定方式不受影响。七、关键结论与实践要点声明式发现build.openshift.io/source-secret-match-uri-*让 Secret 自行声明适用范围BuildConfig 创建时由 admission controller 自动注入sourceSecret模式语法借鉴 Chrome Match Patterns但仅允许git/http/https/ssh四种 scheme*scheme 通配覆盖全部四种不实现all_urls空模式非法双重相关性类型basic-auth / ssh-auth / opaque必须匹配访问方式且至少一条 URI 模式命中仓库 URI最长匹配优先多个相关 Secret 并存时选择匹配模式最长者实现精确覆盖宽泛的覆盖能力注解后缀编号不参与比较三大用途sshauth/basicauth 按服务器批量映射、opaque Secret 自动携带自定义 CA 证书做 TLS 连接、全程无需改动oc new-app/oc new-buildCLI仓库验证e2e 测试 buildconfigsecretinjector.go 及其 测试数据 完整验证了注入结果与类型/模式匹配规则gitauth.go 则保留了显式绑定的对照路径。如需进一步了解 OpenShift 构建体系的整体设计可继续阅读 docs/builds.md若关注扩展测试的组织方式可参考 test/extended/README.md 与 test/extended/builds/ 目录下的其他用例。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐Velero BSL 证书支持增强基于 Secret 的 caCertRef 机制设计与实践Velero BSL 证书支持增强基于 Secret 的 caCertRef 机制设计与实践 导读 本篇文章深入解析 Velero 项目中 BackupSto云原生灾备存储后端深入解读 EIP-8205基于 EL 系统合约的验证者提款凭据预注册机制深入解读 EIP 8205基于 EL 系统合约的验证者提款凭据预注册机制 导读 EIP 8205Withdrawal credentials preregi区块链文档Web3深入解析UE4SSHook注册与注销机制的设计与实现深入解析UE4SSHook注册与注销机制的设计与实现 引言为何Hook机制是UE4SS的核心 你是否曾在Unreal Engine虚幻引擎简称UE游戏游戏开发逆向工程上一篇3个实战技巧轻松掌握Ganache UI以太坊开发环境定制下一篇Python3-saml安全最佳实践防范常见SAML攻击与漏洞的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考