Kubernetes 审计日志深度解析：配置、使用、场景与最佳实践

“老铁们，今天咱们来聊聊 Kubernetes 里的一个‘隐形’但又至关重要的功能——审计日志（Audit Logging）。这玩意儿就像集群的‘黑匣子’，记录着谁、在什么时间、对集群做了什么。对于安全、故障排查、合规性审计来说，它可是个宝贝！别看它平时不声不响，关键时刻能救命！”

1. 为什么要用 Kubernetes 审计日志？

“你可能会问，我平时用 kubectl logs 看日志还不够吗？为啥还要搞个审计日志？”

“兄弟，kubectl logs 看到的只是容器的标准输出和错误输出，它可管不着谁创建了 Pod、谁修改了 Deployment、谁删除了 Namespace。而审计日志记录的是对 Kubernetes API Server 的所有请求，这才是集群操作的‘全貌’。”

“想象一下，如果有人偷偷摸摸地改了你的配置，或者更糟糕的，集群被‘黑’了，你却两眼一抹黑，不知道发生了什么，那得多抓狂？有了审计日志，一切操作都有迹可循，想赖都赖不掉！”

“除了安全，审计日志还能帮你：”

• 故障排查： 快速定位问题根源，比如哪个操作导致了服务异常。
• 合规性审计： 满足各种法规和标准的要求，证明你的集群操作是合规的。
• 性能优化： 分析 API Server 的请求模式，找出潜在的性能瓶颈。
• 资源使用分析： 了解集群资源的使用情况，为资源规划提供依据。

2. Kubernetes 审计日志的基本概念

“在深入之前，咱们先搞清楚几个基本概念，磨刀不误砍柴工嘛。”

• 审计事件（Audit Event）： 对 API Server 的每一次请求都会产生一个审计事件。它包含了请求的详细信息，比如：
  • 请求者（User）： 谁发起的请求，可能是用户、Service Account 或者系统组件。
  • 请求时间（Timestamp）： 请求发生的时间。
  • 请求阶段(Stage): RequestReceived, ResponseStarted, ResponseComplete, Panic
  • 请求动作（Verb）： 对资源的操作类型，比如 get、create、update、delete 等。
  • 请求资源（Resource）： 被操作的资源类型，比如 Pod、Deployment、Service 等。
  • 请求 URI（Request URI）： 请求的完整 URL。
  • 请求/响应体（Request/Response Object）： 请求和响应的具体内容（可选，取决于审计策略）。
  • 源 IP 地址（Source IP）： 发起请求的客户端 IP 地址。
  • 响应状态码（Response Status）： API Server 的响应状态码，比如 200、403、500 等。
• 审计级别（Audit Level）： 决定记录哪些信息，有四个级别：
  • None： 不记录任何审计日志。
  • Metadata： 只记录请求的元数据，比如请求者、时间、资源、动作等，不记录请求和响应体。
  • Request： 记录元数据和请求体，但不记录响应体。
  • RequestResponse： 记录元数据、请求体和响应体。
• 审计策略（Audit Policy）： 定义了哪些请求需要记录、记录哪些信息。它是一个 YAML 文件，包含一系列规则。
• 审计后端（Audit Backend）： 决定审计日志的存储位置和格式。Kubernetes 支持多种后端：
  • Log 后端： 将审计日志写入本地文件。
  • Webhook 后端： 将审计日志发送到远程 HTTP API。

3. 如何配置和启用 Kubernetes 审计日志？

“说了这么多，到底怎么用呢？别急，这就手把手教你。”

“配置审计日志主要分两步：”

1. 创建审计策略文件（Audit Policy）：

“这个文件定义了‘什么该记，什么不该记’，‘记到什么程度’。下面是一个示例：”

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 不记录 kube-system 命名空间下的 events 资源
  - level: None
    resources:
      - group: ""
        resources: ["events"]
    namespaces: ["kube-system"]
 
  # 不记录对 configmaps 或 secrets 的 get、list、watch 请求
  - level: None
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
        resources: ["configmaps", "secrets"]
  
 # 不记录特定用户的请求
  - level: None
    users: ["system:kube-proxy"]
 
  # 其他所有请求只记录元数据
  - level: Metadata

“这个策略文件里有几条规则，每条规则都指定了一个 level，表示审计级别。规则的匹配顺序是从上到下，只要匹配到一条规则，就不再往下匹配了。”

“你可以根据自己的需求定制这个策略文件，比如：”

• 只记录特定命名空间下的操作： namespaces: ["my-namespace"]
• 只记录特定用户的操作： users: ["my-user"]
• 只记录特定类型的资源操作： resources: [{group: "apps", resources: ["deployments"]}]
• 记录更详细的信息： level: RequestResponse

“记住，审计策略越详细，日志量越大，对性能的影响也越大。所以要根据实际需求权衡。”

2. 配置 API Server 启动参数：

“创建好策略文件后，需要告诉 API Server 使用这个策略文件。这需要在 API Server 的启动参数中添加几个选项：”

• --audit-policy-file=/path/to/audit-policy.yaml：指定审计策略文件的路径。
• --audit-log-path=/path/to/audit.log：指定审计日志的输出路径（Log 后端）。
• --audit-log-maxage=30：指定审计日志文件的最大保留天数（Log 后端）。
• --audit-log-maxbackup=10：指定审计日志文件的最大保留数量（Log 后端）。
• --audit-log-maxsize=100：指定审计日志文件的最大大小（MB）（Log 后端）。
• --audit-webhook-config-file=/path/to/webhook-config.yaml：指定 Webhook 配置文件的路径（Webhook 后端）。

“如果你使用的是 kubeadm 部署的集群，可以直接修改 /etc/kubernetes/manifests/kube-apiserver.yaml 文件，在 spec.containers[0].command 中添加这些参数。修改后，kubelet 会自动重启 API Server。”

“如果你使用的是其他方式部署的集群，请参考相应的文档修改 API Server 的配置。”

4. 审计日志的存储和分析

“日志生成了，怎么用呢？总不能每次都去服务器上看文件吧？”

“当然不！咱们得把日志收集起来，集中存储和分析。”

“常用的方法有：”

• Log 后端 + 日志收集工具：

  “这是最简单的方法，直接把日志写到文件里，然后用 Fluentd、Logstash、Filebeat 等工具把日志收集到 Elasticsearch、Splunk、Graylog 等日志分析平台。”

  “这种方式的优点是配置简单，缺点是需要额外部署日志收集工具。”

• Webhook 后端 + 日志分析平台：

  “这种方式直接把日志发送到远程 HTTP API，比如 Elasticsearch、Splunk、Graylog 等都提供了接收 Webhook 的接口。”

  “这种方式的优点是省去了日志收集工具，缺点是需要配置 Webhook，而且对网络有一定要求。”

• 日志收集工具 + Sidecar:
  "可以在每个node上部署日志收集工具，例如Fluentd、Logstash。并且通过Sidecar方式将收集的日志发送到远端。"

“不管用哪种方式，最终目的都是把日志收集到统一的平台，方便查询、分析、可视化。”

“在日志分析平台上，你可以：”

• 搜索： 根据关键字、时间范围、用户、资源等条件搜索日志。
• 过滤： 根据特定条件过滤日志，比如只看错误日志、只看特定用户的操作等。
• 聚合： 统计日志数量、计算平均值、最大值、最小值等。
• 可视化： 将日志数据以图表、仪表盘等形式展示出来，更直观地了解集群状态。
• 告警： 设置告警规则，当日志中出现异常情况时，自动发送通知。

5. 审计日志的实际应用场景

“说了这么多理论，咱们来点实际的，看看审计日志在实际工作中能干啥。”

• 安全事件追踪：

  “假设你发现集群里多了一个陌生的 Pod，或者某个 Service 的配置被修改了，你可以通过审计日志找到是谁干的，什么时候干的，怎么干的。”

  “你可以搜索包含 create pod 或 update service 的日志，然后根据时间、用户、资源等信息缩小范围，最终找到‘元凶’。”

• 异常行为检测：

  “你可以设置一些告警规则，比如：”

  • “如果短时间内出现大量 403 错误，可能是有人在尝试暴力破解。”
  • “如果某个用户频繁删除 Pod，可能是误操作或者恶意行为。”
  • “如果某个 Service Account 突然访问了它不该访问的资源，可能是权限配置错误或者被盗用。”

  “当触发这些规则时，及时收到告警，就能第一时间发现并处理问题。”

• 合规性审计：

  “很多行业都有合规性要求，比如金融、医疗等。审计日志可以提供完整的操作记录，证明你的集群操作是符合相关法规和标准的。”

  “你可以根据合规性要求定制审计策略，只记录必要的信息，避免产生过多的日志。”

• 操作审计与回溯
  "当出现误操作或者需要复盘线上问题时, 可以通过审计日志来查看当时的操作, 以便快速定位与解决问题. 例如, 某个开发人员误删除了一个重要的Deployment, 可以通过审计日志查看删除操作发生的时间、操作者、以及删除的Deployment的详细信息, 从而快速恢复."

6. 最佳实践

“最后，分享几个使用审计日志的最佳实践，帮你更好地利用这个工具。”

• 制定合理的审计策略： 不要记录所有信息，这会产生大量的日志，影响性能。根据实际需求，只记录必要的信息。
• 定期审查审计策略： 随着业务的变化，审计策略也需要调整。定期审查策略，确保它仍然符合当前的需求。
• 选择合适的审计后端： 根据集群规模、网络环境、预算等因素，选择合适的后端。如果集群规模不大，Log 后端就够用了；如果集群规模较大，或者对日志的实时性要求较高，可以考虑 Webhook 后端。
• 集中存储和分析审计日志： 不要把日志分散在各个节点上，这不利于查询和分析。使用日志收集工具或者 Webhook 后端，把日志收集到统一的平台。
• 设置合理的日志保留策略： 审计日志会占用存储空间，所以要设置合理的保留策略，定期清理旧的日志。
• 保护审计日志的安全： 审计日志包含了敏感信息，要防止未经授权的访问。可以对日志进行加密，或者限制访问权限。
• 利用审计日志进行告警： 设置告警规则，当日志中出现异常情况时，及时收到通知。
• 与SIEM系统集成： "如果公司有SIEM（Security Information and Event Management）系统，可以将Kubernetes审计日志集成到SIEM系统中，进行统一的安全监控和分析。"

“好了，关于 Kubernetes 审计日志就聊到这里。希望这篇文章能帮你更好地理解和使用这个强大的工具。记住，安全无小事，审计日志用得好，集群安全没烦恼！”

“如果你还有其他问题，或者想了解更多关于 Kubernetes 的知识，欢迎留言交流，咱们一起学习，共同进步！”