在 GKE 节点上启用 Linux 审核日志

本页面介绍如何在运行 Container-Optimized OS 的 Google Kubernetes Engine 节点上启用详细的操作系统审核日志。本页面还介绍了如何配置 fluent-bit Logging 代理以将日志发送到 Cloud Logging。 GKE Autopilot 集群不支持启用 Linux auditd 日志记录，因为 Google 会管理节点和底层虚拟机 (VM)。

操作系统审核日志记录与 Cloud Audit Logs 和 Kubernetes Audit Logs 不同。

概览

节点上的操作系统日志提供有关集群和工作负载的状态的重要信息，例如错误消息、登录尝试和二进制文件执行情况。您可以使用这些信息排查问题或调查安全突发事件。

如需从集群中的每个节点收集日志，请使用 DaemonSet，它会在能够调度它的每个集群节点上运行一个 Pod。此 Pod 会配置主机上的 auditd 日志记录守护进程，并配置日志记录代理以将日志发送到 Logging 或其他任何日志提取服务。

根据定义，审核发生在事件之后，并且是一种事后分析安全措施。如果只有 auditd 日志，您可能无法在您的集群上进行调查取证。请考虑如何在整个安全策略中充分利用 auditd 日志记录。

限制

本页面介绍的日志记录机制仅适用于在 GKE Standard 集群中运行 Container-Optimized OS 的节点。

日志记录 DaemonSet 的工作原理

本部分介绍示例日志记录 DaemonSet 的工作原理，以便您对其进行配置以满足您的需求。下一部分会介绍如何部署 DaemonSet。

示例清单定义了 DaemonSet、ConfigMap 以及用于包含它们的 Namespace。

DaemonSet 将 Pod 部署到集群中的每个节点。该 Pod 包含两个容器。第一个容器是 init 容器，它启动 Container-Optimized OS 节点上提供的 cloud-audit-setup systemd 服务。第二个容器 cos-auditd-fluent-bit 包含一个 fluent-bit 实例，该实例配置为从节点日志收集 Linux 审核日志并导出到 Cloud Logging。

示例日志记录 DaemonSet 会记录以下事件：

  • auditd 系统配置修改
  • AppArmor 权限检查
  • execve()、socket()、setsockopt()、mmap() 执行情况
  • 网络连接
  • 用户登录
  • SSH 会话和其他所有 TTY（包括 kubectl exec -t 会话）

配置日志记录 DaemonSet

您可以使用 ConfigMap (cos-auditd-fluent-bit-config) 配置日志记录 DaemonSet。本示例会将审核日志发送到 Logging，但您可以对其进行配置以将日志发送到其他目标位置。

由 auditd 生成的日志量可能非常庞大，并且可能会产生额外的费用，因为它会消耗系统资源并且发送的日志会超过默认日志记录配置。您可以设置过滤条件来管理日志记录量：

部署日志记录 DaemonSet

  1. 您可以使用现有集群，也可以创建新的集群。

  2. 下载示例清单：

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. 修改示例清单以满足您的需求。如需详细了解 DaemonSet 的工作原理，请参阅上一部分。

  4. 初始化通用变量：

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    请替换以下内容：

    • CLUSTER_NAME：您的集群的名称。
    • COMPUTE_REGION：集群的 Compute Engine 区域。对于可用区级集群，请改用可用区。

  5. 部署日志记录 Namespace、DaemonSet 和 ConfigMap：

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. 验证日志记录 Pod 是否已启动。如果您在清单中定义了其他命名空间，请将 cos-auditd 替换为您要使用的命名空间的名称。

    kubectl get pods --namespace=cos-auditd

    如果 Pod 正在运行，则输出结果如下所示：

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    集群中的每个节点上部署了一个 Pod；在本示例中，集群有三个节点。

  7. 您现在可以在 Logging 中访问审核日志了。在日志浏览器中，使用以下查询过滤结果：

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    或者，您也可以使用 gcloud CLI（请使用 --limit，因为结果集可能非常大）：

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

导出日志

如需了解如何将日志路由到支持的目标位置，请参阅配置和管理接收器。

清理

如需停用 auditd 日志记录，请删除日志记录 DaemonSet 并重新启动节点。审核配置一旦启用就会锁定，只能通过重新创建节点进行更改。

  1. 从集群中删除 DaemonSet、ConfigMap 以及它们的 Namespace：

    kubectl delete -f cos-auditd-logging.yaml

  2. 重新启动集群的节点。首先，获取它们所属的实例组：

    instance_group=$(gcloud compute instance-groups managed list \
                    --format="value(name)" \
                    --filter=${CLUSTER_NAME})

    然后，获取实例本身：

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
               --format="csv(instance)[no-heading][terminator=',']")

    最后，重新创建实例：

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
   --instances=${instances}

后续步骤