一.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
评论区