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


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

操作系统审核日志记录与 Cloud Audit LogsKubernetes 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}
    

后续步骤