4、审计日志来源：API Server审计日志、kubelet日志、容器运行时日志、etcd日志、云平台审计日志

云原生安全基线的变更可能发生在集群的任意一层——从控制面组件到工作节点，再到底层云基础设施。为了实现对变更的完整追溯与合规审计，安全团队必须建立多源日志聚合分析能力。本章逐一解析五大核心审计日志来源的生成机制、关键字段与采集策略。

4.1 五大日志来源全景

下表从日志生成位置、记录对象、典型事件三个维度对比各来源的差异：

日志来源 生成位置 记录对象 典型基线变更事件
API Server 审计日志 控制面 Master 节点 所有对 Kubernetes API 的请求 创建/修改/删除 Pod、RBAC 规则、NetworkPolicy、ConfigMap
kubelet 日志 工作节点 节点级容器管理操作 Pod 启动/停止、镜像拉取、节点状态变更
容器运行时日志 工作节点 容器生命周期与隔离操作 容器创建/销毁、命名空间切换、挂载操作
etcd 日志 控制面 Master 节点 集群状态数据的读写操作 密钥/配置数据变更、集群元数据篡改
云平台审计日志 云服务商基础设施层 云资源 API 调用 安全组规则变更、IAM 策略修改、存储桶权限调整
审计要点：单一日志源只能反映变更的局部视图。例如，攻击者通过云平台 IAM 修改了节点实例角色权限，随后在 API Server 中创建了特权容器——只有将 CloudTrail 与 API Server 审计日志关联分析，才能还原完整的攻击链。

4.2 API Server 审计日志

API Server 审计日志是 Kubernetes 安全审计的核心数据源。它记录了对集群资源的所有读写操作，包括请求来源、操作类型、资源对象、响应状态等关键信息。

4.2.1 日志结构与关键字段

每条审计日志以结构化 JSON 格式输出，以下为精简后的核心字段示例：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {
    "username": "admin@example.com",
    "groups": ["system:masters"]
  },
  "sourceIPs": ["192.168.1.100"],
  "objectRef": {
    "resource": "pods",
    "namespace": "default",
    "name": "malicious-pod"
  },
  "responseStatus": {
    "code": 201
  },
  "requestObject": {
    "spec": {
      "containers": [{
        "image": "malicious:latest",
        "securityContext": {
          "privileged": true
        }
      }]
    }
  },
  "stageTimestamp": "2025-03-15T10:30:00Z"
}

4.2.2 审计策略配置

通过 --audit-policy-file 参数控制日志记录粒度。推荐基线变更场景下的策略配置：

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 记录所有对核心安全资源的变更
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts"]
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]
      - group: "networking.k8s.io"
        resources: ["networkpolicies"]
      - group: "policy"
        resources: ["podsecuritypolicies"]
  # 记录所有对 Pod 的创建和删除
  - level: Request
    verbs: ["create", "delete", "update", "patch"]
    resources:
      - group: ""
        resources: ["pods"]
  # 默认不记录只读请求
  - level: None

4.3 kubelet 日志

kubelet 日志记录了节点上容器运行时的实际状态变化。当 API Server 审计日志显示 Pod 创建成功，但 kubelet 日志显示镜像拉取失败或容器启动被安全策略拦截时，这种不一致性往往是安全事件的重要信号。

4.3.1 关键日志事件

  • Pod 生命周期事件： Pod 创建、启动、健康检查失败、被驱逐
  • 镜像操作事件： 镜像拉取、镜像拉取失败、镜像签名验证失败
  • 节点状态事件： 节点注册、节点心跳异常、节点磁盘压力
  • 安全策略执行事件： PodSecurityPolicy 拒绝、AppArmor/SELinux 违规

4.3.2 采集方式

kubelet 日志通常通过 journalctl 或节点上的日志代理采集：

# 查看 kubelet 实时日志
journalctl -u kubelet -f

# 按时间范围过滤
journalctl -u kubelet --since "2025-03-15 10:00:00" --until "2025-03-15 11:00:00"

4.4 容器运行时日志

容器运行时（如 containerd、CRI-O）日志提供了比 kubelet 更底层的容器操作记录，包括命名空间隔离、挂载点操作、cgroup 资源限制等。这些日志对于检测容器逃逸和资源滥用行为至关重要。

4.4.1 关键审计事件

事件类型 日志示例 安全含义
容器创建 CreateContainer: container_id="abc123" image="ubuntu:latest" 记录容器启动时的镜像和参数
挂载操作 Mount: source="/host/proc" target="/proc" 检测敏感主机路径挂载
命名空间操作 SetNamespace: pid=1234 ns=pid 检测命名空间逃逸尝试
资源限制变更 UpdateCgroup: memory_limit=4G 检测资源限制被移除或降低

4.5 etcd 日志

etcd 作为 Kubernetes 的持久化存储后端，其日志记录了所有集群状态数据的读写操作。由于 etcd 直接存储 Secrets、ConfigMaps 等敏感数据，其日志对于检测数据泄露和配置篡改具有不可替代的价值。

安全警告：etcd 日志可能包含明文敏感数据（如 TLS 证书、密钥内容）。在日志采集和存储过程中，必须实施脱敏处理或访问控制，避免日志本身成为新的数据泄露渠道。

4.5.1 关键监控指标

  • 写入速率异常： 短时间内大量 PUT/DELETE 操作，可能表示配置批量篡改
  • 密钥读取频率： 对 Secrets 目录的频繁读取，可能表示凭证窃取
  • 租约操作： 租约创建/撤销异常，可能表示节点欺骗攻击
  • 集群成员变更： 新增/移除 etcd 节点，可能表示控制面被入侵

4.6 云平台审计日志

当 Kubernetes 集群运行在云环境中时，云平台审计日志（AWS CloudTrail、Azure Monitor、GCP Audit Logs）记录了基础设施层的所有 API 调用。这些日志是检测基础设施层基线变更的唯一可靠来源。

4.6.1 各平台关键事件映射

云平台 服务 关键审计事件 对应 Kubernetes 影响
AWS CloudTrail ModifySecurityGroupRules, AttachRolePolicy, CreateNetworkAcl 节点网络策略、节点 IAM 权限变更
Azure Monitor Microsoft.Network/networkSecurityGroups/securityRules/write, Microsoft.Authorization/roleAssignments/write 虚拟网络隔离、RBAC 权限变更
GCP Audit Logs compute.firewalls.patch, iam.roles.update, storage.buckets.setIamPolicy 防火墙规则、服务账号权限、存储桶访问策略变更

4.7 多源日志聚合架构

下图展示了从日志采集到聚合分析的完整架构，各日志源通过不同的采集通道汇聚到统一分析平台：

多源审计日志聚合架构图 多源审计日志聚合架构 日志源层 API Server kubelet 容器运行时 etcd 云平台审计日志 采集通道层 Fluentd / Filebeat journald / Filebeat containerd 审计插件 etcd 日志转发 CloudTrail / Monitor 消息队列 / 缓冲层 Kafka / PubSub / Event Hubs 聚合分析层 SIEM / 日志分析平台 (ELK / Splunk / Azure Sentinel) 输出层 合规报告 / 告警通知 / 仪表盘

4.8 日志聚合的关键挑战与应对

最佳实践：在实施多源日志聚合时，建议优先建立时间同步机制（NTP）和统一日志格式（如将各源日志转换为 ECS 或 CEF 标准格式），这是后续关联分析的基础。
挑战 描述 应对策略
时间偏差 各日志源时间戳不一致，导致事件顺序错乱 所有节点配置 NTP 服务；在日志采集时记录采集时间戳
日志量巨大 大规模集群每天产生 TB 级日志 实施日志分级存储；热数据保留 7 天，冷数据归档至对象存储
格式异构 JSON、syslog、二进制日志格式并存 使用 Logstash/Fluentd 进行格式归一化
敏感数据泄露 日志中可能包含密钥、证书、密码 在采集管道中实施正则脱敏或字段过滤
关联分析困难 同一事件在不同日志源中的标识不同 建立统一的关联 ID（如 Pod UID、请求审计 ID）

4.9 基线变更场景的日志关联示例

以下是一个典型的基线变更攻击场景，展示各日志源如何协同记录完整攻击链：

  1. 云平台审计日志：攻击者通过 AWS CloudTrail 修改了节点安全组规则，开放了 22 端口（SSH）
  2. API Server 审计日志：攻击者创建了一个特权 Pod，挂载了宿主机 /var/run/docker.sock
  3. kubelet 日志：记录该 Pod 被调度到目标节点并启动成功
  4. 容器运行时日志：记录容器创建时挂载了宿主机 Docker socket
  5. etcd 日志：记录该 Pod 的配置数据被写入 etcd 存储

通过聚合分析这五类日志，安全团队可以完整还原攻击路径：从基础设施层权限提升 → 控制面资源创建 → 节点级容器逃逸 → 持久化数据写入。

← 上一章 📖 返回目录 下一章 →