一.sysdig(分析容器系统调用)

1.简介

Sysdig：一个非常强大的系统监控、分析和故障排查工具

项目地址：https://github.com/draios/sysdig
文档：https://github.com/draios/sysdig/wiki

2.功能

sysdig 除了能获取系统资源利用率、进程、网络连接、系统调用等信息，
还具备了很强的分析能力，例如：
• 按照CPU使用率对进程排序
• 按照数据包对进程排序
• 打开最多的文件描述符进程
• 查看进程打开了哪些文件
• 查看进程的HTTP请求报文
• 查看机器上容器列表及资源使用情况

3.工作流程

Sysdig在下方的linux内核态注册一个驱动模块，当上方的用户态对内核态进行系统调用时，Sysdig会把系统调用的信息拷贝到特定的buffer缓存区，随后用户态组件再对数据信息处理（解压、解析、过滤等），并最终通过 sysdig 命令行和用户进行交互。

4.安装

curl -s https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public | sudo apt-key add -  
sudo curl -s -o /etc/apt/sources.list.d/draios.list https://s3.amazonaws.com/download.draios.com/stable/deb/draios.list  
apt-get update
apt-get -y install linux-headers-$(uname -r)
apt-get -y install sysdig

5.常用参数

参数	解释
-L， --list	列出可用于过滤和输出的字段。
-M < num_seconds >	多少秒后停止收集。
-p < output_format>， --print=< output_format>， 使用-pc或-pcontainer 容器友好的格式， 使用-pk或-pkubernetes k8s友好的格式	指定打印事件时使用的格式。
-c < chiselname > < chiselargs >	指定内置工具，可直接完成具体的数据聚合、分析工作。
-w < filename >	保存到文件中，特定格式，要用sysdig打开。
-r < filename >	从文件中读取。

6.采集分析

采集数据示例：
    59509 23:59:19.023099531 0 kubelet (1738) < epoll_ctl
采集数据格式：
    %evt.num %evt.outputtime %evt.cpu %proc.name (%thread.tid) %evt.dir %evt.type %evt.info
字段说明：
    evt.num： 递增的事件号。
    evt.time： 事件发生的时间。
    evt.cpu： 事件被捕获时所在的 CPU，也就是系统调用是在哪个 CPU 执行的。
    proc.name： 生成事件的进程名字。
    thread.tid： 线程的 id，如果是单线程的程序，这也是进程的 pid。
    evt.dir： 事件的方向（direction），> 代表进入事件，< 代表退出事件。
    evt.type： 事件的名称，比如 open、stat等，一般是系统调用。
    evt.args： 事件的参数。如果是系统调用，这些对应着系统调用的参数

示例:
10463 10:57:42.329968256 2 sshd (1048.1048) > read fd=12(<f>/dev/ptmx) size=11699
第一列（10463）:事件编号，从1开始记录。
第二列（10:57:42.329968256）:时间。
第三列（2）:进程当前工作所在的cpu编号，从0开始。
第四列（sshd）：进程名称。
第五列(1048.1048):括号里是线程id，两个数值相同说明就一个线程。
第六列（ > ）: 进入事件，<代表退出事件。
第七列（read）:事件名称。
第八列:事件信息，fd=12 是指打开的文件描述符是12

7.过滤

sysdig常用过滤目标：
    fd：根据文件描述符过滤，比如 fd 标号（fd.num）、fd 名字（fd.name）
    process：根据进程信息过滤，比如进程 id（proc.id）、进程名（proc.name）
    evt：根据事件信息过滤，比如事件编号、事件名
    user：根据用户信息过滤，比如用户 id、用户名、用户 home 目录
    syslog：根据系统日志过滤，比如日志的严重程度、日志的内容
    container：根据容器信息过滤，比如容器ID、容器名称、容器镜像

支持运算操作符：
    =、!=、>=、>、<、<=、contains、in 、exists、and、or、not

7.1查看kubelet进程调用

sysdig proc.name=kubelet

7.2查看建立tcp连接事件

tcp三次握手时，有个标识是accept
sysdig evt.type=accept

7.3查看/etc/目录下打开的文件描述符

sysdig fd.name contains /etc

7.4查看nginx系统调用

7.4.1访问nginx

curl 10.244.0.6

7.4.2查看系统调用

sysdig container.name=nginx

7.4.3调用流程

调用流程：
    epoll多路复用。
    与该nginx容器建立tcp三次握手，文件描述符为13。
    epoll处理请求文件，recvfrom请求会打开文件描述符13。
    stat获取html文件状态，openat打开html文件，并提取其中内容返回给客户端，客户端直接在网页上渲染出来。
    writev往tcp连接通道发送数据，并相应数据返回200。
    sendfile优化响应文件时的工作的性能，是nginx的特性。
    write fd=6写入日志。
    sersockopt 关闭fd=17，防止频繁打开提高工作效率。
    close 关闭fd=17，一套流程走完。

(1)epoll多路复用

57612 11:24:26.020854846 4 nginx (14193.14193) < epoll_wait res=1

(2)与该nginx容器建立tcp三次握手，文件描述符为17

57619 11:24:26.020902733 4 nginx (14193.14193) < accept4 fd=17(<4t>10.244.0.1:4031->10.244.0.6:80) tuple=10.244.0.1:4031->10.244.0.6:80 queuepct=0 queuelen=0 queuemax=511

(3)epoll处理请求文件，recvfrom请求会打开文件描述符17

57621 11:24:26.020916000 4 nginx (14193.14193) > epoll_ctl
57622 11:24:26.020921954 4 nginx (14193.14193) < epoll_ctl
57624 11:24:26.020925247 4 nginx (14193.14193) > epoll_wait maxevents=512
57626 11:24:26.020927304 4 nginx (14193.14193) < epoll_wait res=1
57629 11:24:26.020931367 4 nginx (14193.14193) > recvfrom fd=17(<4t>10.244.0.1:4031->10.244.0.6:80) size=1024
57631 11:24:26.020936581 4 nginx (14193.14193) < recvfrom res=77 data=GET / HTTP/1.1..Host: 10.106.246.67..User-Agent: curl/7.81.0..Accept: */*.... tuple=NULL

(4)stat获取html文件状态，openat打开html文件，并提取其中内容返回给客户端，客户端直接在网页上渲染出来。

57633 11:24:26.020964838 4 nginx (14193.14193) > stat
57634 11:24:26.020980848 4 nginx (14193.14193) < stat res=0 path=/usr/share/nginx/html/index.html
57635 11:24:26.020987274 4 nginx (14193.14193) > openat dirfd=-100(AT_FDCWD) name=/usr/share/nginx/html/index.html flags=65(O_NONBLOCK|O_RDONLY) mode=0
57636 11:24:26.020997289 4 nginx (14193.14193) < openat fd=18(<f>/usr/share/nginx/html/index.html) dirfd=-100(AT_FDCWD) name=/usr/share/nginx/html/index.html flags=65(O_NONBLOCK|O_RDONLY) mode=0 dev=D4 ino=1848930

(5)writev往tcp连接通道发送数据，并相应数据返回200。

57655 11:24:26.021148822 4 nginx (14193.14193) < write res=91 data=10.244.0.1 - - [07/Dec/2023:03:24:26 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7

(6) sendfile优化响应文件时的工作的性能，是nginx的特性。

57641 11:24:26.021091786 4 nginx (14193.14193) > sendfile out_fd=17(<4t>10.244.0.1:4031->10.244.0.6:80) in_fd=18(<f>/usr/share/nginx/html/index.html) offset=0 size=615

(7)write fd=6写入日志。

57653 11:24:26.021138292 4 nginx (14193.14193) > write fd=6(<p>pipe:[116954]) size=91
57655 11:24:26.021148822 4 nginx (14193.14193) < write res=91 data=10.244.0.1 - - [07/Dec/2023:03:24:26 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7

(8) sersockopt 关闭fd=17，防止频繁打开提高工作效率。

57661 11:24:26.021173267 4 nginx (14193.14193) < setsockopt res=0 fd=17(<4t>10.244.0.1:4031->10.244.0.6:80) level=2(SOL_TCP) optname=0(UNKNOWN) val=.... optlen=4

(9) close 关闭fd=137，一套流程走完。

57906 11:24:26.021498157 4 nginx (14193.14193) > close fd=17(<4t>10.244.0.1:4031->10.244.0.6:80)
57907 11:24:26.021499197 4 nginx (14193.14193) < close res=0

8.Chisels工具

8.1简介

Chisels：实用的工具箱，一组预定义的功能集合，用来分析特定的场景。
sysdig –cl 列出所有Chisels，以下是一些常用的：
• topprocs_cpu：输出按照 CPU 使用率排序的进程列表，例如sysdig -c
• topprocs_net：输出进程使用网络TOP
• topprocs_file：进程读写磁盘文件TOP
• topfiles_bytes：读写磁盘文件TOP
• netstat：列出网络的连接情况
• ps
• lsof

8.2网络类

命令	解释
sysdig -c topprocs_net	查看使用网络的进程TOP
sysdig -c fdcount_by fd.sport “evt.type=accept” -M 10	查看建立连接的端口
sysdig -c fdbytes_by fd.sport	查看建立连接的端口
sysdig -c fdcount_by fd.cip “evt.type=accept” -M 10	查看建立连接的IP
sysdig -c fdbytes_by fd.cip	查看建立连接的IP

8.3硬盘类

命令	解释
sysdig -c topprocs_file	查看进程磁盘I/O读写
sysdig -c fdcount_by proc.name “fd.type=file” -M 10	查看进程打开的文件描述符数量
sysdig -c topfiles_bytes sysdig -c topfiles_bytes proc.name=etcd	查看读写磁盘文件
sysdig -c fdbytes_by fd.filename “fd.directory=/tmp/”	查看/tmp目录读写磁盘活动文件

8.4cpu类

命令	解释
sysdig -c topprocs_cpu	查看CPU使用率TOP
sysdig -pc -c topprocs_cpu container.name=nginx sysdig -pc -c topprocs_cpu container.id=nginx	查看容器CPU使用率TOP

8.5容器类

命令	解释
csysdig –vcontainers	查看机器上容器列表及资源使用情况
sysdig -c topcontainers_cpu/topcontainers_net/topcontainers_file	查看容器资源使用TOP

8.6示例

8.6.1查看当前系统cpu使用占比最高的进程

root@master01:~# sysdig -c topprocs_cpu
CPU%                Process             PID
--------------------------------------------------------------------------------
8.00%               kube-apiserver      1086
6.00%               etcd                1109
2.00%               kube-controller     14615

8.6.3查看当前系统进程磁盘I/O读写

root@master01:~# sysdig -c topprocs_file
Bytes               Process             PID
--------------------------------------------------------------------------------
41.39KB             etcd                1109
3.28KB              kubelet             660
1.73KB              containerd          669

二.falco(监控容器运行时)

1.简介

Falco 是一个 Linux 安全工具，它使用系统调用来保护和监控系统。
Falco最初是由Sysdig开发的，后来加入CNCF孵化器，成为首个加入CNCF的运行时安全项目。
Falco提供了一组默认规则，可以监控内核态的异常行为，例如：
• 对于系统目录/etc, /usr/bin, /usr/sbin的读写行为
• 文件所有权、访问权限的变更
• 从容器打开shell会话
• 容器生成新进程
• 特权容器启动
项目地址：https://github.com/falcosecurity/falco

2.工作流程

将falco注册成系统模块采集系统调用。
规则引擎根据判断收集的系统调用是否违反了规则，通知给用户处理。
支持k8s发送的审计日志。

3.安装

curl -s https://falco.org/repo/falcosecurity-packages.asc | sudo apt-key add -
echo "deb https://download.falco.org/packages/deb stable main" | \
tee /etc/apt/sources.list.d/falcosecurity.list
apt-get update
apt-get -y install linux-headers-$(uname -r)
apt-get install -y falco
falco-driver-loader
systemctl start falco-custom
systemctl enable falco-custom

安装目录
  falco.yaml：falco配置与输出告警通知方式。
  falco_rules.yaml：规则文件，默认已经定义很多威胁场景。
  falco_rules.local.yaml：自定义扩展规则文件。
  k8s_audit_rules.yaml：K8s审计日志规则

4.规则参数

- rule: The program "sudo" is run in a container
  desc: An event will trigger every time you run sudo in a container
  condition: evt.type = execve and evt.dir=< and container.id != host and proc.name = sudo
  output: "Sudo run in container (user=%user.name %container.info parent=%proc.pnamecmdline=%proc.cmdline)"
  priority: ERROR
  tags: [users, container]

参数说明：
    rule：规则名称，唯一。
    desc：规则的描述。
    condition： 条件表达式。
    output：符合条件事件的输出格式。
    priority：告警的优先级。
    tags：本条规则的 tags 分类

5.默认规则

威胁场景：
    监控系统二进制文件目录读写（默认规则）。
    监控根目录或者/root目录写入文件（默认规则）。
    监控运行交互式Shell的容器（默认规则）。
    监控容器创建的不可信任进程（自定义规则）
验证：
    tail -f /var/log/messages（告警通知默认输出到标准输出和系统日志）

5.1规则1

(1)查看默认规则

root@master01:~# vim /etc/falco/falco_rules.yaml
- rule: Terminal shell in container

(2)验证默认规则，进入容器测试

root@master01:~# kubectl exec -it nginx-6d77c46878-ld8j7 bash

(3)查看日志

root@master01:~# journalctl -b | grep "shell"
Dec 07 14:56:02 master01 falco[5726]: 14:56:02.758506195: Notice A shell was spawned in a container with an attached terminal (evt_type=execve user=root user_uid=0 user_loginuid=-1 process=bash proc_exepath=/bin/bash parent=runc command=bash terminal=34817 exe_flags=EXE_WRITABLE container_id=e687d0a0d6e6 container_name=nginx)

5.2规则2

(1)查看默认规则

root@master01:~# vim /etc/falco/falco_rules.yaml
- macro: private_key_or_password

(2)验证默认规则，查找id_rsa文件

root@master01:~# find / -name id_rsa

(3)查看日志

root@master01:~# journalctl -b | grep "id_rsa"
Dec 07 15:05:01 master01 falco[5726]: 15:05:01.548401894: Warning Grep private keys or passwords activities found (evt_type=execve user=root user_uid=0 user_loginuid=1000 process=find proc_exepath=/usr/bin/find parent=bash command=find / -name id_rsa terminal=34817 exe_flags=EXE_WRITABLE container_id=host container_name=host)

6.自定义规则

6.1编辑自定义规则

#不允许在容器内执行rm命令，如果发现就告警
rule: The program rm is run in a container
  desc: An event will trigger every time you run rm in a container
  condition: evt.type = execve and evt.dir=< and container.id != host and proc.name = rm
  output: "rm run in container (user=%user.name %container.info parent=%proc.pname 
cmdline=%proc.cmdline)"
  priority: ERROR
  tags: [users, container]

6.2验证默认规则，删除文件

root@master01:~# kubectl exec -it nginx-6d77c46878-ld8j7 bash
root@nginx-6d77c46878-ld8j7:/# rm -f docker-entrypoint.sh

6.3查看日志

Dec 07 15:28:21 master01 falco[23535]: 15:28:21.509093370: Error rm run in container (user=root container_id=e687d0a0d6e6 container_name=nginx parent=bash cmdline=rm -f docker-entrypoint.sh)

7.告警输出

7.1输出方式

    五种输出告警通知的方式：
        输出到标准输出（默认启用），stdout_output。
        输出到文件，file_output。
        输出到系统日志（默认启用），sysout_output。
        输出到HTTP服务。
        输出到其他程序（命令行管道方式）

7.2输出为日志文件

(1)修改falso文件，启动文件日志输出

root@master01:~#  vim /etc/falco/falco.yaml
file_output:
  enabled: true
  keep_alive: false
  filename: /var/log/falco_events.log

stdout_output:
  enabled: false
root@master01:~# systemctl  restart falco-custom

(2)容器内执行rm命令

root@master01:~# kubectl exec -it nginx-6d77c46878-ld8j7 bash
root@nginx-6d77c46878-ld8j7:~# rm

(3)查看日志

root@master01:~# cat /var/log/falco_events.log
15:39:32.799791629: Error rm run in container (user=root container_id=e687d0a0d6e6 container_name=nginx parent=bash cmdline=rm)

7.3web展示

7.3.1简介

FalcoSideKick：一个集中收集并指定输出，支持大量方式输出，例如Influxdb、Elasticsearch等
项目地址 https://github.com/falcosecurity/falcosidekick
FalcoSideKick-UI：告警通知集中图形展示系统
项目地址 https://github.com/falcosecurity/falcosidekick-ui

7.3.2流程

每个服务器部署falco收集系统调用。
部署falcosidekick程序，收集每台服务器上的falco的系统调用信息。
通过falcosidekick-ui程序来集中展示在web页面。
告警通道：Slack/Altermanager/SMTP等

7.3.3部署UI

docker run -d \
-p 2802:2802 \
--name falcosidekick-ui \
falcosecurity/falcosidekick-ui

7.3.4部署收集程序

docker run -d \
-p 2801:2801 \
--name falcosidekick \
-e WEBUI_URL=http://192.168.3.135:2802 \
falcosecurity/falcosidekick

7.3.5修改fslco配置文件指定http方式输出

root@master01:~#  vim /etc/falco/falco.yaml
json_output: true
http_output:
  enabled: true
  url: "http://192.168.3.135:2801/"
  user_agent: "falcosecurity/falco"
root@master01:~# systemctl  restart falco-custom

7.3.6测试访问web界面

三.k8s审计日志

1.简介

在Kubernetes集群中，API Server的审计日志记录了哪些用户、哪些服务请求操作集群资源，并且可以编写不同规则，
控制忽略、存储的操作日志。
审计日志采用JSON格式输出，每条日志都包含丰富的元数据，例如请求的URL、HTTP方法、客户端来源等，你可以使
用监控服务来分析API流量，以检测趋势或可能存在的安全隐患。

这些可能服务会访问API Server：
• 管理节点（controller-manager、scheduler）
• 工作节点（kubelet、kube-proxy）
• 集群服务（CoreDNS、Calico、HPA等）
• kubectl、API、Dashboard

2.日志审计方案

审计日志文件+filebeat
审计webhook+falco
审计webhook+logstash

3.事件阶段

当客户端向 API Server发出请求时，该请求将经历一个或多个阶段：
每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略 被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。

阶段	说明
Request Received	审核处理程序已收到请求
Response Started	已发送响应标头，但尚未发送响应正文
Response Complete	响应正文已完成，不再发送任何字节
Panic	内部服务器出错，请求未完成

4.日志输出方式

4.1输出为本地文件存储

需要在apiserver配置文件添加以下参数。
    –audit-policy-file：日志审核策略文件路径。
    –audit-log-path：审计日志文件输出路径。不指定此标志会禁用日志后端，意味着标准化。
    –audit-log-maxage：定义保留旧审计日志文件的最大天数。
    –audit-log-maxbackup：定义要保留的审计日志文件的最大数量。
    –audit-log-maxsize：定义审计日志文件轮转之前的最大大小（兆字节）。

4.2发送给webhook server

需要在kube-apiserver配置文件添加以下参数，并且需要在Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
    –audit-webhook-config-file：设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个 kubeconfig 文件。
    –audit-webhook-initial-backoff：指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
    –audit-webhook-mode：确定采用哪种模式回调通知。
        batch：批量模式，缓存事件并以异步批量方式通知，是默认的工作模式。
        blocking：阻塞模式，事件按顺序逐个处理，这种模式会阻塞API Server的响应，可能导致性能问题。
        blocking-strict：与阻塞模式类似，不同的是当一个Request在RequestReceived阶段发生审计失败时，整个Request请求会被认为失败。

5.审核策略

5.1简介

    K8s审核策略文件包含一系列规则，描述了记录日志的级别，采集哪些日志，不采集哪些日志。
    审核策略合适和rbac授权格式相同，也是写什么组里的什么资源要做什么动作。

5.2日志级别

 请求正文指post请求，比如apply、create动作请求。
 相应正文，比如get动作请求。

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

5.3日志格式

审计日志属性：表明请求哪个API、事件id、请求方法。
用户信息：用哪个身份进来的。
客户端IP：从哪台机器过来请求的。
用户标识对象：想访问哪个资源、资源名称、所在命名空间、所在组。
响应状态：返回状态。
时间注释：响应时间。

5.4启用审计日志

指定参数	解释
audit-policy-file	审计日志策略文件
audit-log-path	审计日志输出文件
audit-log-maxage	审计日志保留的最大天数
audit-log-maxbackup	审计日志最大分片存储多少个日志文件
audit-log-maxsize	单个审计日志最大大小，单位MB

审计日志支持写入本地文件和Webhook（发送到外部HTTP API）两种方式
vim /etc/kubernetes/manifests/kube-apiserver.yaml
    - --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
    - --audit-log-path=/var/log/k8s_audit.log
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100

volumeMounts:
    - mountPath: /etc/kubernetes/audit/audit-policy.yaml
      name: audit
    - mountPath: /var/log/k8s_audit.log
      name: audit-log
volumes:
  - name: audit
    hostPath:
      path: /etc/kubernetes/audit/audit-policy.yaml
      type: File
  - name: audit-log
    hostPath:
      path: /var/log/k8s_audit.log
      type: FileOrCreate

(1)案例1

root@master01:~#mkdir /etc/kubernetes/audit
root@master01:~#cd /etc/kubernetes/audit/
root@master01:~#cat audit-policy.yaml
apiVersion: audit.k8s.io/v1       ##必填项。
kind: Policy
# 不要在 RequestReceived 阶段为任何请求生成审计事件。
omitStages:
  - "RequestReceived"
rules:
  # 在日志中用 RequestResponse 级别记录 Pod 变化。
  - level: RequestResponse
    resources:
    - group: ""
      # 资源 "pods" 不匹配对任何 Pod 子资源的请求，
      # 这与 RBAC 策略一致。
      resources: ["pods"]
  # 在日志中按 Metadata 级别记录 "pods/log"、"pods/status" 请求
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # 不要在日志中记录对名为 "controller-leader" 的 configmap 的请求。
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # 不要在日志中记录由 "system:kube-proxy" 发出的对端点或服务的监测请求。
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API 组
      resources: ["endpoints", "services"]

  # 不要在日志中记录对某些非资源 URL 路径的已认证请求。
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # 通配符匹配。
    - "/version"

  # 在日志中记录 kube-system 中 configmap 变更的请求消息体。
  - level: Request
    resources:
    - group: "" # core API 组
      resources: ["configmaps"]
    # 这个规则仅适用于 "kube-system" 名字空间中的资源。
    # 空字符串 "" 可用于选择非名字空间作用域的资源。
    namespaces: ["kube-system"]

  # 在日志中用 Metadata 级别记录所有其他名字空间中的 configmap 和 secret 变更。
  - level: Metadata
    resources:
    - group: "" # core API 组
      resources: ["secrets", "configmaps"]

  # 在日志中以 Request 级别记录所有其他 core 和 extensions 组中的资源操作。
  - level: Request
    resources:
    - group: "" # core API 组
    - group: "extensions" # 不应包括在内的组版本。

  # 一个抓取所有的规则，将在日志中以 Metadata 级别记录所有其他请求。
  - level: Metadata
    # 符合此规则的 watch 等长时间运行的请求将不会
    # 在 RequestReceived 阶段生成审计事件。
    omitStages:
      - "RequestReceived"

查看日志文件
apt -y install jq
tail -f  /var/log/k8s_audit.log
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"0bae35b3-861d-4b56-a42b-dd5b4ebf1db3","stage":"ResponseComplete","requestURI":"/livez","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["192.168.3.181"],"userAgent":"kube-probe/1.28","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-12-07T09:00:37.722972Z","stageTimestamp":"2023-12-07T09:00:37.725034Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:public-info-viewer\" of ClusterRole \"system:public-info-viewer\" to Group \"system:unauthenticated\""}}

echo '......' |jq