要实现应用间高等级隔离，需构建“命名空间+RBAC+网络策略+安全上下文”四层防线：命名空间划分信任域并配ResourceQuota/PSA；RBAC按角色最小授权；NetworkPolicy默认拒绝、白名单放行；SecurityContext强制非root、只读根文件系统、seccomp与capabilities管控。
要实现应用间的高等级隔离，不能只靠容器本身的基础隔离，必须依托容器编排系统（如 Kubernetes）的权限控制策略，构建“命名空间 + RBAC + 网络策略 + 安全上下文”四层防线。核心不是把权限收得越紧越好，而是让每个应用只拥有完成自身任务所必需的最小权限边界，同时阻断跨应用的非预期通信和资源访问。
命名空间级物理隔离：划分信任域
命名空间（Namespace）是 Kubernetes 中最基础、最有效的逻辑隔离单元。它不仅是资源分组单位，更是权限作用域的锚点。
- 为不同业务线、环境（prod/staging/dev）、安全等级（如 PCI 合规服务）单独创建命名空间，避免共享默认命名空间
- 配合 ResourceQuota 和 LimitRange 限制 CPU、内存、Pod 数量，防止单个应用耗尽集群资源影响其他应用
- 启用 Pod Security Admission（PSA） 并在命名空间级别强制执行
restricted模板，自动拒绝不合规 Pod 创建（如使用特权模式、挂载主机路径等）
RBAC 细粒度授权：按角色而非用户分配权限
RBAC 不是给开发人员开后门的工具，而是定义“谁能在哪个命名空间里对哪些资源执行哪些操作”的策略引擎。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 避免使用
cluster-admin，为每个应用团队创建专属 ServiceAccount，并绑定仅限本命名空间的 RoleBinding - 禁止授予
get secrets权限给非密钥管理组件；数据库连接串、API Token 必须通过 Secret 注入，且仅允许对应应用的 SA 访问 - 对运维类工具（如日志采集、指标 exporter）单独建 SA，并通过
verbs: ["get", "list"]限定只读权限，禁用delete或patch
NetworkPolicy 强制网络微隔离：默认拒绝，显式放行
即使在同一命名空间内，应用之间也不应默认互通。NetworkPolicy 是实现东西向流量控制的关键手段。
- 每个命名空间部署一条 默认拒绝所有入站/出站 的策略（空
podSelector+ 空policyTypes），作为安全基线 - 为前端 → 后端、后端 → 数据库等明确依赖链，编写白名单策略，精确匹配源/目标标签、端口、协议
- 使用
ipBlock限制外部调用方 IP 段（如只允许 API 网关 CIDR），并结合namespaceSelector防止跨命名空间误连
Pod 安全上下文深度加固：从运行时切断提权路径
安全上下文（SecurityContext）决定容器进程如何在节点上运行，是最后一道防线。
- 强制设置
runAsNonRoot: true和固定runAsUser/runAsGroup，杜绝 root 进程启动 - 启用
readOnlyRootFilesystem: true，配合volumeMounts显式声明可写路径（如/tmp、/var/log） - 添加
seccompProfile（如runtime/default）过滤危险系统调用，配合capabilities.drop: ["ALL"]+ 按需add（如仅NET_BIND_SERVICE） - 在节点侧启用 SELinux 或 AppArmor，并在 Pod 中指定
seLinuxOptions或appArmorProfile，实现内核级强制访问控制
不复杂但容易忽略：这些策略必须协同生效。比如 NetworkPolicy 再严格，若 Pod 允许 hostNetwork: true，就直接绕过全部网络隔离；RBAC 控制再细，若命名空间没设 ResourceQuota，一个失控的 Job 就可能拖垮整个节点。实战中建议用 OPA/Gatekeeper 或 Kyverno 做策略准入校验，把隔离要求固化为不可绕过的集群规则。
