4. K8s 策略评审最佳实践:最小权限原则、命名空间隔离、资源配额策略、安全上下文策略

策略评审是保障 Kubernetes 集群安全与稳定运行的核心环节。本章聚焦于四项关键策略的最佳实践:最小权限原则、命名空间隔离、资源配额策略与安全上下文策略。通过系统化的评审与实施,可显著降低攻击面、防止资源争抢并提升合规性。

核心目标: 将安全与效率内建于策略之中,而非事后补救。策略评审应作为 CI/CD 流水线的一环,实现“策略即代码”。

4.1 最小权限原则:从 RBAC 到 ServiceAccount

最小权限原则要求每个实体(用户、Pod、ServiceAccount)仅获得完成其任务所必需的最小权限集。在 K8s 中,这主要通过 RBAC(基于角色的访问控制) 实现。

4.1.1 RBAC 角色与绑定评审清单

评审项 最佳实践 常见风险
ClusterRole 范围 优先使用 Role(命名空间级),仅在需要跨 NS 资源时使用 ClusterRole 滥用 ClusterRole 导致全局提权
动词粒度 使用 get、list、watch 替代 * 授予 create、delete 等破坏性操作
资源限制 明确指定资源名称,避免使用 resources: ["*"] Pod 可操作 Secrets、ConfigMaps 等敏感资源
ServiceAccount 绑定 每个应用使用独立 SA,不共享默认 SA 默认 SA 挂载到 Pod 导致凭证泄露
聚合规则 使用 aggregationRule 组合细粒度 ClusterRole 单一 ClusterRole 包含过多权限

4.1.2 自动化审计命令

# 检查所有 ClusterRole 中是否包含通配符资源
kubectl get clusterrole -o json | jq '.items[] | select(.rules[].resources[] == "*") | .metadata.name'

# 检查默认 ServiceAccount 是否被绑定到 Role
kubectl get rolebinding -A -o json | jq '.items[] | select(.subjects[].name == "default") | .metadata.namespace'
评审技巧: 使用 kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> 模拟特定 SA 的权限,验证最小权限是否满足。

4.2 命名空间隔离:逻辑边界与网络策略

命名空间(Namespace)是 K8s 中实现多租户隔离的基本单元。但仅靠命名空间无法提供网络隔离,必须配合 NetworkPolicy 和 ResourceQuota 才能形成完整的安全边界。

4.2.1 命名空间设计模式

  • 环境隔离: 为 dev、staging、prod 分别创建独立命名空间,避免资源混淆。
  • 团队隔离: 每个团队拥有专属命名空间,配合 RBAC 限制跨团队访问。
  • 应用隔离: 复杂应用(如微服务)使用独立命名空间,便于故障域隔离。
  • 系统组件隔离: 将 kube-system、ingress-nginx、monitoring 等系统组件放入专用命名空间。

4.2.2 默认拒绝网络策略

在关键命名空间中,应部署默认拒绝所有入站/出站流量的 NetworkPolicy,然后按需放行。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
注意: 如果集群 CNI 插件不支持 NetworkPolicy(如 Flannel),则命名空间隔离仅停留在逻辑层面,无法实现网络隔离。建议使用 Calico、Cilium 或 Weave Net。

4.3 资源配额策略:防止资源争抢与容量规划

ResourceQuota 和 LimitRange 是控制命名空间资源消耗的关键策略。评审时应关注配额设置的合理性与完整性。

4.3.1 资源配额评审要点

策略类型 评审项 推荐值
ResourceQuota CPU/内存硬限制 根据节点容量预留 20% 缓冲
ResourceQuota 存储请求限制 按 PVC 类型分别设置(ssd/hdd)
ResourceQuota 对象数量限制 Services: 50, Secrets: 100, ConfigMaps: 100
LimitRange 默认 request/limit request: 256m/512Mi, limit: 1/2Gi
LimitRange 最小/最大限制 min: 128m/256Mi, max: 4/8Gi

4.3.2 配额冲突检测

# 查看命名空间当前配额使用率
kubectl describe quota -n <namespace>

# 检查是否有 Pod 因配额不足而 Pending
kubectl get pods -n <namespace> --field-selector=status.phase=Pending
最佳实践: 为每个命名空间同时配置 ResourceQuota 和 LimitRange。LimitRange 确保未设置资源限制的 Pod 不会无限使用资源,ResourceQuota 则从总量上控制命名空间整体消耗。

4.4 安全上下文策略:Pod 与容器的安全基线

SecurityContext 定义了 Pod 或容器的权限与访问控制属性。评审时应重点关注以下维度:

4.4.1 安全上下文关键字段

字段 作用 推荐配置
runAsNonRoot 禁止以 root 用户运行容器 true
runAsUser 指定容器运行 UID 1000-65535 之间的非 root UID
readOnlyRootFilesystem 将根文件系统设为只读 true(配合 emptyDir 写入临时数据)
allowPrivilegeEscalation 禁止进程获取更多权限 false
capabilities.drop 删除不需要的 Linux Capabilities ["ALL"] 后按需添加
seccompProfile 限制系统调用 RuntimeDefault 或 Localhost

4.4.2 Pod Security Standards (PSS) 集成

K8s 1.23+ 推荐使用 Pod Security Admission 替代废弃的 PodSecurityPolicy。PSS 定义了三个等级:

  • Privileged: 无限制,仅用于系统级组件。
  • Baseline: 禁止已知的提权行为,适用于大多数应用。
  • Restricted: 遵循 Pod 安全最佳实践,适用于高安全环境。
# 为命名空间启用 Restricted 级别
apiVersion: v1
kind: Namespace
metadata:
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
常见误区: 仅设置 runAsNonRoot: true 但未指定 runAsUser,容器仍可能以镜像中默认的非 root 用户运行,但该用户可能拥有过多权限。应同时指定明确的 UID。

4.5 策略评审综合流程图

以下 SVG 展示了策略评审的完整流程,从代码提交到合规验证的闭环。

K8s 策略评审闭环流程 1. 策略定义 RBAC / NetworkPolicy 2. 代码扫描 OPA / Kyverno / Checkov 3. 预检部署 Dry-run / Admission Webhook 4. 运行时审计 Falco / Audit Logs 5. 合规报告 CIS Benchmark / 自定义规则 6. 策略优化 最小权限调整 / 配额修正 关键评审节点说明 • 策略定义阶段:确保 RBAC 角色不包含通配符资源,NetworkPolicy 默认拒绝所有流量。 • 代码扫描阶段:使用 OPA Gatekeeper 或 Kyverno 在 CI 中拦截违反策略的 YAML。 • 运行时审计阶段:Falco 检测容器逃逸、敏感文件访问等异常行为。 • 策略优化阶段:根据审计结果动态收紧权限,形成持续改进闭环。

4.6 策略即代码:自动化评审工具链

将策略评审集成到 CI/CD 流水线中,实现自动化验证。推荐工具链如下:

阶段 工具 作用
静态分析 Checkov / KubeLinter 扫描 YAML 中的安全配置错误
策略引擎 OPA Gatekeeper / Kyverno Admission Webhook 实时拦截违规资源
运行时检测 Falco / Tracee 检测容器运行时异常行为
合规扫描 kube-bench / kube-hunter CIS Benchmark 合规性检查
可视化 Kubescape / Polaris 集群安全评分与可视化报告
# 使用 Checkov 扫描 K8s 清单
checkov -d ./k8s-manifests --framework kubernetes

# 使用 Kubescape 扫描集群
kubescape scan --enable-host-scan --format json --output report.json
推荐实践: 在 Git 仓库中维护 .policy/ 目录,存放所有策略定义(RBAC、NetworkPolicy、OPA 模板等),通过 GitOps 流程自动同步到集群。每次 PR 合并前触发策略扫描,确保“不合规不合并”。