Kubernetes安全上下文用于控制 Pod 和容器在节点上的运行权限。它不直接修复应用漏洞，却能限制容器被入侵或配置错误后的影响范围。很多生产环境的风险不是来自复杂攻击，而是容器默认以 root 运行、允许特权模式、挂载宿主机敏感路径、保留过多 Linux capabilities，导致一个普通应用容器拥有了不必要的节点级能力。
安全上下文配置的目标不是让所有容器都无法运行，而是在满足业务需求的前提下执行最小权限原则。默认收紧权限，确有需要时通过例外流程放开，并保留审计和复核。这比上线前人工检查每个 YAML 更可靠。
Pod级和容器级配置有什么区别
SecurityContext 可以配置在 Pod 级，也可以配置在容器级。Pod 级配置会作为容器的默认安全设置，容器级配置可以覆盖部分字段。常见字段包括 runAsUser、runAsGroup、fsGroup、runAsNonRoot、privileged、allowPrivilegeEscalation、capabilities、readOnlyRootFilesystem 等。
建议平台提供默认 Pod 安全基线，业务应用在此基础上尽量少改。比如默认要求非 root 运行、禁止特权容器、禁止权限提升、丢弃不必要 capabilities。对于确实需要更高权限的基础设施组件，应单独放在受控命名空间，并由平台团队管理。
不要让业务团队每次从零选择所有安全字段。安全上下文应成为模板的一部分，而不是可有可无的附加项。
非root运行是基础要求
容器内 root 不等于宿主机 root，但它仍然增加风险。若容器逃逸、挂载敏感目录或应用存在写文件漏洞，以 root 运行会放大影响。生产业务容器应尽量使用非 root 用户运行，并在镜像构建阶段创建固定用户。
一个基本配置示例：
securityContext:
runAsNonRoot: true
runAsUser: 10001
runAsGroup: 10001这类配置需要与镜像内部文件权限配合。如果应用目录、日志目录或临时目录只有 root 可写，强行切换非 root 会导致启动失败。因此非 root 不是只改 Kubernetes YAML，还要在镜像构建阶段处理文件归属和运行用户。
特权容器要作为强例外
privileged 容器几乎拥有宿主机级别的能力，常用于 CNI、CSI、节点监控或安全代理等基础设施组件。普通业务应用通常不应使用 privileged。若生产业务需要特权容器，应重新评估架构，因为这可能意味着业务在依赖宿主机能力。
特权容器风险包括访问宿主机设备、修改网络、影响内核参数、绕过部分隔离边界。即使没有恶意攻击，配置错误也可能影响节点上其他工作负载。
平台可以在准入策略中默认拒绝普通命名空间的 privileged 容器，只允许特定系统命名空间和特定服务账号使用。例外应包含原因、负责人、有效期和复核机制。
capabilities要按需授予
Linux capabilities 把 root 权限拆分成多个能力，例如 NET_ADMIN、SYS_ADMIN、CHOWN、DAC_OVERRIDE 等。容器默认可能保留一些能力，但多数业务应用并不需要额外 capabilities。安全基线通常建议丢弃全部或大部分能力，再按需添加。
示例配置：
securityContext:
capabilities:
drop:
- ALL如果应用确实需要绑定低端口、调整网络或执行特定系统操作，应明确添加对应 capability，而不是直接使用 privileged。尤其是 SYS_ADMIN，权限范围很大，应尽量避免授予业务容器。
Capabilities 治理的重点是可解释。每个额外能力都应有明确原因，否则很容易变成复制模板时遗留的风险。
禁止权限提升和只读根文件系统
allowPrivilegeEscalation 控制进程是否可以获得比父进程更多权限。生产环境建议默认设置为 false，减少通过 setuid 等方式提升权限的风险。
readOnlyRootFilesystem 可以让容器根文件系统只读，降低运行时被篡改的风险。启用后，应用需要写入的目录应通过 emptyDir、PVC 或专用挂载提供，例如 /tmp、缓存目录或运行时文件目录。这个配置对无状态服务和安全要求高的服务很有价值，但需要提前验证应用写文件行为。
只读根文件系统不是所有应用都能立即启用。老应用可能默认写日志到本地文件、写临时文件到工作目录。改造时应先识别写路径，再迁移到标准输出或明确挂载目录。
与Pod安全标准和准入策略配合
Kubernetes 安全上下文最好通过准入策略统一执行。Pod Security Standards、准入控制器或策略引擎可以对不同命名空间应用不同等级规则。例如开发环境先提示，生产环境强制禁止高风险配置。
建议把规则分为三类：必须阻断、需要审批、建议优化。特权容器、hostPath敏感目录、未知镜像仓库可以作为阻断项；额外 capabilities、root 运行可以作为审批或告警项；只读根文件系统、资源限制等可以作为优化建议逐步推进。
准入策略要提供清晰错误信息。只告诉研发“策略拒绝”没有帮助，应明确哪个字段不符合要求、为什么拒绝、如何修复、如何申请例外。
常见问题
所有容器都必须非root运行吗？
生产业务容器应尽量非 root 运行，但基础设施组件可能确实需要更高权限。关键是区分业务应用和系统组件。业务应用如果无法非 root 运行，应检查镜像文件权限、启动脚本和应用写路径，而不是直接放弃最小权限原则。
privileged和capabilities有什么区别？
privileged 会大幅放开容器权限，接近宿主机级别能力；capabilities 是按能力维度细粒度授权。能用具体 capability 解决的场景，不应直接使用 privileged。对于业务容器，额外 capability 也应有明确理由和审计记录。
只读根文件系统会影响应用运行吗？
可能会。应用如果需要写临时文件、缓存、日志或运行时文件，就需要把这些路径挂载为可写卷。启用前应先识别写路径，并把日志迁移到标准输出。改造完成后，只读根文件系统能显著降低运行时篡改风险。
安全上下文能防止所有容器逃逸吗？
不能。安全上下文是降低权限和缩小影响面的基础措施，不是完整安全方案。还需要镜像治理、漏洞修复、运行时防护、网络策略、RBAC、节点加固和审计能力共同配合。它的价值在于减少默认高权限带来的风险。
结语
Kubernetes安全上下文配置的核心，是把最小权限原则落到每个 Pod 和容器。非 root、禁止特权、限制 capabilities、禁止权限提升、只读根文件系统和准入策略结合起来，可以显著降低容器运行风险。真正成熟的做法，是把这些规则内置到平台模板和发布流程中，让安全成为默认路径。
转载请注明出处：https://www.cloudnative-tech.com/p/7487/
