企业官网建设流程全解析

Kubernetes SIG Security 2021 年度全景：社区驱动的安全治理、KEP 落地与子项目演进

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

本文基于 Kubernetes 社区仓库 中的官方文档 sig-security/annual-report-2021.md 展开，系统梳理 SIG Security 在 2021 年的关键成果：安全文档与工具链子项目的落地、第三方安全审计的推进、Security Self-Assessment 新模式的探索，以及 KEP 1933/2579/2763 的里程碑进展。读完本文，你将掌握 SIG Security 的职责边界、年度 KEP 时间线、社区健康度量方法与子项目组织方式，并能在仓库中找到对应的治理与章程依据。

一、SIG Security 的定位与 2021 年起点

在展开 2021 年年报内容之前，有必要先明确 SIG Security 在整个 Kubernetes 治理体系中的位置。根据 sig-security/charter.md 的 Scope 定义，SIG Security 负责 Kubernetes 项目的横向安全倡议（horizontal security initiatives），包括：

• 周期性第三方安全审计的管理；
• 公开（非 embargoed）漏洞管理流程的协同；
• 跨 SIG 的横向安全文档（如加固指南、安全基准）；
• 安全社区的管理与对外沟通。

章程特别强调：SIG Security不直接拥有任何 Kubernetes 组件代码，与拥有认证、授权、审计和安全策略功能的 SIG Auth 形成明确边界（charter.md 的 Out of scope 一节列出了完整范围）。这份"过程导向型 SIG"的定位，是理解 2021 年全部工作的前提。

2020 年年报（sig-security/annual-report-2020.md）显示，该 SIG 于 2020 年 10 月成立，彼时主 Slack 频道仅 438 名成员、邮件列表 131 人，仍处于"我们是谁"的自我定位阶段。而 2021 年年报开篇即给出结论：SIG 规模翻倍，子项目走向成熟，新一代领导者开始反哺新人，形成了"几代贡献者共同工作、学习、协作"的社区格局。

二、2021 年核心工作：四大子项目齐头并进

2021 年年报从四个维度总结了年度亮点工作。

1. security-docs：让 Kubernetes 安全更易理解

Docs 子项目通过博客与教程大幅降低了 Kubernetes 安全的入门门槛，年报列举的代表性产出包括：

• NSA/CISA Kubernetes 加固指南解读（A Closer Look at NSA/CISA Kubernetes Hardening Guidance）；
• 准入控制器安全（Securing Admission Controllers）主题文章，覆盖 webhook 与准入控制的攻击面；
• Pod Security Standards 集群级应用教程（Apply Pod Security Standards at the Cluster Level）；
• Pod Security Standards 命名空间级应用教程（Apply Pod Security Standards at the Namespace Level）。

这一系列内容恰好对应 2021 年 PodSecurityPolicy（PSP）被弃用后社区急需的替代性安全基线，也印证了 charter.md 中"编写并维护横向安全文档（加固指南、安全基准）"这一 In scope 职责。从仓库看，该子项目在 sig-security/README.md 中被描述为 "Security Documents and Documentation"，并拥有独立的 Slack 频道 #sig-security-docs。

2. security-tooling：CVE 报告标准化与漏洞扫描原型

Tooling 子项目在 2021 年正式起步并快速发展，年报提及三项标志性工作：

• 标准化 Kubernetes CVE 报告：建立统一的 CVE 披露与报告规范；
• 漏洞扫描原型：对 Kubernetes 构建产物（build time dependencies）与容器镜像进行漏洞扫描的可行性验证；
• 系列学习会：围绕安全工具链开展的分享活动被观看数百次。

值得关注的是，漏洞扫描这项工作跨越了多个 SIG 的边界——年报明确指出，其目标是"将 SIG Security 在这些工具上的专业经验转化为实际改进，同时不给其他 SIG 增加额外负担"。这一协作模式与 charter.md 中"去其他 SIG 寻求输入，而非让它们来找我们"的理念一脉相承。

3. Security Self-assessments：Kubernetes 场景化的引导式自评估

Security Self-assessments 是 2021 年年报着墨最多的新探索。起因是 ClusterAPI 维护者希望获得安全评估与改进的指导，SIG Security 成员积极响应，与CNCF TAG Security合作，将 TAG Security 已有的自评估工作流适配到 Kubernetes 语境，为 ClusterAPI 开展引导式自评估。

这一模式的价值在于"授人以渔"：参与者在过程中积累了信心与经验，口碑扩散后，其他 Kubernetes 子项目也开始主动询问引导式自评估。年报写作时，Security Self-Assessment 正成为 SIG Security 的潜在新子项目——这一判断在仓库中得到了验证：sigs.yaml 的 sig-security 条目下已经存在security-self-assessments子项目（描述为 "Security self-assessments for K8s subprojects"），并由 #sig-security-assessments Slack 频道承载沟通（见 sig-security/README.md 的子项目列表）。

4. security-audit：第三方安全审计持续推进

Third-Party Audit 子项目继续管理其同名倡议。2021 年的关键进展是：发布 Request for Proposals（RFP）、评估厂商响应、与入选厂商谈判合同条款，并最终宣布厂商选定、开始筹备审计工作的启动安排。

第三方安全审计是 SIG Security 的历史传承——charter.md 记载，SIG Security 脱胎于 Third-Party Security Audit Working Group，该工作组曾在 2019 年主导审计全流程，如今这一职责由 SIG Security 的 security-audit 子项目延续。

三、KEP 工作盘点：1.21 / 1.22 / 1.23 的关键里程碑

2021 年年报对当年跨越三个 Kubernetes 版本的 KEP 工作做了完整盘点，以下按成熟度阶段整理：

Stable（GA）

• [KEP 1933] Defend against logging secrets via static analysis——1.23 版本转 Stable该 KEP 通过静态分析手段防止日志中意外泄露 Secret，是 SIG Security 从 SIG Instrumentation 接管的 KEP（2020 年年报有记载）。它走完了 alpha → beta → stable 的完整生命周期，展示了横向安全能力如何通过静态分析工具链落地为默认防护。

Beta

• [KEP 2579] PSP Replacement Policy——1.23 版本转 BetaPodSecurityPolicy 在 1.21 被弃用后，KEP 2579 负责定义其替代策略。该 KEP 由 SIG Auth 主导，但 SIG Security 深度参与方案撰写与评审（2020 年年报明确记载了双方的密切协作），是跨 SIG 合作的典型样本。
• [KEP 1933]（同上）——1.21 版本进入 Beta。

Alpha

• [KEP 2579] PSP Replacement Policy——1.22 版本进入 Alpha。

Pre-alpha

• [KEP 2763] Ambient Capabilities—— 提出"环境能力"（ambient capabilities）概念，处于早期设计阶段。

将 2021 年报与 sig-security/annual-report-2022.md 对照可以看出后续演进：KEP 2763（Ambient Capabilities）在 1.24 转 Alpha；而 2022 年新增的 [KEP 3203] Auto-refreshing official CVE feed 在 1.25 进入 Alpha——这正是 2021 年 Tooling 子项目 CVE 标准化工作的自然延伸，最终落地为kubernetes-sigs/cve-feed-osv项目（其 OWNERS 已收录在 sigs.yaml 的 security-tooling 子项目下）。

四、项目健康：社区健康度量的务实之道

1. 最需要帮助的领域：Docs 子项目

年报明确指出，security-docs 子项目始终欢迎各个经验水平的安全向贡献者。这个子项目已成为许多贡献者合并第一个 Kubernetes PR 的起点——年报提到有贡献者在这里合并了他们的首批 PR。对新人而言，参与 Docs 子项目意味着"在提升文档质量的同时深入学习 Kubernetes 安全、帮助所有人更安全地运行集群"，是一个学习与贡献双赢的入口。

2. OWNERS 文件的需求特殊性

作为不拥有代码的横向 SIG，SIG Security 对 OWNERS 文件的需求远低于交付代码的 SIG。年报表示，其所有领域都有两个或以上的 OWNERS，且社区化的运作方式确保了当某人需要缩减投入时能得到充分支持。这与 governance.md 中"每个子项目由 owners 作为技术负责人"的一般模型形成了有趣的对照——安全类横向工作的所有权更多体现在讨论、评审与文档协作上。

3. 社区健康度量指标：以人为本

SIG Security 明确表示关心"人"而非机械指标，其社区健康度量聚焦于定性问题：

• 人们是否来参加会议、在 Slack 上互相交流？
• 有多少人参与？是否有人主导了对话？
• 新贡献者是否在加入？人们是否持续回流？

年报坦言这类问题"很难量化，但我们对此保持坦然"——这与 2020 年年报中"我们关心的是服务是否达成目标、还需要提供哪些新服务"的度量哲学一脉相承，体现了该 SIG 以社区参与而非代码产出为核心的组织文化。

4. CONTRIBUTING.md 与贡献者阶梯的适配

年报坦承，SIG Security 一直需要一份更真实反映其工作方式的 CONTRIBUTING.md：贡献可以从"在会议或 Slack 消息中分享想法"开始，而不必从代码 PR 开始。同时，由于横向工作性质导致 PR、OWNERS 文件远少于代码型 SIG，通用的 社区贡献者阶梯 中"以大量代码 PR 评审为尺度"的设计对 SIG Security 的适配性有限——该 SIG 正通过实践探索如何利用并演进这一阶梯，以鼓励和认可其核心贡献者。

五、会员规模数据：2021 年的增长实证

2021 年年报提供了完整的会员统计（可与 2020 年的基线对照）：

年报特别说明：由于会议组织方式的特殊性，大多数会议上每位与会者都会参与发言。此外，"SIG 拥有包的唯一 reviewers/approvers"两项指标标注为 N/A——因为 SIG Security 不拥有任何代码包，这一细节再次印证了其无代码所有权的横向定位。

六、子项目与工作组演进：新增 tooling，无停摆

2021 年子项目状态一览（依据 sig-security/annual-report-2021.md 及 sigs.yaml）：

• 新增：security-tooling（"Development and Enhancements of Security Tooling"，即安全工具链的开发与增强）；
• 停用：无；
• 延续：security-audit（第三方安全审计）、security-docs（安全文档）。

工作（Working）组方面：2021 年无新增、无停用、无延续，SIG Security 的横向工作全部通过子项目承载。至本文写作时（以 sigs.yaml 和 sig-security/README.md 为准），SIG Security 旗下共有五个子项目：security-audit、security-docs、security-self-assessments、security-tooling与sig-security（SIG 自身的讨论、文档与流程工件）——与 2021 年报的预期方向完全一致。

七、运营与治理：年度运营任务的执行情况

2021 年年报按照 committee-steering/governance/sig-governance.md 的要求逐项核对了年度运营任务：

• [x] README 准确性审查：已审查并按需更新（当前版本见 sig-security/README.md）；
• [ ] CONTRIBUTING.md 审查：未完成——年报解释这是有意为之，SIG 需要一份更能反映"以社区共建提升安全"理念的专属文档，草稿正在推进中；
• [x] sigs.yaml 子项目与 OWNERS 文件核对：已完成（sigs.yaml 中 sig-security 条目已正确列出全部子项目及其 OWNERS 链接）；
• [x] SIG 领导者（chairs / tech leads / 子项目 owner）活跃度核对：已完成；
• [x] 会议记录与录像归档：2021 年会议记录与录制均已链接至 sig-security/README.md 的 Meetings 一节（例会为太平洋时间周五 8:00，双周一次）；
• [x] 社区级更新：2021 年在 KubeCon EU 与 KubeCon NA 分别进行了社区更新演讲（"Get In Containerds, We're Going Securing" 与 "Security Through Transparency"）。

关于领导团队，sigs.yaml 显示 SIG Security 由三位 chair 领导：Ian Coldwater（Independent）、Cailyn Edwards（Okta）、Tabitha Sable（Datadog），并配置了sig-security-leads与sig-security-pr-reviews两个 GitHub 团队，以及 Steering Committee Liaison（当前为 Kat Cosgrove）。

八、SIG Security 的独特方法论：不拥有代码，如何推动安全

纵览整份 2021 年年报，最值得提炼的方法论是 SIG Security 与多数 SIG 截然不同的工作范式：

1. 以社区共建替代代码所有权：通过培育包容、欢迎的环境，让从最新手到最资深黑客的每个人都能分享想法、贡献于项目安全；
2. 共识、沟通、参与驱动：年报直言"SIG Security 的大多数工作不在 KEP 范围内"，实际产出取决于"谁参与、带来什么想法、社区如何回应"——改进流程、提供持续服务、构建跨 SIG 协作是其核心；
3. 涟漪效应设计：SIG Security 的工作被有意设计为"无论我们是否在场都能向外扩散"，鼓励并促成跨 SIG 的内部协作以及与外部安全社区的互动；
4. 与外部组织的协同：与 CNCF TAG Security 合作适配自评估工作流、与 SIG Auth 协作完成 PSP 替代方案、与 SIG Instrumentation 协作承接 KEP 1933，都是"去其他 SIG 寻求输入"理念的落地。

年报用一句话概括了这一年的自我认知转变：从 2020 年"一个刚成立、正在确立自我身份的新 SIG"，成长为 2021 年"自成体系、子项目成熟、领导者辈出"的社区。这份年报不仅是 SIG Security 的年度成绩单，也是理解 Kubernetes 社区如何治理横向安全工作的第一手资料——仓库中的 charter.md、README.md、sigs.yaml 以及 2020–2022 年各年年报（annual-report-2020.md、annual-report-2022.md）共同构成了完整的证据链，供读者进一步深入。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community