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 展示了策略评审的完整流程,从代码提交到合规验证的闭环。
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 合并前触发策略扫描,确保“不合规不合并”。