本页面介绍如何在运行 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
生成的日志量可能非常庞大,并且可能会产生额外的费用,因为它会消耗系统资源并且发送的日志会超过默认日志记录配置。您可以设置过滤条件来管理日志记录量:
- 您可以在
cos-auditd-fluent-bit-config
ConfigMap 中设置过滤条件,以便不记录某些数据。请参阅 Grep、Modify、Record Modifier 和其他过滤条件的 fluent-bit 文档。 - 您还可以配置 Logging 以过滤传入的日志。如需了解详情,请参阅配置和管理接收器。
部署日志记录 DaemonSet
您可以使用现有集群,也可以创建新的集群。
下载示例清单:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml
修改示例清单以满足您的需求。如需详细了解 DaemonSet 的工作原理,请参阅上一部分。
初始化通用变量:
export CLUSTER_NAME=CLUSTER_NAME export CLUSTER_LOCATION=COMPUTE_REGION
请替换以下内容:
CLUSTER_NAME
:您的集群的名称。COMPUTE_REGION
:集群的 Compute Engine 区域。对于可用区级集群,请改用可用区。
部署日志记录 Namespace、DaemonSet 和 ConfigMap:
envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \ | kubectl apply -f -
验证日志记录 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;在本示例中,集群有三个节点。
您现在可以在 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 并重新启动节点。审核配置一旦启用就会锁定,只能通过重新创建节点进行更改。
从集群中删除 DaemonSet、ConfigMap 以及它们的 Namespace:
kubectl delete -f cos-auditd-logging.yaml
重新启动集群的节点。首先,获取它们所属的实例组:
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}
后续步骤
- 观看 Cloud Forentics 101,开始进行云端取证。
- 了解 Kubernetes 审核日志记录和审核政策。
- 阅读 Kubernetes Engine 安全概览。
- 了解 Cloud Audit Logs。