CKS認證 | Day6 監控、審計和運行時安全 sysdig、falco、審計日志

一、分析容器系統調用：Sysdig

Sysdig：定位是系統監控、分析和排障的工具，在 linux 平臺上，已有很多這方面的工具如tcpdump、htop、iftop、lsof、netstat，它們都能用來分析 linux 系統的運行情況，而且還有很多日志、監控工具。為什么還需要 sysdig 呢？ sysdig 的優點可以歸納為三個詞語：整合、強大、靈活。
Sysdig 除了能獲取系統資源利用率、進程、網絡連接、系統調用等信息，還具備了很強的分析能力，例如：

按照CPU使用率對進程排序
按照數據包對進程排序
打開最多的文件描述符進程
查看進程打開了哪些文件
查看進程的HTTP請求報文
查看機器上容器列表及資源使用情況

Sysdig 官網：www.sysdig.org

項目地址：https://github.com/draios/sysdig

使用文檔：https://github.com/draios/sysdig/wiki

工作方式：因為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

項目地址：https://github.com/falcosecurity/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安全項目簡介與部署

總體來說，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

安裝文檔：https://falco.org/docs/setup/packages/

# 載入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.d

falco配置文件目錄：/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 containerdesc: An event will trigger every time you run sudo in a containercondition: evt.type = execve and evt.dir=< and container.id != host and proc.name = sudooutput: "Sudo run in container (user=%user.name %container.info parent=%proc.pname 
cmdline=%proc.cmdline)"priority: ERRORtags: [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 containerscondition: spawned_process and container and container.image startswith nginx and not proc.name in (nginx)desc: testoutput: "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: WARNING

condition表達式解讀：

- 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-ui

2）修改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: RequestResponseresources:- group: ""# 資源 "pods" 不匹配對任何 Pod 子資源的請求，# 這與 RBAC 策略一致。resources: ["pods"]# 在日志中按 Metadata 級別記錄 "pods/log"、"pods/status" 請求- level: Metadataresources:- group: ""resources: ["pods/log", "pods/status"]# 不要在日志中記錄對名為 "controller-leader" 的 configmap 的請求。- level: Noneresources:- group: ""resources: ["configmaps"]resourceNames: ["controller-leader"]# 不要在日志中記錄由 "system:kube-proxy" 發出的對端點或服務的監測請求。- level: Noneusers: ["system:kube-proxy"]    # system:kube-proxy用戶請求不記錄verbs: ["watch"]   # watch請求不記錄resources:- group: "" # core API 組resources: ["endpoints", "services"]   # "endpoints", "services"資源不記錄# 不要在日志中記錄對某些非資源 URL 路徑的已認證請求。- level: NoneuserGroups: ["system:authenticated"]nonResourceURLs:- "/api*" # 通配符匹配。- "/version"# 在日志中記錄 kube-system 中 configmap 變更的請求消息體。- level: Requestresources:- group: "" # core API 組resources: ["configmaps"]# 這個規則僅適用于 "kube-system" 名字空間中的資源。# 空字符串 "" 可用于選擇非名字空間作用域的資源。namespaces: ["kube-system"]# 在日志中用 Metadata 級別記錄所有其他名字空間中的 configmap 和 secret 變更。- level: Metadataresources:- group: "" # core API 組resources: ["secrets", "configmaps"]# 在日志中以 Request 級別記錄所有其他 core 和 extensions 組中的資源操作。- level: Requestresources:- group: "" # core API 組- group: "extensions" # 不應包括在內的組版本。# 一個抓取所有的規則，將在日志中以 Metadata 級別記錄所有其他請求。- level: Metadata# 符合此規則的 watch 等長時間運行的請求將不會# 在 RequestReceived 階段生成審計事件。omitStages:- "RequestReceived"

你可以使用最低限度的審計策略文件在 Metadata 級別記錄所有請求：

# 在 Metadata 級別為所有請求生成日志
apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:
- level: Metadata

2、日志格式示例：

審計日志支持寫入本地文件和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.yamlname: audit- mountPath: /var/log/k8s_audit.logname: audit-log
...volumes:- name: audithostPath:path: /etc/kubernetes/audit/audit-policy.yamltype: File- name: audit-loghostPath:path: /var/log/k8s_audit.logtype: 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: Noneusers:- system:apiserver- system:kube-controller-manager- system:kube-scheduler- system:kube-proxy- kubelet# 針對Pod資源記錄日志- level: Metadataresources: - 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: Noneusers:- 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}"}
}