从 2016 年会议纪要回溯 Kubernetes SIG-Auth认证授权体系的奠基决策与演进脉络【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本篇文章以仓库内 sig-auth/archive/meeting-notes-2016.md 这份 2016 年全年 SIG-Auth 双周例会纪要为核心骨架系统梳理当年 Kubernetes 认证Authentication、授权Authorization与安全策略领域的关键设计与决策RBAC 从 Alpha 走向 Beta、kubelet 认证授权与 Node CSR 引导机制、凭据轮换与吊销、ServiceAccount Token 安全边界、认证代理、网络策略多租户模型、OIDC/Keystone 外部身份集成以及安全响应团队的组建。读完本文你不仅能还原 2016 年这些安全特性的设计初衷与取舍还能对照 SIG-Auth 章程、SIG-Auth 现状 与 安全响应委员会看清当年决策如何沉淀为今日 Kubernetes 的安全骨架。一、背景2016 年的 SIG-Auth 与文档定位SIG-AuthAuth Special Interest Group负责 Kubernetes 中控制和保护对 API 及核心组件访问的一切能力按 章程 的界定其范围内包括认证、授权、审计接口与扩展点以及 ServiceAccount、OIDC、认证代理、Webhook 等认证实现RBAC、Node、Webhook 等授权实现还有 NodeRestriction、ServiceAccount、PodSecurityPolicy、ImagePolicy 等安全相关准入插件。2016 年正是这些机制的从 0 到 1阶段。4 月 20 日举行了第一次正式会议随后每两周一次直至 12 月 14 日。这一年的会议纪要sig-auth/archive/meeting-notes-2016.md记录了从概念讨论、设计提案到 PR 合入的完整过程是研究 Kubernetes 安全体系演进的第一手史料。当年参与讨论的多位核心成员——Jordan Liggittliggitt、David Eadsdeads2k、Eric Chiangericchiang、Eric Tuneerictune、Mike Danesemikedanese等——至今仍是 SIG-Auth 现任或荣休负责人 名单中的名字。会议纪要以时间为序展开为便于阅读本文按技术主题重新组织但完整保留了各次会议的核心内容。二、RBAC当年最核心的P1工程RBAC基于角色的访问控制是 2016 年 SIG-Auth 投入最大的工作线贯穿全年会议。2.1 从 Alpha 到 Beta 的目标路线在 7 月 13 日的会议 上SIG 明确了 RBAC 的两阶段目标1.4 目标AlphaRBAC API 与授权器落地GCE 测试以开启状态运行提供默认角色集与默认 ServiceAccount 角色1.5 目标Beta对自动搭建的集群默认开启API 可用且不再混用资源规则与非资源规则。到 9 月 7 日的会议RBAC 被正式列为 1.5 的 P1 目标审查 RBAC 相关贡献、确保其进入 Beta并明确验收标准——准确性accuracy、性能performance由 ericchiang 协助测试与默认角色default roles。2.2 1.6 的 RBAC 收尾清单在 11 月 30 日的会议 上1.6 的 RBAC-to-Beta 被标注为 P1, big收尾工作包括为 controller、scheduler、kubelet 等组件建立默认角色与身份相关 PR 已在推进支持local-up-cluster场景增加 CI 测试强制校验 controller、kubelet 及其他基础设施组件的权限边界编写如何用 RBAC 默认保护 API的文档并跟踪 AWS、GCE、kubeadm、kops 等部署机制的启用情况由 ericchiang 协助ServiceAccount 的默认最小角色在当时已完成默认关闭防止失陷 Pod 造成更大破坏。2.3 收紧规则跨 Namespace 引用与 roleref 校验9 月 7 日的会议 讨论了 RBAC 规则的收紧方向禁止跨 Namespace 的 Role 引用——当时该场景仅在运行时才报错计划改为创建时即拒绝但保留跨 Namespace 引用 ServiceAccount的能力要求 roleref 必须携带Kind与APIGroup字段可做默认值填充同时评估这些变更带来的破坏性影响并讨论角色的引导bootstrapping方式。2.4 声明式Intent-BasedRBAC API11 月 2 日会议 上讨论了基于意图的 RBAC APIintent-based RBAC API相比命令式地执行绑定/解绑操作声明式 API 让用户直接表达希望 david 能访问 pods/proxy这类意图由系统负责收敛到具体策略。会议明确这是声明式declarative与命令式imperative之争计划在 1.5 之后由 david 与 clayton 跟进落地。仓库佐证今天 sigs.yaml 中 sig-auth 目录下仍可见authorizers子项目其 OWNERS 覆盖了pkg/apis/rbac、pkg/registry/rbac、staging/src/k8s.io/api/rbac等路径见 sig-auth/README.md说明这套当年从会议中打磨出来的 RBAC 代码至今仍是 SIG-Auth 的核心领地。三、凭据轮换与吊销短生命周期证书 vs CRL 之争11 月 30 日会议 将凭据轮换系统化为三类问题类别内容当年讨论要点凭据吊销Credential revocationServiceAccount Token 吊销删除对应 Secret并回查 etcd 校验X509 证书吊销通过 CRL证书吊销列表实现凭据轮换Credential rotationServiceAccount Token 轮换支持多签名密钥识别 TokenX509 证书轮换客户端/服务端证书更新签名/签发凭据轮换Token 签名密钥轮换API Server 需支持多验证密钥CA 签名证书轮换根 CA 泄漏后的补救路径在 11 月 2 日会议 上团队明确讨论了 CRL 的时间线PR 处于待审状态可能无法在 1.5 冻结前完成可能推迟到 1.6 早期。核心权衡是短生命周期证书容易轮换vs 简单吊销CRL 查询有性能开销。这一权衡至今仍是 PKI 设计的经典命题。9 月 7 日会议 还补充了轮换场景的动机若某人拿到 ServiceAccount Token需要能吊销它为此需要在标准部署中默认开启对应的准入控制器或授权选项若主节点密钥泄露需要能撤销该密钥前提是根 CA 仍然安全。当时的实现路径包括为 API Server 增加允许 JWT 验证器接收多个验证密钥的能力。仓库佐证今日 SIG-Auth 仍保有certificates证书 API 与 PKI 客户端基础设施与encryption-at-restetcd 静态加密两个子项目详见 sig-auth/README.md可见凭据与密钥管理这条线在 2016 年后持续演进。四、kubelet 认证授权与 Node CSR API节点身份体系的开端4.1 kubelet authn/authz 提案10 月 5 日会议 审阅了 kubelet 认证/授权提案为 kubelet 的 API 增加认证与授权能力。GKE 的考量是可以继续运行在无认证/授权模式CJ Cullen 对针对 kubelet 使用 SubjectAccessReviewSAR持保留意见讨论延续到 PR 中。9 月 7 日会议 将其列为 1.5 的 P1 目标与消除不安全的主机端口issue 13598并列。4.2 Node CSR API 的设计原则8 月 10 日会议 对 Node CSR证书签名请求API 进行了深入设计确立了两个层次的约束API 强制信息API-enforced info请求者是谁user/uid/groups用户指定信息User-specified info请求什么CSR 内容、请求什么类型的证书ExtKeyUsageServerAuth、ExtKeyUsageClientAuth、KeyUsageCertSign 等用途扩展。针对引导bootstrap场景会议给出两种自动化路径节点客户端证书自动批准bootstrap 场景节点从共享密钥出发获得独立客户端证书。约束包括限制只能申请客户端证书要求特定 CSR subject 形状例如Osystem:nodes, CNsystem:node:nodename控制器可基于引导组或用户标志做自动批准使共享引导密钥能扇出为各节点独立的客户端证书节点服务端证书自动批准器限制只能申请服务端证书要求特定 subject/SAN 形状仅 CN且 CN 必须在 SAN 中并以请求来自节点用户为门槛与客户端证书自动批准器链式配合实现更强的安全约束。4.3 节点差异化授权同一场会议还确立了节点应基于是哪个节点被差异化授权的原则节点只能看到调度到它上面的 Pod节点只能看到被调度到它上面的 Pod 所使用的 Secret节点只能更新自身认证层必须提供足以支撑这些判断的信息指示主体是节点的特殊组以及指示节点主体对应哪一个节点的字段。此外会议指出服务端证书与客户端证书应被视为不同动作sign 的授权策略应区分并强调任何能决定什么可以被签发的控制器都必须感知谁能请求什么需要 API 层面的知识因此希望 CSR 策略基于 API 意图而非配置文件。仓库佐证这段讨论的遗产清晰可见——sig-auth/README.md 中的node-identity-and-isolation子项目与 sig-lifecycle、sig-node 共管正是节点身份管理与隔离工作负载授权的当代形态其 OWNERS 覆盖pkg/controller/certificates/approver、pkg/kubelet/certificate、plugin/pkg/admission/noderestriction与plugin/pkg/auth/authorizer/node。五、ServiceAccount Token 与真实的 Secrets之辩5.1 把凭据放进 Secret 的风险7 月 27 日 与 8 月 10 日会议 反复讨论同一问题ServiceAccount 凭据存储在 Secret 中任何能查看 Secret 的人都能拿到凭据并以该 ServiceAccount 身份行事。讨论的替代方向包括将 ServiceAccount Token 迁移到独立资源把 Secret 作为 ServiceAccount 的子资源仅 ServiceAccount 可访问其 Secret用户需先冒充impersonate该 ServiceAccount 才能取得 Token会议也提出这或许是用具体方案解决一般性问题——我们到底需要一个 Secret 权限系统还是一个通用对象的权限系统5.2 Vault 集成原型Token per Pod12 月 14 日会议 演示了 Kelsey Hightower 的 vault-controller 原型讨论记录了当时对 Kubernetes Secrets 边界的清醒认知会议观点Kubernetes 没有真正的SecretKubernetes doesnt have real secrets方案每个 Pod 一个 Token——用 init 容器与 vault controller 通信controller 按 Pod 名查找对应 Pod确认自己确实在与该 Pod 通信例如通过 Pod IP 下发 Token后才发放令牌动态 Secret 可带短 TTL 并支持续期Vault 只允许一个客户端解码 Token若被尝试解包两次会触发告警遗留难点当时无法保护特定 annotation 的使用安全密钥/证书更新仍要处理健康检查与轮换依然困难Vault controller 需要能访问它可能委托给 Pod 的全部策略。5.3 OpenShift 的 Serving Cert 注解方案同一场会议12 月 14 日还介绍了 OpenShift 的服务端证书注解方案为集群内 DNS 名service-name.namespace.svc签发服务端证书借助自动挂载的 SA Secret 顺带分发 CA 捆绑包到所有 Pod被窃取的密钥无法被其他 Namespace 的 Pod 使用因为它们无法控制流量路由不签发客户端证书因为客户端证书可能被随处重用难点让 Pod 重新加载更新后的服务端证书很困难Ingress 只做 TLS 终止termination而不做重新加密re-encryption证书轮换困难。六、身份模型user.Info、Groups、Impersonation 与 Scopes6.1 Scopes vs Extra 的历史性结论4 月 20 日首次会议 就讨论了user.Info上的 Scopes 与 Extra 之争RedHat 希望服务器签发带 scope 的 OAuth TokenToken 由用户 U 签发但被限制只能做某些事。讨论后的结论是允许 Extra 信息而不为 scopes 建立结构化字段否则 Kubernetes 就要负责管理 scopes 并映射到 REST 操作各认证器与授权器模块自行协商如何解释 Extra 信息建议使用带命名空间前缀的键namespaced keys。这一决策直接塑造了后来user.Info.Extra的形态。6.2 通过证书组织单位OU表达 Group8 月 10 日会议 讨论为 x509 客户端证书增加基于 Organizations 或 Organizational Units 的 Group 支持采用 Organizations 以与 OpenShift 对齐同时提出连锁问题——证书嵌入的信息越多就越需要吊销机制支撑。6.3 扩展 Impersonation 到 Groups 与 Extra同一场会议8 月 10 日确定扩展 impersonation 能力允许完整冒充包括 Groups 与 Extra即user.Info接口的最后几个字段服务于代理/委派场景如联邦集群这些场景下认证方式不可传递如 x509 客户端证书认证在边缘完成认证后以确定的用户身份转发请求以转发用户是否具备 impersonate 权限为前提。6.4 字段级授权与级联删除4 月 20 日 与 9 月 7 日会议 都触及字段级授权field-level authorization若用户有权限设置对象的 parent label 却无权限删除对象可以让父对象级联删除该对象或反过来利用 controller 删除子对象。级联删除与 Impersonate-User 的关系使问题复杂化该讨论当时未完结并延伸到 RBAC 规则收紧议题中。七、认证代理Kubernetes 作为/背后的 Authenticating Proxy9 月 7 日会议 为 1.5 收集目标时认证代理被拆成两个方向Kubernetes API 可以位于认证代理之后P1集群部署者可在 API Server 前放置认证代理利用请求头Request Header转发身份信息Kubernetes 本身作为认证代理P2让集群内的 addon/app/chart 免于自建认证——如果我已认证到 Kubernetes API我就可以被认证到集群上运行的应用。潜在用户包括 K8s Dashboard、联邦 API Server、Grafana、Spark driver dashboard。当时尚无成熟设计倾向分阶段推进。11 月 30 日会议 进一步将联邦 API Server 的认证/授权列为 1.6 的 P1-smallAPI Machinery 已有联邦 API Server 提案认证代理正在标准化为认证方式且 OpenShift 的 kube-aggregator 作为 POC 被引入验证概念。八、网络策略与多租户与 SIG-Network 的联合讨论9 月 21 日会议 是 SIG-Auth 与 SIG-Network 的联合会议围绕 NetworkPolicy 与多租户展开当时的 NetworkPolicy 能力边界仅支持 ingress不支持 egress通过 label selector 选择哪些 Pod 可以互相通信也可选择一组 Namespace策略只做加法additive与 RBAC 的关系RBAC 当时与网络策略映射不佳RBAC 分两级cluster admin vs namespace adminNamespace admin 不应影响其他 NamespaceAWS 安全组类比创建组我暴露 80 端口只接受来自 foobar IP 的流量把 VM 加入组目标是用 label selector 圈定范围且运维策略优先于用户策略用 Namespace 上的 label 表达跨 Namespace 公共策略的挑战label 值有限OpenShift 不得不改用 annotation还要回答谁控制这些 labelGrant vs Accept 的启示我授予你某物不代表你想要它通过误导性命名向他人授予访问权的钓鱼攻击风险关于租户的讨论10 月 19 日继续OpenShift 中 Namespace 网络默认隔离、可共享上游 NetworkPolicy 当时不解决租户问题会议计划产出一份什么是租户的文档由 David Oppenheimer 推动。仓库佐证这段讨论最终走向了 Kubernetes 的网络策略与多租户能力而 SIG-Auth 的角色被定格为其他 SIG 要实现策略时SIG-Auth 是讨论一般性策略的合适场所会议原话与 章程 中与其他 SIG 协商如何应用 SIG-Auth 拥有的机制的定位一致。九、外部身份集成OIDC、Keystone/OpenStack 与 kubectl login9.1 OIDC 客户端更新11 月 2 日会议 记录了 OpenID Connect 客户端的进展CoreOS 库的上游重写与任意 OAuth/OIDC Server 的兼容性更好切换前先做kube 使用 OIDC的外部测试覆盖由 ericchiang 开跟踪 issue 汇总变更。9.2 Keystone/OpenStack 集成7 月 13 日会议 讨论了 OpenStack Keystone 集成的两种形态认证侧原生 Token 认证 远程认证调用 vs Webhook 化——Webhook 会丢失 project id 与 keystone roles 信息角色转为 groups 并不直接因为角色是限定在 project 范围内的授权侧等待角色映射方案确定后再继续。9 月 7 日会议 进一步细化映射设计用户名用Keystone user namedomain name友好还是 user id唯一且程序化推荐把 keystone project/role 元组映射为 group从而在 Kubernetes 认证/授权层实现干净分层Kubernetes 收到的 Token 标识 keystone 用户并限定到特定 project/role 元组。9.3 kubectl login 与挑战式认证7 月 13 日会议 讨论了kubectl login的需求必须能处理 basic auth challenge参考 OpenShift 的 ChallengeHandler 接口——basic、negotiate 与多实现basic 处理可用指定用户/密码或从 stdin 提示negotiate 可用 gssapi 库。7 月 27 日会议 补充倾向使用标准 discovery 机制而非给 API Server 新增路径可在无 discovery 机制的情况下先启动 kubectl login。9.4 刷新令牌与客户端密钥的争议4 月 20 日会议 记录了 deads2k 对 API Server 自动附加客户端密钥client secret到刷新令牌refresh token设计的担忧这会让提交刷新令牌从 OAuth 规范要求的双因素刷新令牌 客户端密钥退化为单因素相当于机密客户端盲目声明是的就是我。会议共识包括登录命令必须足够灵活以容纳多种认证提供方为 challenge 预留插槽不绑定特定提供方API Server 不应负责提供认证端点。该议题延续到 6 月 29 日 的会议中继续跟进。十、威胁模型、What can I do 端点与消除不安全端口10.1 1.6 的威胁模型叙事11 月 30 日会议 提出为 1.6 提炼一句简洁的威胁模型例如集群内失陷的 nginx 不应在不借助进一步漏洞的情况下获得集群 root 权限。Pod 安全上下文PodSecurityContext与 RBAC 正是为这一示例场景做的工作同时需要配套文档说明如何组合使用它们向用户与开发者解释安全工作的意义。10.2 What can I do? 端点9 月 7 日会议 提出为用户提供我能执行哪些操作的完整列表能力SAR/SelfSAR 只能逐次检查单个动作获得完整列表对 UI 交互如是否显示删除按钮极为有用。设计约束包括不应绑定特定授权器支持 Namespaced 与 Cluster 作用域需要处理通配符star规则与信息不完整的情形考虑批处理以降低开销。10.3 消除不安全的 10250 端口9 月 7 日会议 将消除无保护的 master 端口列为 P1当时 controller 与 scheduler 仍在使用不安全端口计划为其赋予system:身份预计 1.5 中可行但不容易1.6 才能真正易用。十一、治理与流程SIG 自评与安全响应团队11.1 SIG 自评11 月 30 日会议 进行了 SIG 自评代码归属SIG-Auth 代码集中在 kubernetes/kubernetes 的/pkg/apis/{abac,authorization,authentication,rbac}、/pkg/auth、/plugin/pkg/auth主仓库外无代码OWNERS 中 sig-auth 负责人以个人身份出现在多个文件但未以 sig-auth 别名聚合GitHub 团队与邮件组未同步支持渠道Slack 频道活跃度高邮件组表现一般Slack 不可搜索应明确各论坛适合的问题类型并把高频问答沉淀到文档工程质量单元测试覆盖良好集成测试覆盖较弱难以用多种配置启动服务器文档欠账较多。11.2 安全响应团队 → 今日的 Security Response Committee10 月 19 日会议 提出组建安全响应团队security response team / vulnerability management team作为 SIG-Auth 的工作组目标是小团队私下分流 CVE/安全报告与相应 SIG lead / 特性 owner 协调与发布工程releng协调安全修复的 point release 或 backport与厂商/发行版协调安全修复的分发。推进分两阶段先设计团队结构与章程再由团队执行使命前期还参考了 OpenStack Vulnerability Management Team 的既有流程。仓库佐证这一构想如今已落地为独立于 SIG-Auth 的 Security Response Committee其职责被明确为接收并响应 Kubernetes 项目安全问题的报告成员名单中仍可见当年参与讨论的 CJ Cullen、Mo Khan 等名字。当年协调与 releng、与厂商/发行版分发的设想也对应今日委员会与发布流程的协作机制。十二、结语2016 年决策的当代回声回看这份 2016 年会议纪要今日 Kubernetes 安全体系中几乎每一块拼图都能找到当年的讨论原点RBAC 的默认角色、引导bootstrapping、声明式 API演进为今日默认开启的授权模型Node CSR 的system:nodes组、system:node:nodenamesubject 形状与自动批准器构成了 kubelet 证书引导与节点身份的基础ServiceAccount Token 存储在 Secret 中的风险讨论催生了 TokenRequest、TokenReview 等更精细的短期令牌机制Scopes vs Extra 的结论延续为user.Info.Extra的命名空间化键认证代理的两个方向分别长成为今日的 Webhook Token 认证、请求头认证与聚合 API Serverkube-aggregator安全响应团队则正式化为独立委员会其章程与成员见 committee-security-response/README.md。对希望深入源码的读者建议从 sigs.yaml 中 SIG-Auth 的目录与子项目定义出发对照 SIG-Auth 现状 与 章程再回到本份纪要按时间线重读每个决策的前因后果——会议纪要记录的是为什么而代码仓库沉淀的是是什么。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
