多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

ingress-nginx Helm Chart 3.25.0 解析:通过 automountServiceAccountToken 收紧服务账户令牌权限

ingress-nginx Helm Chart 3.25.0 解析:通过 automountServiceAccountToken 收紧服务账户令牌权限 ingress-nginx Helm Chart 3.25.0 解析通过 automountServiceAccountToken 收紧服务账户令牌权限【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginxingress-nginx Helm Chart 的 3.25.0 版本做了一项面向安全加固的小型但重要的变更允许用户在 Chart 中显式指定automountServiceAccountToken对应上游 PR #6957。阅读本文可以了解该字段在 ServiceAccount、Pod spec 两层的语义与区别、Chart 中三处新增配置项的默认值与作用范围以及如何利用它遵循最小权限原则部署 ingress-nginx。3.25.0 版本变更内容Helm Chart 的变更记录维护在 helm-chart-3.25.0.md 中该版本仅包含一条功能性变更Add ability to specify automountServiceAccountToken按照语义化版本semver规则新增能力属于 minor 版本递增3.24.0 → 3.25.0。作为参照前一个版本 helm-chart-3.24.0.md 的变更是 Add volumes to default-backend deployment为 default-backend 的 Deployment 增加 volumes 支持可见 3.25.0 延续了为 Chart 增加缺失的可配置项这一迭代方向。这些 changelog 条目由 helm-chart.md.gotmpl 模板在发版时自动生成。需要说明适用前提当前仓库中 Chart 的版本已演进到更高版本见 Chart.yaml但 3.25.0 引入的automountServiceAccountToken配置体系至今保留在 Chart 中其模板与测试结构均未被改动。背景automountServiceAccountToken 控制什么在 Kubernetes 中Pod 内进程能否访问 API Server 取决于其 ServiceAccount 令牌是否被自动挂载通常挂载到/var/run/secrets/kubernetes.io/serviceaccount/token。这一行为由两层字段控制ServiceAccount 级ServiceAccount.spec.automountServiceAccountToken作为该 SA 下所有 Pod 的默认值Pod 级Pod.spec.automountServiceAccountToken优先级更高逐 Pod 覆盖 SA 级默认值。从安全角度看自动挂载令牌意味着 Pod 内的任何进程包括被入侵的容器都能以该 ServiceAccount 的身份访问 API Server实际可执行的操作边界取决于该 SA 绑定的 RBAC 规则。因此业界通用做法是对不需要调用 API 的 Pod 关闭自动挂载从源头削减凭据暴露面。ingress-nginx 仓库自身也在 hardening-guide.md 中专门讨论了控制器部署的加固策略automountServiceAccountToken正是其中最常被提到的一项。3.25.0 之前Chart 对这一字段没有暴露配置入口3.25.0 之后用户可以完全控制 Chart 所创建的全部 ServiceAccount 及其工作负载的令牌挂载行为。Chart 中新增的三处配置项本次变更加入了三个 values 键在 values.yaml 中均默认设为true保持向后兼容values 键默认值定义位置作用对象serviceAccount.automountServiceAccountTokentruevalues.yamlingress-nginx 控制器 ServiceAccountcontroller Deployment/DaemonSetdefaultBackend.serviceAccount.automountServiceAccountTokentruevalues.yamldefault-backend ServiceAccountcontroller.admissionWebhooks.patch.serviceAccount.automountServiceAccountTokentruevalues.yaml准入 webhook patch Job 使用的 ServiceAccountChart 的 README.md 参数表中将这三项的默认值描述为{automountServiceAccountToken:true,create:true,name:}等对象形式与 values.yaml 一致。模板实现SA 级与 Pod 级双写深入模板可以看出Chart 对每一组组件都做了SA 级 Pod 级双写这是理解该特性的关键细节。控制器controllerSA 级controller-serviceaccount.yaml 中直接输出automountServiceAccountToken: {{ .Values.serviceAccount.automountServiceAccountToken }}Pod 级controller-deployment.yaml 与 controller-daemonset.yaml 的 Pod spec 中同样写入automountServiceAccountToken且与serviceAccountName相邻声明。之所以在 Pod spec 层再写一次从源码结构看有两层考虑其一Pod 级字段会覆盖 SA 级默认值双写保证即使外部 SA 的默认行为不同Chart 渲染结果仍然确定其二当用户通过serviceAccount.create: false使用外部 SA 时SA 模板不再生效Pod 级声明仍能约束令牌挂载行为。default-backendSA 级default-backend-serviceaccount.yamlPod 级default-backend-deployment.yaml。准入 webhook patch Jobwebhook 证书补丁由 pre-install/pre-upgrade hook 触发的 Job 完成涉及三个模板SA 级job-patch/serviceaccount.yaml该 SA 带有helm.sh/hook注解Pod 级job-createSecret.yaml创建 Secret 的 Job与 job-patchWebhook.yaml打补丁的 Job。实战哪些组件适合关闭自动挂载结合各组件的职责可以推断合理的配置策略default-backend最典型的关闭对象。default-backend 只是静态返回 404/503 的简单后端从源码结构看它不需要调用 Kubernetes API。关闭后即使该组件被攻破攻击者也无法从 Pod 内窃取有效的 API 凭据defaultBackend: serviceAccount: automountServiceAccountToken: false控制器需谨慎评估。控制器依赖 API 凭据监听 Ingress、Service、EndpointSlice 等资源仓库的控制器代码internal/ingress/controller/、internal/k8s/大量使用 API Client因此绝大多数场景应保持serviceAccount.automountServiceAccountToken: true仅在使用 TokenRequest API、自动挂载方式由平台策略统一管控等场景下才考虑调整。webhook patch Job临时组件。该 Job 需要访问 API 以创建/修改 Secret 和 ValidatingWebhook运行时间极短如果集群策略要求零自动挂载可以评估将 Job 设为false并同时确认其凭据获取方式但默认保持true是安全的。一个更完整的示例# values.yaml 片段 serviceAccount: create: true automountServiceAccountToken: true # 控制器需要 API 访问保持开启 defaultBackend: serviceAccount: automountServiceAccountToken: false # 后端无需 API 访问关闭 controller: admissionWebhooks: patch: serviceAccount: automountServiceAccountToken: true # patch Job 需要 API 访问渲染验证命令在仓库外执行helm template ingress-nginx ./charts/ingress-nginx \ --set defaultBackend.serviceAccount.automountServiceAccountTokenfalse \ | grep -n automountServiceAccountToken测试证据单元测试覆盖的断言行为Chart 使用 helm-unittest 风格的 YAML 测试验证渲染结果3.25.0 的变更配套了覆盖全部三个组件的测试controller-serviceaccount_test.yaml设置serviceAccount.automountServiceAccountToken: false后断言渲染出的 ServiceAccount 中automountServiceAccountToken为falsecontroller-deployment_test.yaml 与 daemonset 对应测试 controller-daemonset_test.yaml断言spec.template.spec.automountServiceAccountToken为false证明 Pod 级字段确实随 values 变化default-backend-serviceaccount_test.yamldefault-backend SA 的同名断言webhook patch 一侧job-patchWebhook_test.yaml 与 serviceaccount_test.yaml 分别覆盖 Job Pod spec 与 SA 两层。这些测试共同确认了双写实现的正确性无论修改哪个 values 键SA 模板与 Pod spec 模板会同步渲染出一致的值。小结ingress-nginx Helm Chart 3.25.0 的这条 changelog 对应一次典型的安全加固能力补齐新增serviceAccount、defaultBackend.serviceAccount、controller.admissionWebhooks.patch.serviceAccount三组automountServiceAccountToken配置默认均为true以兼容存量部署实现上采用 ServiceAccount 级与 Pod spec 级双写覆盖控制器 Deployment/DaemonSet、default-backend 以及 webhook patch Job 三类工作负载对无需 API 访问的组件如 default-backend建议显式置false以落实最小权限原则控制器本身因依赖 API 凭据应保持开启或依据平台统一策略评估变更行为有完整的 helm-unittest 用例佐证渲染结果可通过helm template直接验证。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表