审核政策

本页面介绍 Google Kubernetes Engine (GKE) 的审核日志记录政策。

准备工作

在阅读本主题之前,您应该先熟悉以下主题中的材料:

概览

在 GKE 集群中,Kubernetes API 服务器将审核日志条目写入由 GKE 管理的后端。当 GKE 从 Kubernetes API 服务器接收日志条目时,它会将其写入项目的管理员活动日志和数据访问日志。

有两项政策会影响您在项目审核日志中看到的内容:

  • Kubernetes 审核政策定义将哪些事件应记录为日志条目的规则,还指定了日志条目应包含的数据。

  • GKE 审核政策确定将哪些条目写入管理员活动日志,以及哪些条目写入数据访问日志。

Kubernetes 审核政策

Kubernetes API 服务器遵循 kube-apiserver 命令的 --audit-policy-file 标志中指定的政策。

当 GKE 启动 Kubernetes API 服务器时,它会通过设置 --audit-policy-file 标志的值来提供审核政策文件。在开源 Kubernetes 代码库中,您可以找到生成审核政策文件的 configure-helper.sh 脚本。您可以在脚本中直接查看审核政策文件的大部分内容。

事件和阶段

当某个人或组件向 Kubernetes API 服务器发出请求时,该请求将经历一个或多个阶段

阶段 说明
RequestReceived 审核处理程序已收到请求。
ResponseStarted 已发送响应标头,但尚未发送响应正文。
ResponseComplete 响应正文已完成,不再发送任何字节。
Panic 内部服务器出错,请求未完成。

请求的每个阶段都会生成一个事件,该事件根据政策进行处理。政策指定是否应将事件记录为日志条目,如果需要记录,应将哪些数据包含在日志条目中。

审核级别

Kubernetes 审核政策文件包含一个规则列表。在政策文件中,与事件匹配的第一项规则设置事件的审核级别

规则可以指定以下审核级别之一:

级别 说明
None 不为事件创建日志条目。
Metadata 创建日志条目。包括元数据,但不包括请求正文或响应正文。
Request 创建日志条目。包括元数据和请求正文,但不包括响应正文。
RequestResponse 创建日志条目。包括元数据、请求正文和响应正文。

下面是一个示例规则。如果事件与规则匹配,Kubernetes API 服务器将在 Request 级别创建一个日志条目。

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

如果满足以下所有条件,则事件与规则匹配:

  • 事件与政策文件中前面的任何规则都不匹配。
  • 进行调用的身份属于 system:nodes 用户组。
  • 该调用是 update 请求或 patch 请求。
  • 请求针对 nodes/status 资源或 pods/status 资源。
  • 事件不是针对调用的 RequestReceived 阶段。

GKE 集群的 Kubernetes 审核政策摘要

  • 通常,createupdatedelete 等写入请求会在 RequestResponse 级别记录。

  • 通常,getlistwatch 事件会在 Metadata 级别记录。

  • 有些事件被视为特殊情况。如需查看被视为特殊情况的请求的确切列表,请参阅政策脚本。在撰写本文时,以下这些是特殊情况:

    • kubeletsystem:node-problem-detectorsystem:serviceaccount:kube-system:node-problem-detector 发出的针对 nodes/status 资源或 pods/status 资源的 update 和 patch 请求会在 Request 级别记录。

    • system:nodes 组中的任何身份发出的针对 nodes/status 资源或 pods/status 资源的 update 和 patch 请求会在 Request 级别记录。

    • system:serviceaccount:kube-system:namespace-controller 发出的 deletecollection 请求会在 Request 级别记录。

    • 针对 secrets 资源、configmaps 资源或 tokenreviews 资源的请求会在 Metadata 级别记录。

  • 某些请求是不会被记录的。如需查看系统不会记录的请求的确切列表,请参阅政策脚本中的 level: None 规则。截至撰写本文时为止,以下请求将不会进行记录:

    • system:kube-proxy 发出的监视 endpoints 资源、services 资源或 services/status 资源的请求。

    • system:unsecured 发出的针对 kube-system 命名空间中 configmaps 资源的 get 请求。

    • kubelet 发出的针对 nodes 资源或 nodes/status 资源的 get 请求。

    • system:nodes 组中的任何身份发出的针对 nodes 资源或 nodes/status 资源的 get 请求。

    • system:kube-controller-managersystem:kube-schedulersystem:serviceaccount:endpoint-controller 发出的针对 kube-system 命名空间中 endpoints 资源的 get 和 update 请求。

    • system:apiserver 发出的针对 namespaces 资源、namespaces/status 资源或 namespaces/finalize 资源的 get 请求。

    • system:kube-controller-manager 发出的针对 metrics.k8s.io 组中任何资源的 get 和 list 请求。

    • 对与 /healthz*/version/swagger* 匹配的网址发出的请求。

GKE 审核政策

当 GKE 从 Kubernetes API 服务器接收日志条目时,它会应用自己的政策来确定将哪些条目写入项目的管理员活动日志,将哪些条目写入项目的数据访问日志。

在大多数情况下,GKE 应用以下规则来记录来自 Kubernetes API 服务器的条目:

  • 表示 createdeleteupdate 请求的条目将写入管理员活动日志。

  • 表示 getlistupdateStatus 请求的条目将写入数据访问日志。

如需了解价格以及默认启用的日志类型,请参阅 Logging 详情

了解 Kubernetes 审核政策文件

对于 GKE 集群,Kubernetes 审核政策文件开头的规则将指定不记录哪些事件。例如,此规则指定不应记录 kubelet 发出的针对 nodes 资源或 nodes/status 资源的任何 get 请求。前文中提到过,None 级别意味着不应记录任何匹配事件:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

level: None 规则列表之后,政策文件包含一列针对特殊情况的规则。例如,下面是一个特殊情况规则,指定在 Metadata 级别记录某些请求:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

如果满足以下所有条件,则事件与规则匹配:

  • 事件与政策文件中前面的任何规则都不匹配。
  • 请求针对 secretsconfigmapstokenreviews 类型的资源。
  • 事件不是针对调用的 RequestReceived 阶段。

在特殊情况规则列表之后,政策文件列出一些通用规则。 如需查看脚本中的通用规则,您必须用 known_apis 的值替换 ${known_apis}。替换后,您会得到如下规则:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

该规则适用于与政策文件中前面的任何规则均不匹配且不在 RequestReceived 阶段的事件。该规则指定,针对属于所列群组之一的任何资源发出的 getlistwatch 请求应该在 Request 级别记录。

政策文件中的下一项规则如下所示:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

该规则适用于与政策文件中前面的任何规则均不匹配且不在 RequestReceived 阶段的事件。具体来说,此规则不适用于读取请求:getlistwatch。但此规则适用于写入请求,如 createupdatedelete。该规则指定应该在 RequestResponse 级别记录写入请求。

后续步骤