Kubernetes SIG Security 章程全解横向安全治理边界、四大职能范围与子项目体系【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes 社区仓库中的 sig-security/charter.md 为骨架系统解读 SIG Security安全特别兴趣小组的正式章程这是一个典型的“横向horizontal”SIG不直接拥有任何 Kubernetes 组件代码而是以流程与协作方式横跨所有 SIG 提升项目整体安全性。读完本文你将掌握 SIG Security 的职能边界哪些归它管、哪些明确不属于它、它与 Security Response Committee (SRC) / SIG Auth 等实体的分工以及其子项目创建机制与治理结构并可通过仓库中的 sigs.yaml 与 sig-governance.md 验证章程的实际落地情况。一、章程背景与定位从安全审计工作组到横向 SIGSIG Security 的章程遵循 Kubernetes Charter README 中描述的约定并采用 sig-governance 中规定的角色与组织管理方式。这一点与仓库根目录下的章程模板 sig-charter-template.md 的结构完全一致——所有 Kubernetes SIG 的章程都以此模板为基础。SIG Security 覆盖 Kubernetes 项目的横向安全倡议包括定期的安全审计、漏洞管理流程、跨领域安全文档以及安全社区管理。作为一个以流程为导向的 SIG它不直接拥有 Kubernetes 组件代码。该 SIG 取代了此前的 Security Audit Working Group安全审计工作组转而专注于在所有组件上提升 Kubernetes 项目的安全性。历史渊源Third-Party Security Audit Working GroupSIG Security 成长自 Third-Party Security Audit Working Group该工作组在每次第三方安全审计的生命周期内负责管理。工作组与选定的厂商、Product Security Committee (PSC) 以及 CNCF 紧密合作负责撰写 RFP、遴选厂商并管理厂商与其他 SIG 及领域专家的对接。SIG Security 继承了第三方安全审计的管理职责同时承担更广泛的使命倡导安全相关的结构性或系统性问题与默认配置设置、管理非保密公开的漏洞流程、定义 bug bounty漏洞赏金、编写官方 Kubernetes 加固指南与安全文档并作为 Kubernetes 安全的对外公关联络点。在 sigs.yaml 中可以找到该 SIG 的正式注册信息mission_statement使命宣言SIG Security 采取社区建设的方法为最终用户、项目维护者以及 Kubernetes 项目本身提升安全性。它跨 SIG 协作推进安全相关特性、编写和更新文档并维护惠及所有人的安全流程与工具。labelsecurity用于 GitHub issue/PR 打标签如sig/security。charter_link指向本仓库内的 sig-security/charter.md。二、In scopeSIG Security 的四大核心职能范围章程将“范围内In scope”工作划分为四个清晰的板块这是理解该 SIG 日常运作的关键。2.1 漏洞管理流程Vulnerability Management ProcessSIG Security 与 Kubernetes Security Response Committee (SRC) 协作共同定义漏洞修复与披露的流程具体讨论项包括私有修复与发布流程何时被触发漏洞如何被评级severity rating**bug bounty漏洞赏金**的覆盖范围公告发布后的跟进例如漏洞公开后的额外修复、缓解措施、预防手段或文档更新分销商公告政策例如时间线、加入名单的标准等漏洞在何时、以何种方式、于何处被公告定义支持 Kubernetes 子项目的标准与流程例如 dashboard、ingress-nginx、kops 等。注意章程强调这里是**非保密public/non-embargoed**的漏洞流程管理。私有的、受保密协议约束embargoed的漏洞响应归属 Product Security Committee (PSC)见下文“Out of scope”部分。SIG Security 的职责是定义“公开流程”的规则与边界而不是亲自处理保密漏洞。2.2 安全社区管理与外联Security Community Management and OutreachSIG Security 为新加入的安全向贡献者提供进入 Kubernetes 社区的入口同时作为社区内讨论安全主题与问题的汇聚点具体工作包括与 SIG Contributor Experience 协作策划并维护安全讨论渠道如 Slack 频道、邮件列表、discourse、stack overflow 等回答没有经验的新用户不知道应该去哪个 SIG提出的安全问题并识别常见问题或议题作为改进方向为对安全感兴趣的新贡献者提供“入口”当其有更具体的目标时引导其前往相应的 SIG例如容器隔离相关问题引导至 SIG Node。这一职能也体现在 sig-security/README.md 中该 SIG 的会议是开放、协作且松散规划的每次会议都会听取子项目汇报、共同审查与安全相关的 issue 和 PR并讨论社区成员带来的想法。2.3 横向安全文档Horizontal Security DocumentationSIG Security 负责撰写并维护跨领域的安全文档包括加固指南与安全基准其工作方式是主动寻找其他 SIG 的专家征求意见“我们去找他们他们无需来找我们”。范围内文档包括加固指南与最佳实践Hardening guides and best practices安全基准Security benchmarks改进文档以解决常见误解或问题威胁模型Threat models。该职能在 annual-report-2020.md 中得到印证SIG 的 security-docs 子项目开始创建 Kubernetes 加固指南从整个 Kubernetes 社区收集贡献形成文档大纲后由团队协作撰写。2.4 安全审计Security AuditSIG Security 管理周期性的安全审计并跟进问题协调厂商执行审计并发布审计结果随后跟进受影响 SIG 的问题并协助协调解决具体包括帮助排定修复优先级可能通过从 SIG Security 招募人手同时承认最终决定是否修复、如何修复问题的权威属于负责该问题的 SIG当负责的 SIG 决定不修复某个已报告问题时记录缓解措施、临时方案或注意事项mitigations, workarounds, caveats。从 2021 年度报告 annual-report-2021.md 可以看到该流程的实例Third-Party Audit 子项目在 2021 年发布了 RFP、评估厂商响应并开始协商合同随后宣布了厂商遴选结果。三、Out of scopeSIG Security 的边界划分章程以明确的反向清单划出边界防止与其他机构的工作重叠与 SIG Auth 的对比与 SIG Auth 不同SIG Security 不拥有任何 Kubernetes 集群组件代码认证、授权、审计与安全策略特性归属 SIG Auth私有漏洞响应归属 PSC包括受保密约束的漏洞管理Embargoed vulnerability managementBug bounty 提交的初审与管理triage and management非公开漏洞的收集、初审与披露API 数据保密性/完整性保护机制归属 SIG API Machinery、SIG Auth 或其他 SIG其他 CNCF 项目的安全审计例如 etcd、CoreDNS、CRI-O、containerd归属 CNCF 的 SIG SecurityKubernetes 项目之外的任何项目云厂商特定或分销商特定的加固指南对特定商业产品厂商或云服务商的推荐或背书。这一边界设计保证了 SIG Security 专注于“横向流程与社区”而把具体组件实现SIG Auth、保密响应PSC和生态项目CNCF交给对应机构。四、角色与组织管理Roles and Organization Management章程明确声明SIG Security 遵循 sig-governance 中列出的角色与组织管理并**选择接受opts-in**该文档的后续更新与修改。4.1 Chairs 与 Tech Leads 的附加职责Additional responsibilities of Chairs目前未定义任何附加职责None defined at this timeAdditional responsibilities of Tech LeadsSecurity Documents and Documentation Tech Leads负责维护官方的 Kubernetes 项目 Security Hardening Guide安全加固指南。在 sig-governance.md 中可以查到 Chairs 与 Tech Leads 的通用职责基准例如Chairs 必须组织小组会议、维护 sigs.yaml 元数据、确保会议录制公开、创建年度报告Tech Leads 必须批准与促成子项目的新建/退役、解决跨子项目与跨 SIG 的技术问题、审查与批准 SIG 增强提案KEP。SIG Security 的章程在此基础上按需增减。4.2 子项目创建机制Subproject Creation章程规定SIG Security将子项目审批权委托给 SIG Technical Leads。参见 Subproject creation - Option 1。也就是说在 sig-governance.md 定义的两种子项目创建选项中SIG Security 选择了“由 SIG Technical Leads 审批”的路径对应章程模板 sig-charter-template.md 中的 Option 1而非“子项目联合会Federation of Subprojects”模式。4.3 初始子项目清单SIG Security 的初始子项目为Security Documents and Documentation安全文档与文档撰写Third Party Security Audit第三方安全审计Community Discussion Groups社区讨论组。五、章程的仓库级落地验证sigs.yaml 中的真实子项目体系章程只是起点实际的子项目体系在 sigs.yaml 中有完整注册。截至当前仓库快照SIG Security 名下共有5 个活跃子项目相比章程中的 3 个初始子项目有所演进“Community Discussion Groups”已发展为多个具体社区子项目子项目说明联系渠道SlackOWNERS 来源security-audit第三方安全审计—sig-security-external-audit/OWNERSsecurity-docs安全文档与文档撰写#sig-security-docssig-security-docs/OWNERSsecurity-self-assessmentsKubernetes 子项目的安全自评估#sig-security-assessmentssig-security-assessments/OWNERSsecurity-tooling安全工具的开发与增强#sig-security-toolingcve-feed-osv/OWNERS 与 sig-security-tooling/OWNERSsig-securitySIG 讨论、文档、流程及其他产物#sig-securitysig-security 仓库 OWNERS从 annual-report-2021.md 可以看到子项目的演进过程security-tooling于 2021 年新增着手标准化 Kubernetes CVE 报告、原型验证 Kubernetes 制品的漏洞扫描并举办了多次学习分享会security-self-assessments萌芽于与 ClusterAPI 维护者的一次协作——SIG Security 与 CNCF TAG Security 合作将后者的安全自评估工作流适配到 Kubernetes 语境随后其他子项目纷纷询问自己的引导式自评估security-audit与security-docs自成立起持续运作。而在 2020 年度报告 annual-report-2020.md 中SIG 成立初期仅有 security-docs 与 security-audit 两个成熟子项目security-tooling 刚刚起步——与章程定义的初始子项目相互印证。六、治理依据与对外沟通入口章程的治理框架还包含以下几项可验证的仓库依据会议机制根据 sig-security/README.md 与 sigs.yamlSIG Security 每两周biweekly于周五 8:00 PT 召开例会会议记录与录像链接均维护在 README 中符合 sig-governance.md 中“定期开会、维护会议记录、公开录制”的 SIG 通用要求领导层当前 Chairs 为 Ian Coldwater、Cailyn Edwards 与 Tabitha Sable见 sigs.yaml由 Steering Committee 指派 LiaisonKat Cosgrove对接联系人Slack#sig-security、邮件列表 kubernetes-sig-security、GitHub 团队sig-security-leads与sig-security-pr-reviews见 sig-security/README.md年度报告义务SIG 需要按 sig-governance.md 的要求完成年度报告如 annual-report-2020.md、annual-report-2021.md、annual-report-2022.md用于汇报运营状况、成员规模、KEP 进展与子项目健康度。七、总结一份章程如何塑造一个不拥有代码的 SIGSIG Security 的章程是一份过程型 SIG的典型治理范本定位上它明确自己是横向流程型 SIG不拥有组件代码通过协作放大安全影响力范围上In scope 聚焦四大板块——漏洞管理流程、社区管理与外联、横向安全文档、安全审计Out of scope 则精确切分了与 SIG Auth、PSC、CNCF 的职责边界避免重复劳动治理上它遵循 sig-governance 的角色体系将子项目审批权委托给 Tech Leads并通过 sigs.yaml 注册子项目与 OWNERS实现可审计的治理执行上章程中的职能审计、加固指南、社区入口、公开漏洞流程在年度报告与子项目演进中均有迹可循。对于希望参与 Kubernetes 安全治理的贡献者而言这份章程是理解SIG Security 做什么、不做什么、如何运作的第一手权威材料对于其他社区或项目而言它也是设计横向安全治理小组时可参考的边界划分范本。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes SIG Security 章程全解：横向安全治理边界、四大职能范围与子项目体系
Kubernetes SIG Security 章程全解横向安全治理边界、四大职能范围与子项目体系【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes 社区仓库中的 sig-security/charter.md 为骨架系统解读 SIG Security安全特别兴趣小组的正式章程这是一个典型的“横向horizontal”SIG不直接拥有任何 Kubernetes 组件代码而是以流程与协作方式横跨所有 SIG 提升项目整体安全性。读完本文你将掌握 SIG Security 的职能边界哪些归它管、哪些明确不属于它、它与 Security Response Committee (SRC) / SIG Auth 等实体的分工以及其子项目创建机制与治理结构并可通过仓库中的 sigs.yaml 与 sig-governance.md 验证章程的实际落地情况。一、章程背景与定位从安全审计工作组到横向 SIGSIG Security 的章程遵循 Kubernetes Charter README 中描述的约定并采用 sig-governance 中规定的角色与组织管理方式。这一点与仓库根目录下的章程模板 sig-charter-template.md 的结构完全一致——所有 Kubernetes SIG 的章程都以此模板为基础。SIG Security 覆盖 Kubernetes 项目的横向安全倡议包括定期的安全审计、漏洞管理流程、跨领域安全文档以及安全社区管理。作为一个以流程为导向的 SIG它不直接拥有 Kubernetes 组件代码。该 SIG 取代了此前的 Security Audit Working Group安全审计工作组转而专注于在所有组件上提升 Kubernetes 项目的安全性。历史渊源Third-Party Security Audit Working GroupSIG Security 成长自 Third-Party Security Audit Working Group该工作组在每次第三方安全审计的生命周期内负责管理。工作组与选定的厂商、Product Security Committee (PSC) 以及 CNCF 紧密合作负责撰写 RFP、遴选厂商并管理厂商与其他 SIG 及领域专家的对接。SIG Security 继承了第三方安全审计的管理职责同时承担更广泛的使命倡导安全相关的结构性或系统性问题与默认配置设置、管理非保密公开的漏洞流程、定义 bug bounty漏洞赏金、编写官方 Kubernetes 加固指南与安全文档并作为 Kubernetes 安全的对外公关联络点。在 sigs.yaml 中可以找到该 SIG 的正式注册信息mission_statement使命宣言SIG Security 采取社区建设的方法为最终用户、项目维护者以及 Kubernetes 项目本身提升安全性。它跨 SIG 协作推进安全相关特性、编写和更新文档并维护惠及所有人的安全流程与工具。labelsecurity用于 GitHub issue/PR 打标签如sig/security。charter_link指向本仓库内的 sig-security/charter.md。二、In scopeSIG Security 的四大核心职能范围章程将“范围内In scope”工作划分为四个清晰的板块这是理解该 SIG 日常运作的关键。2.1 漏洞管理流程Vulnerability Management ProcessSIG Security 与 Kubernetes Security Response Committee (SRC) 协作共同定义漏洞修复与披露的流程具体讨论项包括私有修复与发布流程何时被触发漏洞如何被评级severity rating**bug bounty漏洞赏金**的覆盖范围公告发布后的跟进例如漏洞公开后的额外修复、缓解措施、预防手段或文档更新分销商公告政策例如时间线、加入名单的标准等漏洞在何时、以何种方式、于何处被公告定义支持 Kubernetes 子项目的标准与流程例如 dashboard、ingress-nginx、kops 等。注意章程强调这里是**非保密public/non-embargoed**的漏洞流程管理。私有的、受保密协议约束embargoed的漏洞响应归属 Product Security Committee (PSC)见下文“Out of scope”部分。SIG Security 的职责是定义“公开流程”的规则与边界而不是亲自处理保密漏洞。2.2 安全社区管理与外联Security Community Management and OutreachSIG Security 为新加入的安全向贡献者提供进入 Kubernetes 社区的入口同时作为社区内讨论安全主题与问题的汇聚点具体工作包括与 SIG Contributor Experience 协作策划并维护安全讨论渠道如 Slack 频道、邮件列表、discourse、stack overflow 等回答没有经验的新用户不知道应该去哪个 SIG提出的安全问题并识别常见问题或议题作为改进方向为对安全感兴趣的新贡献者提供“入口”当其有更具体的目标时引导其前往相应的 SIG例如容器隔离相关问题引导至 SIG Node。这一职能也体现在 sig-security/README.md 中该 SIG 的会议是开放、协作且松散规划的每次会议都会听取子项目汇报、共同审查与安全相关的 issue 和 PR并讨论社区成员带来的想法。2.3 横向安全文档Horizontal Security DocumentationSIG Security 负责撰写并维护跨领域的安全文档包括加固指南与安全基准其工作方式是主动寻找其他 SIG 的专家征求意见“我们去找他们他们无需来找我们”。范围内文档包括加固指南与最佳实践Hardening guides and best practices安全基准Security benchmarks改进文档以解决常见误解或问题威胁模型Threat models。该职能在 annual-report-2020.md 中得到印证SIG 的 security-docs 子项目开始创建 Kubernetes 加固指南从整个 Kubernetes 社区收集贡献形成文档大纲后由团队协作撰写。2.4 安全审计Security AuditSIG Security 管理周期性的安全审计并跟进问题协调厂商执行审计并发布审计结果随后跟进受影响 SIG 的问题并协助协调解决具体包括帮助排定修复优先级可能通过从 SIG Security 招募人手同时承认最终决定是否修复、如何修复问题的权威属于负责该问题的 SIG当负责的 SIG 决定不修复某个已报告问题时记录缓解措施、临时方案或注意事项mitigations, workarounds, caveats。从 2021 年度报告 annual-report-2021.md 可以看到该流程的实例Third-Party Audit 子项目在 2021 年发布了 RFP、评估厂商响应并开始协商合同随后宣布了厂商遴选结果。三、Out of scopeSIG Security 的边界划分章程以明确的反向清单划出边界防止与其他机构的工作重叠与 SIG Auth 的对比与 SIG Auth 不同SIG Security 不拥有任何 Kubernetes 集群组件代码认证、授权、审计与安全策略特性归属 SIG Auth私有漏洞响应归属 PSC包括受保密约束的漏洞管理Embargoed vulnerability managementBug bounty 提交的初审与管理triage and management非公开漏洞的收集、初审与披露API 数据保密性/完整性保护机制归属 SIG API Machinery、SIG Auth 或其他 SIG其他 CNCF 项目的安全审计例如 etcd、CoreDNS、CRI-O、containerd归属 CNCF 的 SIG SecurityKubernetes 项目之外的任何项目云厂商特定或分销商特定的加固指南对特定商业产品厂商或云服务商的推荐或背书。这一边界设计保证了 SIG Security 专注于“横向流程与社区”而把具体组件实现SIG Auth、保密响应PSC和生态项目CNCF交给对应机构。四、角色与组织管理Roles and Organization Management章程明确声明SIG Security 遵循 sig-governance 中列出的角色与组织管理并**选择接受opts-in**该文档的后续更新与修改。4.1 Chairs 与 Tech Leads 的附加职责Additional responsibilities of Chairs目前未定义任何附加职责None defined at this timeAdditional responsibilities of Tech LeadsSecurity Documents and Documentation Tech Leads负责维护官方的 Kubernetes 项目 Security Hardening Guide安全加固指南。在 sig-governance.md 中可以查到 Chairs 与 Tech Leads 的通用职责基准例如Chairs 必须组织小组会议、维护 sigs.yaml 元数据、确保会议录制公开、创建年度报告Tech Leads 必须批准与促成子项目的新建/退役、解决跨子项目与跨 SIG 的技术问题、审查与批准 SIG 增强提案KEP。SIG Security 的章程在此基础上按需增减。4.2 子项目创建机制Subproject Creation章程规定SIG Security将子项目审批权委托给 SIG Technical Leads。参见 Subproject creation - Option 1。也就是说在 sig-governance.md 定义的两种子项目创建选项中SIG Security 选择了“由 SIG Technical Leads 审批”的路径对应章程模板 sig-charter-template.md 中的 Option 1而非“子项目联合会Federation of Subprojects”模式。4.3 初始子项目清单SIG Security 的初始子项目为Security Documents and Documentation安全文档与文档撰写Third Party Security Audit第三方安全审计Community Discussion Groups社区讨论组。五、章程的仓库级落地验证sigs.yaml 中的真实子项目体系章程只是起点实际的子项目体系在 sigs.yaml 中有完整注册。截至当前仓库快照SIG Security 名下共有5 个活跃子项目相比章程中的 3 个初始子项目有所演进“Community Discussion Groups”已发展为多个具体社区子项目子项目说明联系渠道SlackOWNERS 来源security-audit第三方安全审计—sig-security-external-audit/OWNERSsecurity-docs安全文档与文档撰写#sig-security-docssig-security-docs/OWNERSsecurity-self-assessmentsKubernetes 子项目的安全自评估#sig-security-assessmentssig-security-assessments/OWNERSsecurity-tooling安全工具的开发与增强#sig-security-toolingcve-feed-osv/OWNERS 与 sig-security-tooling/OWNERSsig-securitySIG 讨论、文档、流程及其他产物#sig-securitysig-security 仓库 OWNERS从 annual-report-2021.md 可以看到子项目的演进过程security-tooling于 2021 年新增着手标准化 Kubernetes CVE 报告、原型验证 Kubernetes 制品的漏洞扫描并举办了多次学习分享会security-self-assessments萌芽于与 ClusterAPI 维护者的一次协作——SIG Security 与 CNCF TAG Security 合作将后者的安全自评估工作流适配到 Kubernetes 语境随后其他子项目纷纷询问自己的引导式自评估security-audit与security-docs自成立起持续运作。而在 2020 年度报告 annual-report-2020.md 中SIG 成立初期仅有 security-docs 与 security-audit 两个成熟子项目security-tooling 刚刚起步——与章程定义的初始子项目相互印证。六、治理依据与对外沟通入口章程的治理框架还包含以下几项可验证的仓库依据会议机制根据 sig-security/README.md 与 sigs.yamlSIG Security 每两周biweekly于周五 8:00 PT 召开例会会议记录与录像链接均维护在 README 中符合 sig-governance.md 中“定期开会、维护会议记录、公开录制”的 SIG 通用要求领导层当前 Chairs 为 Ian Coldwater、Cailyn Edwards 与 Tabitha Sable见 sigs.yaml由 Steering Committee 指派 LiaisonKat Cosgrove对接联系人Slack#sig-security、邮件列表 kubernetes-sig-security、GitHub 团队sig-security-leads与sig-security-pr-reviews见 sig-security/README.md年度报告义务SIG 需要按 sig-governance.md 的要求完成年度报告如 annual-report-2020.md、annual-report-2021.md、annual-report-2022.md用于汇报运营状况、成员规模、KEP 进展与子项目健康度。七、总结一份章程如何塑造一个不拥有代码的 SIGSIG Security 的章程是一份过程型 SIG的典型治理范本定位上它明确自己是横向流程型 SIG不拥有组件代码通过协作放大安全影响力范围上In scope 聚焦四大板块——漏洞管理流程、社区管理与外联、横向安全文档、安全审计Out of scope 则精确切分了与 SIG Auth、PSC、CNCF 的职责边界避免重复劳动治理上它遵循 sig-governance 的角色体系将子项目审批权委托给 Tech Leads并通过 sigs.yaml 注册子项目与 OWNERS实现可审计的治理执行上章程中的职能审计、加固指南、社区入口、公开漏洞流程在年度报告与子项目演进中均有迹可循。对于希望参与 Kubernetes 安全治理的贡献者而言这份章程是理解SIG Security 做什么、不做什么、如何运作的第一手权威材料对于其他社区或项目而言它也是设计横向安全治理小组时可参考的边界划分范本。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考