namespace 本身不提供安全隔离，需组合 resourcequota/limitrange、networkpolicy、rbac、亲和性与节点标签等机制实现多层隔离。

不同命名空间的应用默认不自动隔离，需要组合多种机制才能实现真正可用的隔离效果。仅靠 Namespace 本身只是逻辑分组，不是安全边界。

资源配额限制（ResourceQuota + LimitRange）

防止某个命名空间耗尽集群资源，是隔离的第一道防线。

• 为每个命名空间定义 ResourceQuota，限制 CPU、内存、Pod 数量等总量
• 配合 LimitRange 设置 Pod/Container 默认请求与上限，避免单个容器抢占过多资源
• 注意：ResourceQuota 不限制节点级资源（如磁盘 IO、网络带宽），这些需靠底层 CNI 或节点配置补充

网络通信控制（NetworkPolicy）

Namespace 默认互通，必须显式启用 NetworkPolicy 才能切断跨命名空间访问。

Kubernetes Security Posture Scorecard

评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……

下载

• 在命名空间中启用 NetworkPolicy（需 CNI 插件支持，如 Calico、Cilium、Tungsten Fabric）
• 默认拒绝所有入站/出站流量，再按需放行：例如只允许同命名空间内通信，或仅允许访问特定共享服务（如 Redis、DB）
• 跨命名空间调用必须通过 Service FQDN（如 svc-name.namespace.svc.cluster.local），且该 Service 必须被 NetworkPolicy 显式允许

权限与可见性隔离（RBAC + 命名空间绑定）

确保用户、服务账号只能操作指定命名空间内的资源。

• 使用 Role（命名空间级别）+ RoleBinding，而非 ClusterRole（除非必要）
• 避免给租户授予 cluster-admin 或跨命名空间的 list/watch 权限
• ServiceAccount 应限定在命名空间内创建，并绑定最小权限 Role

调度与运行时隔离（亲和性 + 节点标签）

让关键应用避开干扰，或物理分散高风险租户。

• 利用 podAntiAffinity 配合 namespaces 字段，主动避开其他命名空间的同类 Pod（需显式指定目标命名空间列表）
• 为敏感租户打节点标签（如 tenant=finance），再用 nodeSelector 或 nodeAffinity 将其调度到专用节点组
• 注意：亲和性规则默认只在当前命名空间生效，跨命名空间需手动列出 namespaces 或使用 namespaceSelector