一、分析容器系统调用：Sysdig
Sysdig：定位是系统监控、分析和排障的工具，在 linux 平台上，已有很多这方面的工具 如tcpdump、htop、iftop、lsof、netstat，它们都能用来分析 linux 系统的运行情况，而且还有很多 日志、监控工具。为什么还需要 sysdig 呢？ sysdig 的优点可以归纳为三个词语：整合、强大、灵 活。
Sysdig 除了能获取系统资源利用率、进程、网络连接、系统调用等信息， 还具备了很强的分析能力，例如：
- 按照CPU使用率对进程排序
- 按照数据包对进程排序
- 打开最多的文件描述符进程
- 查看进程打开了哪些文件
- 查看进程的HTTP请求报文
- 查看机器上容器列表及资源使用情况
Sysdig 官网：www.sysdig.org
工作方式：因为linux大部分程序都是依靠系统调用完成工作，而sysdig 通过在内核的驱动模块注册系统调用的 hook，当有系 统调用发生和完成的时候，它会把系统调用信息拦截到并拷贝到特定的 buffer缓存中(scap)，然后在用户态组件对数据信息处理（sinsp：解压、解析、过滤等）， 并最终通过 sysdig 命令行和用户进行交互。
补充：/proc文件系统是一种虚拟文件系统,以文件系统目录和文件形式,提供一个指向内核数据结构的接口，通过它能够查看和改变各种系统属性，该目录下保存的不是真正的文件和目录，而是一些“运行时”信息，如系统内存、磁盘io、设备挂载信息和硬件配置信息等。proc目录是一个控制中心，用户可以通过更改其中某些文件来改变内核的运行状态。proc目录也是内核提供给我们的查询中心，我们可以通过这些文件查看有关系统硬件及当前正在运行进程的信息。在Linux系统中，许多工具的数据来源正是proc目录中的内容。例如，lsmod命令就是cat /proc/modules命令的别名，lspci命令是cat /proc/pci命令的别名。
1、安装Sysdig
# 载入draios仓库的公共密钥
rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public
# 下载draios仓库的repo源
curl -s -o /etc/yum.repos.d/draios.repo https://s3.amazonaws.com/download.draios.com/stable/rpm/draios.repo
# 安装epel
yum install epel-release -y
# 安装sysdig
yum install sysdig -y
# 加载sysdig驱动模块
到内核中
scap-driver-loader
--------------------------------------------------------------------------------
# 验证1：
[root@k8s-node2-1-73 ~]# lsmod | grep scap
scap 838126 0
# 验证2：
[root@k8s-node2-1-73 ~]# sysdig //执行sysdig命令进行用户交互
212000 21:32:40.504082041 1 sysdig (27469.27469) > switch next=0 pgft_maj=0 pgft_min=7668 vm_size=142768 vm_rss=16020 vm_swap=0
212001 21:32:40.504114873 0 sshd (22556.22556) > clock_gettime
...
## 当系统启动起来时将会有自带的进程已在运行中，输出的打印内容即捕获正在运行进程的系统调用信息
2、打印格式说明
示例：执行sysdig命令，实时输出大量系统调用。捕获系统调用
# 执行sysdig
211997 21:32:40.503961918 0 sshd (22556.22556) > write fd=3(<4t>192.168.1.1:5758->192.168.1.73:22) size=4160
211998 21:32:40.504066607 1 <NA> (<NA>.0) > switch next=27469(sysdig) pgft_maj=0 pgft_min=0 vm_size=0 vm_rss=0 vm_swap=0
211999 21:32:40.504078645 0 sshd (22556.22556) < write res=4160 data=C.....!.....~...yj...*.<.$.:....."...3.8.........rI.....-.B.B..p.....Y.E.......5
212000 21:32:40.504082041 1 sysdig (27469.27469) > switch next=0 pgft_maj=0 pgft_min=7668 vm_size=142768 vm_rss=16020 vm_swap=0
格式：%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： 事件的参数。如果是系统调用，这些对应着系统调用的参数
3、常用参数
- -l, --list：列出可用于过滤和输出的字段
- -M ：多少秒后停止收集
- -p , --print= ：指定打印事件时使用的格式，
- 例如自定义格式输出：sysdig -p "user:%user.name time:%evt.time proc_name:%proc.name"
- 使用 -pc 或-pcontainer 容器友好的格式
- 使用 -pk 或-pkubernetes k8s友好的格式
- -c ：指定内置工具，可直接完成具体的数据聚合、分析工作
- -w ：保存到文件中
- -r ：从文件中读取
— 示例：
1）列出可用于过滤和输出的字段
[root@k8s-node2-1-73 ~]# sysdig -l
2）设置1秒后停止收集
[root@k8s-node2-1-73 ~]# sysdig -M 1
3）指定打印事件时使用的格式
[root@k8s-node2-1-73 ~]# sysdig -p "%evt.num,%proc.name"
4）指定内置工具
[root@k8s-node2-1-73 ~]# sysdig -c ps
4、查看完整过滤器列表 sysdig -l
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
— 示例：
1）根据进程信息，查看一个进程名称的系统调用
sysdig proc.name=kubelet //查看进程名称是kubelet的系统调用2）根据进程信息，查看一个进程Pid的系统调用
sysdig proc.pid=931 //查看pid是931的系统调用3）根据事件信息，查看建立TCP连接的事件
sysdig evt.type=accept //查看事件类型是accept的系统调用
4）根据文件描述符，查看/etc目录下打开的文件描述符（contains为包含）
sysdig fd.name contains /etc
补充：本地硬盘将文件删除，但是磁盘空间没有释放，原因就是文件描述符没有被释放（在Linux中，文件都是通过文件描述符的形式进行去打开或关闭）
5）根据容器信息，查看指定容器名称的系统调用
sysdig -M 10 container.name=web
6）根据容器信息，查看指定k8s集群pod名称的系统调用
[root@k8s-master-1-71 ~]# kubectl get pods
[root@k8s-master-1-71 ~]# kubectl exec -it web1-77b4df5876-nwlp5 bash
root@web1-77b4df5876-nwlp5:/# ls //随意执行一个命令测试，查看node2的输出结果
# 测试
[root@k8s-node2-1-73 ~]# sysdig -l | grep k8s
...
k8s.pod.name Kubernetes pod name.
[root@k8s-node2-1-73 ~]# sysdig k8s.pod.name=web1-77b4df5876-nwlp5
7）根据容器信息，查看指定k8s集群deployment名称的系统调用
sysdig k8s.deployment.name=web假设k8s集群被黑客入侵，通过系统调用去排查的思路：
① 原则一个容器一个服务，如果除该服务以外的不可信任程序，可能是植入的病毒文件。
② 根据如nginx系统调用流程，如果有其它文件创建等，也可能是植入的病毒文件。
③ 通过系统调用查看是否有异常的进程。
5、Chisels：实用的工具箱
一组预定义的功能集合，用来分析特定的场景
命令：sysdig –cl // 列出所有Chisels，以下是一些常用的：
- topprocs_cpu：输出按照 CPU 使用率排序的进程列表，例如sysdig -c
- topprocs_net：输出进程使用网络TOP
- topprocs_file：进程读写磁盘文件TOP
- topfiles_bytes：读写磁盘文件TOP
- netstat：列出网络的连接情况
- ps
- lsof
网络 |
# 查看使用网络的进程TOP sysdig -c topprocs_net |
# 查看建立连接的端口 sysdig -c fdcount_by fd.sport "evt.type=accept" -M 10 |
|
# 查看建立连接的端口 sysdig -c fdbytes_by fd.sport |
|
# 查看建立连接的IP sysdig -c fdcount_by fd.cip "evt.type=accept" -M 10 |
|
# 查看建立连接的IP sysdig -c fdbytes_by fd.cip |
|
磁盘 |
# 查看进程磁盘I/O读写 sysdig -c topprocs_file |
# 查看进程打开的文件描述符数量 sysdig -c fdcount_by proc.name "fd.type=file" -M 10 |
|
# 查看读写磁盘文件 sysdig -c topfiles_bytes sysdig -c topfiles_bytes proc.name=etcd |
|
# 查看/tmp目录读写磁盘活动文件 sysdig -c fdbytes_by fd.filename "fd.directory=/tmp/" |
|
CPU |
# 查看CPU使用率TOP sysdig -c topprocs_cpu |
# 查看容器CPU使用率TOP sysdig -pc -c topprocs_cpu container.name=web sysdig -pc -c topprocs_cpu container.id=web |
|
容器 |
# 查看机器上容器列表及资源使用情况 csysdig -v containers |
# 查看容器资源使用TOP sysdig -c topcontainers_cpu/topcontainers_net/topcontainers_file |
—示例：
1）列出所有Chisels
sysdig -cl
2）查看CPU使用率TOP
sysdig -c topprocs_cpu
3）输出进程使用网络TOP
sysdig -c topprocs_net
4）进程读写磁盘文件TOP
sysdig -c topprocs_file
5）读写磁盘文件TOP
sysdig -c topfiles_bytes
6）指定内置工具
sysdig -c netstat
sysdig -c ps
sysdig -c lsof
7）列出正在运行的容器
sysdig -c lscontainers
8）查看机器上容器列表及资源使用情况
csysdig -v containers
二、监控容器运行时：Falco
1、什么是 Falco
Falco 是一个云原生运行时安全工具，可与容器和原始 Linux 主机一起使用。它由 Sysdig 开发， 是 Cloud Native Computing Foundation（云原生计算基金会）的一个沙箱项目。Falco 的工作方式 是查看文件更改、网络活动、进程表和其他数据是否存在可疑行为，然后通过可插拔后端发送警报。通过内核模块或扩展的 BPF 探测器在主机的系统调用级别检查事件。
旨在检测应用程序中的异常活动，可用于监控 Kubernetes 应用程序和内部组件的运行时安全性。仅需为 Falco 撰写一套规则，即可持续监测并监控容器、应用、主机及网络的异常活动。
Falco 可对任何涉及 Linux 系统调用的行为进行检测和报警。Falco 的警报可以通过使用特定的系统调用、参数以及调用进程的属性来触发。例如，Falco 可以轻松检测到包括但不限于以下事件：
- Kubernetes 中的容器或 pod 内正在运行一个 shell 。
- 容器以特权模式运行，或从主机挂载敏感路径，如 /proc。
- 一个服务器进程正在生成一个意外类型的子进程。
- 读写一个敏感文件，如 /etc/shadow。
- /dev目录下创建了一个非设备文件。
- ls之类的常规系统工具向外进行了对外网络通信
- 在 Kubernetes 集群中启动一个有特权的 Pod。
此外，其还可以检测云环境下的特有行为。例如：
- 创建了带有特权容器、挂载敏感路径或使用了宿主机网络的Pod
- 向用户授予大范围权限（例如cluster-admin）
- 创建了带有敏感信息的configmap
Falco 规则定义 Falco 应监视的行为及事件；可以在 Falco 规则文件或通用配置文件撰写规则。有关编写、管理和部署规则的更多信息。
Falco与传统的主机安全监控工具有什么不同呢？
- Falco主要依托于底层Sysdig内核模块提供的系统调用事件流，与用户状态工具通过预定采集时间或轮询方式实现的离散式监控不同，它提供的是一种连续式实时监控功能；
- 与工作在内核层进行系统调使用捕获、过滤和监控的工具相比，Falco自动运行在用户空间，仅只借内核模块来获得数据，Falco的规则改变更多和程序停止要更多为精神活；
- 与其他任何工作在内核层又提供用户空间接口的工具相比，Falco具有非常易学的规则语言法（可以与SELinux的规则语言法对比）和对云环境的支持。
— 程序架构：
总体来说，Falco是一个基于规则的进程异常进行检测工具，它的目标前支持的事件源有两种：
- Sysdig内核模块
- Kubernetes 审计日志
其中，Sysdig内核模块提供的是整个主机上的实时系统调试事件信息，是Falco依赖的内核事件源。另外，Falco支持五种输出报警的方式：
- 输出到标准输出
- 输出到文件
- 输出到系统日志（syslog）
- 输出到HTTP服务
- 输出到其他程序（指令行管方式）
值得一提的是，最后两种方式使我们能够很容易将 Falco 与其他组件或框架组合起来。下图展示了它的基础架构：
其中，紫色模块为Falco目前支持的输入事件源，绿色模块为目前支持的输出方式，蓝色模块即Falco用户态程序。
— 工作原理：
Falco采用类似于iptables的规则匹配方式来检测异常。它自带了一份规则文件/etc/falco/falco_rules.yaml 供使用，我们也可以将自己定义的规则放在/etc/falco/falco_rules.local.yaml文件中。
它的异常检测流程是直观的。以系统调用为例：Sysdig内核模块首先加载，用户态的Falco运行后读取并解析本地配置文件和规则文件、初始化规则引擎；一旦有进程做了系统调用，内核模块将捕获到这次调用，并把详细信息传给Falco，Falco对这些信息作规则匹配，如果满足规则就通过约定好的方式输出告警。上述工作流程可以表示如下：
2、安装falco
# 载入falco仓库的公共密钥
rpm --import https://falco.org/repo/falcosecurity-3672BA8F.asc
# 下载falco仓库的repo源
curl -s -o /etc/yum.repos.d/falcosecurity.repo https://falco.org/repo/falcosecurity-rpm.repo
# 安装epel
yum install epel-release -y
yum update
# 安装falco
yum install falco -y
# 加载驱动模块
到内核中
falco-driver-loader
# 将falco-custom.service拷贝为falco.service
cd /usr/lib/systemd/system/
cp falco-custom.service falco.service
# 使用systemctl启动服务
systemctl start falco
systemctl enable falco
--------------------------------------------------------------------------------
# 验证：
[root@k8s-node2-1-73 ~]# ps -ef | grep falco //查看运行进程
root 103892 1 12 00:29 ? 00:00:00 /usr/bin/falco --pidfile=/var/run/falco.pid
root 103893 1 0 00:29 ? 00:00:00 /usr/bin/falcoctl artifact follow --allowed-types=rulesfile
[root@k8s-node2-1-73 ~]# cd /etc/falco ; ls //查看目录
aws_cloudtrail_rules.yaml falco_rules.yaml k8s_audit_rules.yaml
falco_rules.local.yaml falco.yaml rules.dfalco配置文件目录：/etc/falco
- falco.yaml falco配置与输出告警通知方式
- falco_rules.yaml 规则文件，默认已经定义很多威胁场景
- falco_rules.local.yaml 自定义扩展规则文件
- k8s_audit_rules.yaml K8s审计日志规则
3、默认规则（falco_rules.yaml ），威胁场景测试：
验证方式：tail -f /var/log/messages（告警通知默认输出到标准输出和系统日志）
测试1：监控系统的二进制文件目录读写（默认规则），如：/usr/bin、/usr/sbin
[root@k8s-node2-1-73 ~]# touch /usr/bin/123 //在/usr/bin目录下创建文件
# 验证：
[root@k8s-node2-1-73 ~]# tail -f /var/log/messages
...
Jun 16 00:31:54 k8s-node2 falco: 00:31:54.893066614: Error File below a known binary directory opened for writing (user=root user_loginuid=0 command=touch /usr/bin/123 pid=108162 file=/usr/bin/123 parent=bash pcmdline=bash gparent=sshd container_id=host image=<NA>)
# 根据描述日志文件中的描述名称，即可在falco规则文件中找到相应的规则，例如：3721
File below a known binary directory opened for writing
测试2：监控根目录或者/root目录写入文件（默认规则）
[root@k8s-node2-1-73 ~]# touch 123
# 验证：
[root@k8s-node2-1-73 ~]# tail -f /var/log/messages
...
Jun 16 00:35:16 k8s-node2 falco: 00:35:16.644494858: Error File below / or /root opened for writing (user=root user_loginuid=0 command=touch 123 pid=115542 parent=bash file=/root/123 program=touch container_id=host image=<NA>)
# 根据描述日志文件中的描述名称，即可在falco规则文件中找到相应的规则，例如：File below / or /root opened for writing
测试3：监控运行交互式Shell的容器（默认规则）
[root@k8s-node2-1-73 ~]# kubectl exec -it web1-77b4df5876-nwlp5 bash
root@web1-77b4df5876-nwlp5:/#
# 验证：
[root@k8s-node2-1-73 ~]# tail -f /var/log/messages
...
Jun 16 00:44:10 k8s-node2 falco: 00:44:10.842464875: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s_nginx_web1-77b4df5876-nwlp5_default_19f4a733-1f92-4b15-b341-18cd353271f0_5 (id=aca4124b24e2) shell=bash parent=runc cmdline=bash pid=4387 terminal=34816 container_id=aca4124b24e2 image=nginx)
# 根据描述日志文件中的描述名称，即可在falco规则文件中找到相应的规则，例如：A shell was spawned in a container with an attached terminal
监控容器创建的不可信任进程（自定义规则）
4、自定义告警规则（falco_rules.local.yaml），修改即生效：
- 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.pname
cmdline=%proc.cmdline)"
priority: ERROR
tags: [users, container]参数说明：
- rule：规则名称，唯一
- desc：规则的描述（在/var/log/messages日志中显示的描述名称）
- condition： 条件表达式
- output：符合条件事件的输出格式
- priority：告警的优先级（INFO、NOTICE、WARN、ERROR）
- tags：本条规则的 tags 分类
示例：监控容器创建的不可信任进程规则，在falco_rules.local.yaml文件添加：
注：在云原生的原则里，容器一旦创建完成之后就不要在容器发生任何变化。
[root@k8s-node2-1-73 ~]# vi /etc/falco/falco_rules.local.yaml
# Your custom rules!
- rule: Unauthorized process on nginx containers
condition: spawned_process and container and container.image startswith nginx and not proc.name in (nginx)
desc: test
output: "Unauthorized process on nginx containers (user=%user.name container_name=%container.name
container_id=%container.id image=%container.image.repository shell=%proc.name parent=%proc.pname
cmdline=%proc.cmdline terminal=%proc.tty)"
priority: WARNINGcondition表达式解读：
- spawned_process // 运行了新进程（可能是宿主机也可能是容器）
- container // 容器
- container.image startswith nginx // 以nginx开头的容器镜像
- not proc.name in (nginx) // 不属于nginx的进程名称（允许进程名称列表）解释： 当以nginx开头的容器镜像运行了不属于nginx进程的新进程
补充：and 当条件都满足的情况下，才会执行当前事件。
output符合条件事件的输出格式（自定义）：%引用变量
user=%user.name
container_name=%container.name
container_id=%container.id
image=%container.image.repository
shell=%proc.name
parent=%proc.pname
cmdline=%proc.cmdline
terminal=%proc.tty
验证：
[root@k8s-node2-1-73 ~]# kubectl run nginx-pod --image=nginx
[root@k8s-node2-1-73 ~]# kubectl exec -it nginx-pod -- bash
root@nginx-pod:/# ls
# 测试：
[root@k8s-node2-1-73 ~]# tail -f /var/log/messages
...
Jun 16 01:19:25 k8s-node2 falco: 01:19:25.697616007: Warning Unauthorized process on nginx containers (user=root container_name=k8s_nginx-pod_nginx-pod_default_8cb3b357-4c60-4156-814d-b551758b5158_0 container_id=49d6300ccadd image=nginx shell=ls parent=bash cmdline=ls terminal=34816)
## 日志输出的内容即自定义扩展规则文件内容
5、Falco支持五种输出告警通知的方式：
- 输出到标准输出（默认启用）
- 输出到指定文件
- 输出到Syslog（默认启用）
- 输出到HTTP服务
- 输出到其他程序（命令行管道方式）
示例：修改告警配置文件（/etc/falco/falco.yaml）关闭默认启用，并开启指定文件输出方式。
[root@k8s-node2-1-73 ~]# vi /etc/falco/falco.yaml
stdout_output:
enabled: false //关闭标准输出（默认为true）
...
syslog_output:
enabled: false //关闭syslog（默认为true）
...
file_output:
enabled: true //开启输出到指定文件（默认为false）
keep_alive: false //改为true，保持文件描述符打开，下次写入事件将不会重复打开，提升性能
filename: /var/log/falco-events.log //指定输出文件验证：
[root@k8s-node2-1-73 ~]# systemctl restart falco
[root@k8s-node2-1-73 ~]# kubectl exec -it nginx-pod -- bash
root@nginx-pod:/# ls
# 测试：
[root@k8s-node2-1-73 ~]# cat /var/log/falco-events.log
01:34:55.959625276: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s_nginx-pod_nginx-pod_default_8cb3b357-4c60-4156-814d-b551758b5158_0 (id=49d6300ccadd) shell=bash parent=runc cmdline=bash pid=117703 terminal=34816 container_id=49d6300ccadd image=nginx)
01:34:58.316083910: Warning Unauthorized process on nginx containers (user=root container_name=k8s_nginx-pod_nginx-pod_default_8cb3b357-4c60-4156-814d-b551758b5158_0 container_id=49d6300ccadd image=nginx shell=ls parent=bash cmdline=ls terminal=34816)
6、Falco告警集中化展示：
FalcoSideKick-UI：告警通知集中图形展示系统
- 项目地址 https://github.com/falcosecurity/falcosidekick-ui
FalcoSideKick：一个集中收集并指定输出，支持大量方式输出，例如Influxdb、Elasticsearch等，主要负责收集每个节点输出的http_output，还可以通过告警通道做邮件告警通知
- 项目地址 https://github.com/falcosecurity/falcosidekick
Falco，代表每个节点类似agent
补充：简单流程为 Falco（agent）—> FalcoSideKick中间程序 —> UI界面
UI界面展示：
1）部署Falco UI：
# 启动FalcoSideKick的容器，需要在每个节点启动，端口是2801，并指定UI地址
docker run -d \
-p 2801:2801 \
--name falcosidekick \
-e WEBUI_URL=http://192.168.1.71:2802 \
falcosecurity/falcosidekick
# 启动FalcoSideKick-UI的容器，端口是2802
docker run -d \
-p 2802:2802 \
--name falcosidekick-ui \
falcosecurity/falcosidekick-ui2）修改falco配置文件指定http方式输出：
[root@k8s-node2-1-73 ~]# vi /etc/falco/falco.yaml
...
# [Stable] `json_output`
# When enabled, Falco will output alert messages and rules file（启用后，Falco将输出警报消息和规则文件）
# loading/validation results in JSON format, making it easier for downstream（以JSON格式加载/验证结果，使下游更容易
）
# programs to process and consume the data. By default, this option is disabled.（处理和使用数据的程序。默认情况下，该选项是禁用的）
json_output: true // 开启以json方式输出
...
# [Stable] `json_include_output_property`
# When using JSON output in Falco, you have the option to include the "output"（当在Falco中使用JSON输出时，你可以选择包含“output”）
# property itself in the generated JSON output. The "output" property provides（属性本身在生成的JSON输出。"output"属性提供）
# additional information about the purpose of the rule. To reduce the logging（关于规则目的的附加信息。为了减少记录）
# volume, it is recommended to turn it off if it's not necessary for your use（如果您的用例不需要，建议将其关闭）
# case.
json_include_output_property: true
...
# [Stable] `http_output`
# Send logs to an HTTP endpoint or webhook.（将日志发送到HTTP端点或webhook）
http_output:
enabled: true //启用HTTP服务输出
url: "http://192.168.1.73:2801/" //指定falcosidekick URL路径
user_agent: "falcosecurity/falco"
# Tell Falco to not verify the remote server.（告诉Falco不要验证远程服务器）
insecure: false
# Path to the CA certificate that can verify the remote server.（可以验证远程服务器的CA证书的路径）
ca_cert: ""
# Path to a specific file that will be used as the CA certificate store.（将用作CA证书存储的特定文件的路径）
ca_bundle: ""
# Path to a folder that will be used as the CA certificate store. CA certificate need to be （将用作CA证书存储的文件夹的路径。CA证书需要作为单独的PEM文件存储在该目录下。）
# stored as indivitual PEM files in this directory.
ca_path: "/etc/ssl/certs"
--------------------------------------------------------------------------------
# 重启服务
[root@k8s-node2-1-73 ~]# systemctl restart falco
3）UI访问地址：http://192.168.1.73:2802/ui/
三、Kubernetes 审计日志
Kubernetes 审计（Auditing） 功能提供了与安全相关的、按时间顺序排列的记录集， 记录每个 用户使用 Kubernetes API 的应用以及控制面自身引发的活动。 审计功能使得集群管理员能够回答以下问题：
- 发生了什么？
- 什么时候发生的？
- 谁触发的？
- 活动发生在哪个（些）对象上？
- 在哪观察到的？
- 它从哪触发的？
- 活动的后续处理行为是什么？
在Kubernetes集群中，API Server的审计日志记录了哪些用户、哪些服务请求操作集群资源，并且可以编写不同规则， 控制忽略、存储的操作日志。 审计日志采用JSON格式输出，每条日志都包含丰富的元数据，例如请求的URL、HTTP方法、客户端来源等，你可以使 用监控服务来分析API流量，以检测趋势或可能存在的安全隐患。
这些可能服务会访问API Server：
- - 管理节点（controller-manager、scheduler）
- - 工作节点（kubelet、kube-proxy）
- - 集群服务（CoreDNS、Calico、HPA等）
- - kubectl、API、Dashboard
官网：https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
1）事件和阶段：
Kube-apiserver 执行审计。每个执行阶段的每个请求都会生成一个事件（例如当客户端向 API Server发出请求时，该请求将经历一个或多个阶段），然后根据特定策略对 事件进行预处理并写入后端。 每个请求都可以用相关的 “stage” 记录。已知的 stage 有：
- RequestReceived - 此阶段事件将在审计处理器接收到请求后，并且在委托给其余处理器之前 生成。
- ResponseStarted - 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时 间运行的请求生成（例如 watch）。
- ResponseComplete - 当响应消息体完成并且没有更多数据需要传输的时候。
- Panic - 当 panic 发生时生成。
阶段 |
说明 |
RequestReceived |
审核处理程序已收到请求 |
ResponseStarted |
已发送响应标头，但尚未发送响应正文 |
ResponseComplete |
响应正文已完成，不再发送任何字节 |
Panic |
内部服务器出错，请求未完成 |
— ApiServer处理请求流程图：
注意：审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上 下文。此外，内存消耗取决于审计日志记录的配置。
2）Kubernetes审核策略文件包含一系列规则：
审计策略定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时，将按顺序与规则 列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有：
- None - 符合这条规则的日志将不会记录。
- Metadata - 记录请求的 metadata（请求的用户、timestamp、resource、verb 等 ），但不记录请求或者响应的消息体。
- Request - 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用 于非资源类型的请求。
- RequestResponse - 记录事件的 metadata、请求和响应的消息体。这不适用于非资源类 型的请求。
可以使用 --audit-policy-file 标志将包含策略的文件传递给 kube-apiserver。如果不设置该 标志，则不记录事件。
注意：rules 字段必须在审计策略文件中提供。
规则级别如下表所示：
审计级别 |
说明 |
None |
不为事件创建日志条目 |
Metadata |
创建日志条目。包括元数据，但不包括请求正文或响应正文 |
Request |
创建日志条目。包括元数据和请求正文，但不包括响应正文 |
RequestResponse |
创建日志条目。包括元数据、请求正文和响应正文 |
补充：当kubectl去访问API server
解释：
- 例如 kubectl get pods => 对于HTTP即GET请求（list），是相应Pod所有的信息
- 例如 kubectl run pod => 对于HTTP即POST请求（create），正文(body): http请求时携带的内容，如pod.json，里面是Pod的相关定义的资源信息
1、审计策略文件的示例：
官网资料：审计 | Kubernetes
# 创建审计策略文件目录
[root@k8s-master-1-71 ~]# mkdir /etc/kubernetes/audit/
# vi /etc/kubernetes/audit/audit-policy.yaml
apiVersion: audit.k8s.io/v1 # 这是必填项。
kind: Policy
# 不要在 RequestReceived 阶段为任何请求生成审计事件。（omit省略 Stages阶段）
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"] # system:kube-proxy用户请求不记录
verbs: ["watch"] # watch请求不记录
resources:
- group: "" # core API 组
resources: ["endpoints", "services"] # "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"你可以使用最低限度的审计策略文件在 Metadata 级别记录所有请求：
# 在 Metadata 级别为所有请求生成日志
apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:
- level: Metadata2、日志格式示例：
审计日志支持写入本地文件和Webhook（发送到外部HTTP API）两种方式。
示例1：使用官方审计策略
1）使用官方的审计策略文件（官网资料：审计 | Kubernetes）
# vi /etc/kubernetes/audit/audit-policy.yaml //参考上方 2）启用审计日志功能：
# vi /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 # 单个审计日志最大大小，单位MB
...
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
注：需要使用hostpath数据卷，将宿主 机策略文件和日志文件挂载到容器中
验证：
# 查看apiserver容器是否成功拉起
docker ps -a | grep apiserver
kubectl get pods
# 查看宿主机本地的审计日志
tail -f /var/log/k8s_audit.log
# 安装jq工具（可以解析json方式标准输出）
yum install epel-release
yum install jq## 安装jq命令参考：https://www.voidking.com/dev-jq-command/
# 打开审计日志 /var/log/k8s_audit.log，通过JSON结构进行解析
echo '{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"9c141a7d-4a72-4095-80fa-1e9a11862a79","stage":"ResponseComplete","requestURI":"/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager?timeout=5s","verb":"get","user":{"username":"system:kube-controller-manager","groups":["system:authenticated"]},"sourceIPs":["192.168.1.71"],"userAgent":"kube-controller-manager/v1.26.3 (linux/amd64) kubernetes/9e64410/leader-election","objectRef":{"resource":"leases","namespace":"kube-system","name":"kube-controller-manager","apiGroup":"coordination.k8s.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-06-19T16:27:35.558086Z","stageTimestamp":"2023-06-19T16:27:35.559450Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:kube-controller-manager\" of ClusterRole \"system:kube-controller-manager\" to User \"system:kube-controller-manager\""}}' | jq
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "Metadata",
"auditID": "9c141a7d-4a72-4095-80fa-1e9a11862a79",
"stage": "ResponseComplete",
"requestURI": "/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager?timeout=5s",
"verb": "get",
"user": {
"username": "system:kube-controller-manager",
"groups": [
"system:authenticated"
]
},
"sourceIPs": [
"192.168.1.71"
],
"userAgent": "kube-controller-manager/v1.26.3 (linux/amd64) kubernetes/9e64410/leader-election",
"objectRef": {
"resource": "leases",
"namespace": "kube-system",
"name": "kube-controller-manager",
"apiGroup": "coordination.k8s.io",
"apiVersion": "v1"
},
"responseStatus": {
"metadata": {},
"code": 200
},
"requestReceivedTimestamp": "2023-06-19T16:27:35.558086Z",
"stageTimestamp": "2023-06-19T16:27:35.559450Z",
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"system:kube-controller-manager\" of ClusterRole \"system:kube-controller-manager\" to User \"system:kube-controller-manager\""
}
}
示例2：自定义只记录指定Pod资源操作日志
# vi /etc/kubernetes/audit/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
# 忽略步骤，不为RequestReceived阶段生成审计日志
omitStages:
- "RequestReceived"
rules:
# 不记录日志（因为其它组件也会根据Pod的创建进行调用）
- level: None
users:
- system:apiserver
- system:kube-controller-manager
- system:kube-scheduler
- system:kube-proxy
- kubelet
# 针对Pod资源记录日志
- level: Metadata
resources:
- group: ""
resources: ["pods"]
# 其他所有的资源操作都不记录日志
- level: None注意：在容器配置文件里进行增加或修改审计日志策略文件，容器是不会重启的，需要强制重启，否则不会生效
# 方式1：（推荐）
ps -ef | grep apiserver
kill -9 <进程ID>
# 方式2：
kubectl delete pod <apiserverpod>验证：创建Pod
kubectl run test-pod --image=nginx
tail -f /var/log/k8s_audit.log
echo '{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"c560a4ae-abbd-424c-a245-972a66ec752d","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/default/pods?fieldManager=kubectl-run","verb":"create","user":{"username":"kubernetes-admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["192.168.1.71"],"userAgent":"kubectl/v1.26.3 (linux/amd64) kubernetes/9e64410","objectRef":{"resource":"pods","namespace":"default","name":"test-pod","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-06-19T16:39:02.986628Z","stageTimestamp":"2023-06-19T16:39:02.997490Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"","imagepolicywebhook.image-policy.k8s.io/failed-open":"true","mutation.webhook.admission.k8s.io/round_0_index_0":"{\"configuration\":\"gatekeeper-mutating-webhook-configuration\",\"webhook\":\"mutation.gatekeeper.sh\",\"mutated\":false}","pod-security.kubernetes.io/enforce-policy":"privileged:latest"}}' | jq
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "Metadata",
"auditID": "c560a4ae-abbd-424c-a245-972a66ec752d",
"stage": "ResponseComplete",
"requestURI": "/api/v1/namespaces/default/pods?fieldManager=kubectl-run",
"verb": "create",
"user": {
"username": "kubernetes-admin",
"groups": [
"system:masters",
"system:authenticated"
]
},
"sourceIPs": [
"192.168.1.71"
],
"userAgent": "kubectl/v1.26.3 (linux/amd64) kubernetes/9e64410",
"objectRef": {
"resource": "pods",
"namespace": "default",
"name": "test-pod",
"apiVersion": "v1"
},
"responseStatus": {
"metadata": {},
"code": 201
},
"requestReceivedTimestamp": "2023-06-19T16:39:02.986628Z",
"stageTimestamp": "2023-06-19T16:39:02.997490Z",
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "",
"imagepolicywebhook.image-policy.k8s.io/failed-open": "true",
"mutation.webhook.admission.k8s.io/round_0_index_0": "{\"configuration\":\"gatekeeper-mutating-webhook-configuration\",\"webhook\":\"mutation.gatekeeper.sh\",\"mutated\":false}",
"pod-security.kubernetes.io/enforce-policy": "privileged:latest"
}
}
示例3：自定义只记录指定Deploy资源操作日志
apiVersion: audit.k8s.io/v1
kind: Policy
# 忽略步骤，不为RequestReceived阶段生成审计日志
omitStages:
- "RequestReceived"
rules:
# 不记录日志（因为其它组件也会根据Pod的创建进行调用）
- level: None
users:
- system:apiserver
- system:kube-controller-manager
- system:kube-scheduler
- system:kube-proxy
- kubelet
# 针对Pod、Deployment资源记录日志
- level: RequestResponse # 包括元数据、请求正文和响应正文
resources:
- group: ""
resources: ["pods"]
- group: "apps" # 增加资源组
resources: ["deployments"] # 增加Deployments
# 其他所有的资源操作都不记录日志
- level: None# 方式1：（推荐）
ps -ef | grep apiserver
kill -9 <进程ID>
# 方式2：
kubectl delete pod <apiserverpod>验证：创建Deployment
kubectl create deploy test --image=nginx
tail -f /var/log/k8s_audit.log
echo '{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"RequestResponse","auditID":"6fee8f69-18b8-4b01-bb1f-3b8c98f604d1","stage":"ResponseComplete","requestURI":"/apis/apps/v1/namespaces/default/deployments?fieldManager=kubectl-create\u0026fieldValidation=Strict","verb":"create","user":{"username":"kubernetes-admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["192.168.1.71"],"userAgent":"kubectl/v1.26.3 (linux/amd64) kubernetes/9e64410","objectRef":{"resource":"deployments","namespace":"default","name":"test","apiGroup":"apps","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestObject":{"kind":"Deployment","apiVersion":"apps/v1","metadata":{"name":"test","creationTimestamp":null,"labels":{"app":"test"}},"spec":{"replicas":1,"selector":{"matchLabels":{"app":"test"}},"template":{"metadata":{"creationTimestamp":null,"labels":{"app":"test"}},"spec":{"containers":[{"name":"nginx","image":"nginx","resources":{},"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"Always"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","securityContext":{},"schedulerName":"default-scheduler"}},"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxUnavailable":"25%","maxSurge":"25%"}},"revisionHistoryLimit":10,"progressDeadlineSeconds":600},"status":{}},"responseObject":{"kind":"Deployment","apiVersion":"apps/v1","metadata":{"name":"test","namespace":"default","uid":"b5754ad2-3082-40c8-9d65-d5c7d6d6d691","resourceVersion":"1218330","generation":1,"creationTimestamp":"2023-06-19T16:47:33Z","labels":{"app":"test"},"managedFields":[{"manager":"kubectl-create","operation":"Update","apiVersion":"apps/v1","time":"2023-06-19T16:47:33Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:labels":{".":{},"f:app":{}}},"f:spec":{"f:progressDeadlineSeconds":{},"f:replicas":{},"f:revisionHistoryLimit":{},"f:selector":{},"f:strategy":{"f:rollingUpdate":{".":{},"f:maxSurge":{},"f:maxUnavailable":{}},"f:type":{}},"f:template":{"f:metadata":{"f:labels":{".":{},"f:app":{}}},"f:spec":{"f:containers":{"k:{\"name\":\"nginx\"}":{".":{},"f:image":{},"f:imagePullPolicy":{},"f:name":{},"f:resources":{},"f:terminationMessagePath":{},"f:terminationMessagePolicy":{}}},"f:dnsPolicy":{},"f:restartPolicy":{},"f:schedulerName":{},"f:securityContext":{},"f:terminationGracePeriodSeconds":{}}}}}}]},"spec":{"replicas":1,"selector":{"matchLabels":{"app":"test"}},"template":{"metadata":{"creationTimestamp":null,"labels":{"app":"test"}},"spec":{"containers":[{"name":"nginx","image":"nginx","resources":{},"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"Always"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","securityContext":{},"schedulerName":"default-scheduler"}},"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxUnavailable":"25%","maxSurge":"25%"}},"revisionHistoryLimit":10,"progressDeadlineSeconds":600},"status":{}},"requestReceivedTimestamp":"2023-06-19T16:47:33.757953Z","stageTimestamp":"2023-06-19T16:47:33.769608Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"","mutation.webhook.admission.k8s.io/round_0_index_0":"{\"configuration\":\"gatekeeper-mutating-webhook-configuration\",\"webhook\":\"mutation.gatekeeper.sh\",\"mutated\":false}"}}' | jq
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "RequestResponse",
"auditID": "6fee8f69-18b8-4b01-bb1f-3b8c98f604d1",
"stage": "ResponseComplete",
"requestURI": "/apis/apps/v1/namespaces/default/deployments?fieldManager=kubectl-create&fieldValidation=Strict",
"verb": "create",
"user": {
"username": "kubernetes-admin",
"groups": [
"system:masters",
"system:authenticated"
]
},
"sourceIPs": [
"192.168.1.71"
],
"userAgent": "kubectl/v1.26.3 (linux/amd64) kubernetes/9e64410",
"objectRef": {
"resource": "deployments",
"namespace": "default",
"name": "test",
"apiGroup": "apps",
"apiVersion": "v1"
},
"responseStatus": {
"metadata": {},
"code": 201
},
"requestObject": {
"kind": "Deployment",
"apiVersion": "apps/v1",
"metadata": {
"name": "test",
"creationTimestamp": null,
"labels": {
"app": "test"
}
},
"spec": {
"replicas": 1,
"selector": {
"matchLabels": {
"app": "test"
}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"app": "test"
}
},
"spec": {
"containers": [
{
"name": "nginx",
"image": "nginx",
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"imagePullPolicy": "Always"
}
],
"restartPolicy": "Always",
"terminationGracePeriodSeconds": 30,
"dnsPolicy": "ClusterFirst",
"securityContext": {},
"schedulerName": "default-scheduler"
}
},
"strategy": {
"type": "RollingUpdate",
"rollingUpdate": {
"maxUnavailable": "25%",
"maxSurge": "25%"
}
},
"revisionHistoryLimit": 10,
"progressDeadlineSeconds": 600
},
"status": {}
},
"responseObject": {
"kind": "Deployment",
"apiVersion": "apps/v1",
"metadata": {
"name": "test",
"namespace": "default",
"uid": "b5754ad2-3082-40c8-9d65-d5c7d6d6d691",
"resourceVersion": "1218330",
"generation": 1,
"creationTimestamp": "2023-06-19T16:47:33Z",
"labels": {
"app": "test"
},
"managedFields": [
{
"manager": "kubectl-create",
"operation": "Update",
"apiVersion": "apps/v1",
"time": "2023-06-19T16:47:33Z",
"fieldsType": "FieldsV1",
"fieldsV1": {
"f:metadata": {
"f:labels": {
".": {},
"f:app": {}
}
},
"f:spec": {
"f:progressDeadlineSeconds": {},
"f:replicas": {},
"f:revisionHistoryLimit": {},
"f:selector": {},
"f:strategy": {
"f:rollingUpdate": {
".": {},
"f:maxSurge": {},
"f:maxUnavailable": {}
},
"f:type": {}
},
"f:template": {
"f:metadata": {
"f:labels": {
".": {},
"f:app": {}
}
},
"f:spec": {
"f:containers": {
"k:{\"name\":\"nginx\"}": {
".": {},
"f:image": {},
"f:imagePullPolicy": {},
"f:name": {},
"f:resources": {},
"f:terminationMessagePath": {},
"f:terminationMessagePolicy": {}
}
},
"f:dnsPolicy": {},
"f:restartPolicy": {},
"f:schedulerName": {},
"f:securityContext": {},
"f:terminationGracePeriodSeconds": {}
}
}
}
}
}
]
},
"spec": {
"replicas": 1,
"selector": {
"matchLabels": {
"app": "test"
}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"app": "test"
}
},
"spec": {
"containers": [
{
"name": "nginx",
"image": "nginx",
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"imagePullPolicy": "Always"
}
],
"restartPolicy": "Always",
"terminationGracePeriodSeconds": 30,
"dnsPolicy": "ClusterFirst",
"securityContext": {},
"schedulerName": "default-scheduler"
}
},
"strategy": {
"type": "RollingUpdate",
"rollingUpdate": {
"maxUnavailable": "25%",
"maxSurge": "25%"
}
},
"revisionHistoryLimit": 10,
"progressDeadlineSeconds": 600
},
"status": {}
},
"requestReceivedTimestamp": "2023-06-19T16:47:33.757953Z",
"stageTimestamp": "2023-06-19T16:47:33.769608Z",
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "",
"mutation.webhook.admission.k8s.io/round_0_index_0": "{\"configuration\":\"gatekeeper-mutating-webhook-configuration\",\"webhook\":\"mutation.gatekeeper.sh\",\"mutated\":false}"
}
}
3、收集审计日志方案：
- 审计日志文件+filebeat
- 审计webhook+logstash
- 审计webhook+falco
小结
本篇为 【Kubernetes CKS认证 DAY6】的开篇学习笔记，希望这篇笔记可以让您初步了解到 分析容器系统调用：Sysdig、监控容器运行时：Falco、Kubernetes 审计日志，不妨跟着我的笔记步伐亲自实践一下吧！
Tip：毕竟两个人的智慧大于一个人的智慧，如果你不理解本章节的内容或需要相关笔记、视频，可私信小安，请不要害羞和回避，可以向他人请教，花点时间直到你真正的理解。