目录
概述
审计事件阶段
审计日志级别
None
Metadata
Request
RequestResponse
审计日志的使用
步骤1:配置审计策略文件
步骤2:配置API Server
步骤3:配置日志存储
注意事项
审计策略与规则
审计日志样例
使用场景
概述
Kubernetes集群中,API Server的审计日志详细记录了用户、服务对集群资源的请求操作. 通过对API Server的审计,可以监控分析API流量,检测安全隐患.
具体来说,这些服务会访问API Server:
- 管理节点:controller-manager、scheduler
- 工作节点:kubelet、kube-proxy
- 集群服务:CoreDNS、Calico、HPA等
- 客户端工具:kubectl、API、Dashboard
审计事件阶段
当Client客户端向API Server发出请求时,会经历以下某些阶段
阶段 | 说明 |
RequestReceived | 表示API Server接收到了请求。这是审计日志记录开始的点,所有的请求无论成功与否都会记录在此阶段 |
ResponseStarted | 表示API Server已经找到了请求对应的资源,并开始返回响应。这意味着请求已经被处理,并且开始生成响应。 |
ResponseComplete | 表示响应已被完全处理并发送给了请求者。不管请求处理成功还是失败,如果响应体已经生成,就会记录这个阶段。 |
Panic | 如果在处理请求的过程中发生了内部服务器错误,会记录这个阶段的日志。 |
审计日志级别
在Kubernetes中,可以通过配置审计策略(Audit Policy)来指定对API Server的请求要记录哪些审计日志. 审计策略中包含一个有序的审计规则列表,每条规则通过level
字段指定日志级别.
Kubernetes支持以下审计日志级别:
None
level: None
表示不记录日志.适用于以下情况:
- 不需要对某些资源操作审计,如密钥、configmap等
- 避免Storage大小超支,排除不重要的审计
- 减少日志存储和传输的性能开销
例如,下面的策略规则不记录对kube-system
和kube-public
名字空间的审计日志:
- level: None
namespaces: ["kube-system", "kube-public"]
Metadata
level: Metadata
表示只记录审计事件的元数据,不记录请求和响应的消息体.元数据包括:
- 请求的用户、IP、用户组、资源、动词等
- 请求的时间戳和审计ID
- 响应的状态码
适用于以下情况:
- 关注事件的关键信息,如谁在何时做了什么
- 消息体可能包含敏感信息,如Secret、私钥
- 消息体数据量很大,全量记录会占用很多存储
例如,下面的策略规则对匿名用户只记录Metadata级别的日志:
- level: Metadata
userGroups: ["system:unauthenticated"]
Request
level: Request
表示记录事件的元数据和请求消息体,但不记录响应消息体.适用于以下情况:
- 需要审计请求的具体内容,如创建、更新的资源配置
- 请求消息体相对较小,全量记录的开销可以接受
- 响应消息体无需审计,或者数据量过大不宜全量记录
例如,下面的策略规则对认证用户记录Request级别的日志:
- level: Request
userGroups: ["system:authenticated"]
verbs: ["create", "update", "patch", "delete"]
resources:
- group: ""
resources: ["pods", "secrets", "configmaps"]
RequestResponse
level: RequestResponse
表示记录事件的元数据、请求消息体、响应消息体,是最高的审计级别.适用于以下情况:
- 事关安全或合规,需要完整记录请求和响应
- 全量审计的性能和存储开销在预期之内
- 调试或故障诊断时需要事后回放完整的API调用过程
例如,下面的策略规则对特权用户的所有写操作记录RequestResponse级别的日志:
- level: RequestResponse
userGroups: ["manager", "admin"]
verbs: ["create", "update", "patch", "delete"]
resources:
- group: "*"
resources: ["*"]
审计日志的使用
步骤1:配置审计策略文件
-
创建审计策略文件(例如:
/etc/kubernetes/audit/audit-policy.yaml
)。 -
在审计策略文件中定义审计规则,指定想要审计的资源和相应的日志级别。
示例策略文件内容:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: ""
resources: ["pods"]
步骤2:配置API Server
-
编辑API服务器的配置文件(例如:
/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
步骤3:配置日志存储
-
确保审计日志文件(例如:
/var/log/k8s_audit.log
)能够被正确创建和存储。 -
在kube-apiserver的配置文件(例如:
/etc/kubernetes/manifests/kube-apiserver.yaml
)中设置volumeMounts,将审计策略文件和审计日志文件的存储路径挂载到API服务器的容器内。示例如下:
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
注意事项
- 请确保API服务器可以访问审计策略文件和审计日志文件的路径。
- 审计日志的大小和保留期限应根据集群的实际情况进行调整,避免过大的日志文件占用过多磁盘空间。
- 对于使用HostPath方式挂载的文件和目录,需要确保它们在宿主机上存在并且权限正确
审计策略与规则
Kubernetes使用审计策略(Policy)来指定对API Server请求的审计规则,也就是上方/etc/kubernetes/audit/audit-policy.yaml的内容
审计策略中包含一个有序的审计规则(Rule)列表,从上到下逐一匹配请求,直到命中某条规则。如果有a、b两条规则都针对pod,从上至下先到a,则a规则生效
每条审计规则指定了:
- 日志级别(Level): None(不记录)、Metadata(只记录metadata)、Request(记录请求)、RequestResponse(记录请求和响应)
- 资源(Resources):对哪些资源的请求应用该规则,如pods、deployments
- 动词(Verbs): 对资源的哪些操作应用该规则,如get、list、create、update、delete等
- ...
示例审计策略如下:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 不记录对RequestReceived阶段的日志
- level: None
stage: RequestReceived
# 不记录对kube-system和kube-public命名空间的请求日志
- level: None
namespaces: ["kube-system", "kube-public"]
# 不记录对/healthz*、/logs、/metrics请求路径的日志
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/healthz*"
- "/logs"
- "/metrics"
# 对可信用户记录请求阶段的日志
- level: Request
userGroups: ["system:authenticated"]
verbs: ["get", "list", "watch"]
resources:
- group: ""
resources: ["*"]
# 对不可信用户记录metadata阶段的日志
- level: Metadata
userGroups: ["system:unauthenticated"]
# 默认记录metadata阶段的日志
- level: Metadata
omitStages:
- RequestReceived
审计日志样例
这个审计日志输出样例记录了一个创建部署(Deployment)的事件,其中包含了操作的基本元数据,比如请求的类型、用户信息、被操作的对象、时间戳等。
{
"kind": "Event", // 事件类型
"apiVersion": "audit.k8s.io/v1", // 审计日志的API版本
"level": "Metadata", // 审计级别
"auditID": "4becec1a-0d3d-4304-904d-7c0695c3d938", // 审计事件的唯一标识符
"stage": "ResponseComplete", // 请求阶段,表示响应已完成
"requestURI": "/apis/apps/v1/namespaces/default/deployments?fieldManager=kubectl-create", // 请求的URI
"verb": "create", // 请求动作
"user": { // 用户信息
"username": "kubernetes-admin", // 用户名
"groups": [ // 用户所属的组
"system:masters",
"system:authenticated"
]
},
"sourceIPs": [ // 发起请求的源IP地址
"192.168.31.71"
],
"userAgent": "kubectl/v1.21.0 (linux/amd64) kubernetes/cb303e6", // 用户代理,客户端信息
"objectRef": { // 关于被操作对象的引用
"resource": "deployments", // 资源类型
"namespace": "default", // 资源所在的命名空间
"name": "web-demo", // 资源名称
"apiGroup": "apps", // 资源所属的API组
"apiVersion": "v1" // 资源的API版本
},
"responseStatus": { // 响应状态
"metadata": {},
"code": 201 // HTTP状态码
},
"requestReceivedTimestamp": "2021-11-08T16:16:53.551850Z", // 请求接收的时间戳
"stageTimestamp": "2021-11-08T16:16:53.569307Z", // 请求阶段的时间戳
"annotations": { // 注解信息
"authorization.k8s.io/decision": "allow", // 授权决策
"authorization.k8s.io/reason": "" // 授权原因
}
}
使用场景
通过分析和监控审计日志,我们可以实现以下目标:
- 事后审计(Audit): 对受到入侵、误操作造成故障时,可以通过审计日志复盘事故过程.
- 实时告警(Alert): 对违反策略的行为实时告警,如用户访问未授权的资源.
- 行为分析(Analysis): 分析用户、服务对资源的访问行为,挖掘使用规律和异常情况.
- 合规检查(Compliance): 保存审计日志以满足法规合规性要求,如SOX法案.
- 容量规划(Capacity): 通过审计日志分析资源使用情况,辅助容量评估和规划.
- 异常检测(Anomaly): 建立API请求基线,侦测异常API调用,对可疑行为发出告警.
- 溯源取证(Forensics): 充当事件的法律证据,帮助犯罪分析,损失评估等.