📚 课程目录第3章安全基线规则分类

3. 安全基线规则分类

在跨集群安全基线管理中，规则分类是策略分发与一致性校验的基础。不同分类对应不同的 Kubernetes 原生资源对象与校验维度。本章将五类核心规则的定义、校验对象与常见风险进行结构化梳理。

3.1 规则分类总览

安全基线规则按管控维度分为以下五类，每类对应一组 Kubernetes 资源与校验策略：

分类	核心资源对象	校验维度	典型风险
身份认证与授权	RBAC (Role/ClusterRole, RoleBinding/ClusterRoleBinding), ServiceAccount	最小权限、绑定范围、匿名访问	越权操作、权限扩散、匿名用户访问 API Server
Pod 安全上下文	PodSecurityPolicy (PSP) / Pod Security Admission (PSA), SecurityContext	特权容器、Capabilities、Seccomp、RunAsNonRoot	容器逃逸、内核提权、Root 用户运行
网络策略	NetworkPolicy	入站/出站规则、命名空间隔离、默认拒绝	东西向流量未隔离、恶意 Pod 横向移动
资源限制	ResourceQuota, LimitRange, Pod 资源 requests/limits	CPU/内存上限、命名空间配额、服务质量 (QoS)	资源争抢、DoS 攻击、无限制 Pod 消耗集群资源
审计日志	AuditPolicy, AuditBackend (API Server 配置)	日志级别、事件覆盖、存储持久化	安全事件遗漏、日志丢失、无法溯源

基线对齐提示： 在跨集群场景中，不同集群可能使用不同版本的 Kubernetes（如 1.24 之前使用 PSP，之后使用 PSA）。规则分类必须包含版本兼容性映射，否则同步后可能产生校验失败。

3.2 身份认证与授权规则

身份认证与授权是安全基线的第一道防线。规则主要围绕 RBAC 与 ServiceAccount 展开，确保每个主体（用户、组、ServiceAccount）只拥有完成其任务所需的最小权限。

角色定义规则： 禁止使用 cluster-admin 等超级角色绑定到非管理用途的 ServiceAccount；所有自定义角色必须显式列出 verbs 和 resources，禁止使用通配符 *。
绑定范围规则： 命名空间级别的 RoleBinding 只能绑定本命名空间内的 ServiceAccount；跨命名空间绑定必须经过审批并记录。
匿名访问规则： 必须禁用匿名用户对 API Server 的访问（--anonymous-auth=false），并移除 system:anonymous 和 system:unauthenticated 的绑定。
ServiceAccount 自动挂载规则： 对于不需要与 API Server 通信的 Pod，必须设置 automountServiceAccountToken: false。

  跨集群校验要点： 在规则同步时，需要对比每个集群中所有 RoleBinding 和 ClusterRoleBinding 的 subjects 与 roleRef，确保没有“幽灵绑定”（即引用了不存在的 Role 或 ServiceAccount）。

3.3 Pod 安全上下文规则

Pod 安全上下文规则控制容器运行时的安全属性，是防止容器逃逸和权限提升的核心手段。在 Kubernetes 1.25+ 中，PSA（Pod Security Admission）已取代 PSP 成为主流标准。

安全上下文字段	基线要求	违反后果
`privileged`	必须为 `false`	容器拥有宿主机所有 Capabilities，极易逃逸
`runAsNonRoot`	必须为 `true`	容器以 Root 运行，可修改系统文件
`capabilities.drop`	必须包含 `ALL`	保留高危 Capability（如 SYS_ADMIN）
`seccompProfile.type`	必须为 `RuntimeDefault` 或 `Localhost`	未限制系统调用，增加攻击面
`allowPrivilegeEscalation`	必须为 `false`	容器内进程可通过 setuid 提权

版本兼容性警告： 如果集群仍在使用 PSP（K8s < 1.25），规则分类需要同时维护 PSP 模板和 PSA 标签（pod-security.kubernetes.io/enforce），并在同步时根据集群版本自动选择生效策略。

3.4 网络策略规则

网络策略规则通过 NetworkPolicy 资源实现微隔离，控制 Pod 之间以及 Pod 与外部服务的网络通信。基线要求采用“默认拒绝”模型。

默认拒绝入站： 每个命名空间必须至少有一条 NetworkPolicy 拒绝所有入站流量（ingress: []），除非有明确的白名单规则。
默认拒绝出站： 同样需要拒绝所有出站流量，仅允许必要的 DNS（端口 53）和业务端口。
命名空间隔离： 不同安全等级的命名空间之间必须显式设置 namespaceSelector 和 podSelector，禁止使用 ipBlock 绕过。
策略冲突检测： 当多条 NetworkPolicy 作用于同一组 Pod 时，规则是“或”关系（任一允许即放行）。基线校验必须检测是否存在意外放行的策略组合。

# 默认拒绝入站示例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

一致性校验难点： 网络策略的生效依赖于 CNI 插件（如 Calico、Cilium）。跨集群同步时，需要额外校验 CNI 插件版本与 NetworkPolicy 功能的兼容性，否则规则可能“静默失效”。

3.5 资源限制规则

资源限制规则防止单个 Pod 或命名空间耗尽集群资源，保障服务质量（QoS）与公平调度。规则分为三个层级：

层级	资源对象	基线要求
命名空间配额	ResourceQuota	每个命名空间必须设置 CPU 和内存的 `limits` 配额，禁止无限使用
默认限制	LimitRange	为未显式设置 requests/limits 的 Pod 提供默认值，避免无限制运行
Pod 级别	Pod spec.containers[].resources	所有容器必须设置 `requests` 和 `limits`，且 `limits` 不得超过 `requests` 的 2 倍（弹性比例）

QoS 保障： 禁止使用 BestEffort 类型的 Pod（即未设置任何资源限制），必须至少达到 Burstable 级别。
存储限制： ResourceQuota 必须包含 requests.storage 和 persistentvolumeclaims 的配额，防止存储耗尽。
跨集群一致性： 不同集群的节点规格可能不同（如 2C4G vs 8C16G），资源限制规则应使用相对比例而非值，或通过集群标签动态调整。

3.6 审计日志规则

审计日志规则确保所有安全相关操作被完整记录，满足合规与溯源需求。规则覆盖 API Server 的审计策略配置与日志后端。

审计级别： 对于敏感资源（如 Secrets、ConfigMaps、RBAC 配置），必须使用 RequestResponse 级别记录请求体和响应体；对于只读操作可使用 Metadata 级别。
事件覆盖： 必须记录所有 create、update、delete 操作，以及所有 get 操作中的敏感资源。
日志持久化： 审计日志必须输出到持久化存储（如 S3、GCS、本地磁盘），禁止仅输出到 stdout 导致日志丢失。
轮转与保留： 日志文件必须配置轮转策略（如按大小或时间），保留期至少 90 天。

# 审计策略片段（仅记录敏感资源的 RequestResponse）
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  resources:
  - group: ""
    resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

  跨集群同步挑战： 审计日志规则通常与集群的 API Server 启动参数绑定（--audit-policy-file），无法通过 Kubernetes API 直接读取。在跨集群一致性校验中，需要通过 SSH 或配置管理工具（如 Ansible）采集 API Server 的启动参数，再与基线策略对比。

3.7 规则分类与跨集群同步的映射关系

在跨集群规则同步中，五类规则的同步策略存在差异，主要取决于规则是 声明式资源（通过 Kubernetes API 管理）还是 配置式规则（通过启动参数或文件管理）。

规则分类	同步方式	一致性校验方法	同步优先级
身份认证与授权	Kubernetes API (CRD 或原生资源)	kubectl diff / 自定义控制器比对	高（直接影响访问控制）
Pod 安全上下文	PSA 标签 / OPA Gatekeeper 约束	标签校验 + 策略引擎审计	高（防止容器逃逸）
网络策略	Kubernetes API (NetworkPolicy)	策略覆盖度分析 + 连通性测试	中（依赖 CNI 实现）
资源限制	Kubernetes API (ResourceQuota, LimitRange)	配额对比 + 实际使用率监控	中（影响稳定性）
审计日志	节点配置文件 / Helm Chart	SSH 采集 + 配置比对	低（但合规要求高）

实践提醒： 审计日志规则无法通过 Kubernetes API 直接同步，需要借助 GitOps 或配置管理工具（如 Ansible、Puppet）将审计策略文件分发到每个集群的 Master 节点，并重启 API Server 生效。在一致性校验中，这类规则最容易出现“配置漂移”。

3.8 规则分类的最佳实践

按风险等级排序： 在跨集群同步时，优先同步身份认证与授权规则和 Pod 安全上下文规则，因为它们直接影响集群的安全边界。资源限制和审计日志规则可以稍后同步。
版本兼容性矩阵： 为每类规则建立版本兼容性矩阵（如 K8s 1.23 支持 PSP，1.25+ 仅支持 PSA），在同步控制器中根据集群版本自动选择规则模板。
规则分组与标签： 使用 Kubernetes 标签（如 security-baseline-class: auth）对规则资源进行分组，便于在一致性校验中按分类进行批量比对。
异常处理： 当某类规则在目标集群中同步失败时，不应阻塞其他规则的同步。建议为每类规则设置独立的同步队列和重试策略。