一、集群环境

底层系统为ubuntu18.04，然后在每个node上安装k8s，并构建集群。Master node的IP地址为192.168.26.71/24，两个Worker node的IP地址为192.168.26.72/24、192.168.26.73/24。

二、K8s审计概念

1.什么是K8s审计
我们知道，K8s系统管理员可以创建多个K8s账号，并赋予不同的权限分发给其他需要操作K8s环境的人。那么如果K8s系统管理员想要去查看具体这些K8s用户在K8s中做了哪些操作，则需要使用K8s审计功能（默认情况下K8s并没有启用审计）。

Kubernetes 审计（Auditing） 功能提供了与安全相关的、按时间顺序排列的记录集， 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。

审计记录最初产生于 kube-apiserver 内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定审计策略被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。每个请求都可被记录其相关的 阶段（stage）。

2.审计策略
审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。 审计策略对象结构定义在 audit.k8s.io API 组 处理事件时，将按顺序与规则列表进行比较。

在审计策略中需要注意如下几天点。设置什么时候记：

1. RequestReceived - 审计处理程序收到请求后立即生成的事件阶段，持续到它被委派到处理程序链之前；
2. ResponseStarted - 在响应消息的头部发送后，响应消息体发送前生成的事件。 只有长时间运行的请求（例如 watch）才会生成这个阶段；
3. ResponseComplete - 当响应消息体完成并且没有更多数据需要传输的时候；
4. Panic - 当 panic错误发生时生成。

需要记什么：

1. None - 符合这条规则的日志将不会记录；
2. Metadata - 记录请求的元数据（请求的用户、时间戳、资源、动词等等）， 但是不记录请求或者响应的消息体；
3. Request - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。 这不适用于非资源类型的请求；
4. RequestResponse - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求。

3.审计后端
审计后端实现将审计事件导出到外部存储。Kube-apiserver 默认提供两个后端：

1. Log 后端，将事件写入到文件系统；
2. Webhook 后端，将事件发送到外部 HTTP API。

三、K8s审计实验

1.准备工作
使用一台K8s集群外的设备作为K8s的客户端，我这里使用的是一台ubuntu。需要保证能够和集群中的master通信。

接着在其上安装kubelctl客户端工具：

apt-get install -y  kubectl=1.22.0-00

回到master设备上，将testuser的kubeconfig文件kc1（kc1如何创建，请查看：https://blog.csdn.net/tushanpeipei/article/details/121877797?spm=1001.2014.3001.5501）拷贝到ubuntu客户端上。并使用如下命令赋予testuser k8s管理员的权限：

root@vms71:~/authentication# kubectl create clusterrolebinding cbind1 --clusterrole=cluster-admin --user=testuser
clusterrolebinding.rbac.authorization.k8s.io/cbind1 created

接下来，testuser用户就可以在ubuntu客户端上对我们部署的K8s集群进行操作了：

root@vms75:~# kubectl get nodes --kubeconfig=kc1
NAME            STATUS   ROLES                  AGE   VERSION
vms71.rhce.cc   Ready    control-plane,master   16d   v1.22.0
vms72.rhce.cc   Ready    <none>                 16d   v1.22.0
vms73.rhce.cc   Ready    <none>                 16d   v1.22.0

2.创建审计策略

在master的/etc/kubernetes/目录下设置审计的文件audit-policy.yaml，内容如下：

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    users: ["testuser"]
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"]

可以看到，此规则主要是记录的是RequestReceived这个阶段产生的信息，请求从上往下开始匹配，只要匹配到了就会被记录。记录的信息针对pods、configmaps资源。其中某些资源的信息仅仅只包含我们所指定的命名空间，如kube-system。
同时，我们在规则中使用了users指定了特定testuser的对pods的记录才会被查看。

3.设置审计后端并开启审计

这里以log的方式记录审计数据。在master上，首先修改vim /etc/kubernetes/manifests/kube-apiserver.yaml文件，在command命令下设置记录使用的审计策略和记录的log文件的位置。如下所示：

 - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
 - --audit-log-path=/var/log/audit.log

还需要通过 hostPath 卷来访问策略文件和日志文件所在的目录（因为kube-apiserver以容器方式运行，需要将其log信息保存到宿主机中，同时访问宿主机的审计配置文件），这样审计记录才会持久保存下来。挂载数据卷：

volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/audit.log
    name: audit-log
    readOnly: false

最后配置 hostPath：

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

重启kubelet使配置生效：

systemctl restart kubelet.service

配置完成后，我们进行最后的测试。

4.审计测试
登录到ubuntu的客户端，使用testuse去访问K8s集群中的pods等资源：

root@vms75:~# kubectl get pods --kubeconfig=kc1
No resources found in default namespace.
root@vms75:~# kubectl get configmaps -n kube-system --kubeconfig=kc1
NAME                                      DATA   AGE
calico-config                             4      16d
cert-manager-cainjector-leader-election   0      15d
cert-manager-controller                   0      15d
coredns                                   1      16d
extension-apiserver-authentication        6      16d
kube-proxy                                2      16d
kube-root-ca.crt                          1      16d
kubeadm-config                            1      16d
kubelet-config-1.22                       1      16d

完成后，返回到master上，查看日志文件：

cat /var/log/audit.log

可以看到，已经以json的格式记录到了很多日志信息。比如这一条就是testuer对于configmaps查询的信息：

后续我们可以借助各种日志分析软件分析这些信息，提取我们需要的内容。

整理资料来源：
K8s audit：https://kubernetes.io/zh/docs/tasks/debug-application-cluster/audit/
《老段CKS课程》