KubernetesAPI审计⽇志⽅案
KubernetesAPI审计⽇志⽅案
当前Kubernetes（K8S）已经成为事实上的容器编排标准，⼤家关注的重点也不再是最新发布的功能、稳定性提升等，正如Kubernetes 项⽬创始⼈和维护者谈到，Kubernetes已经不再是buzzword，当我们谈起它的时候，变得越发的boring，它作为成熟项⽬已经⾛向了IT 基础设施的中台，为适应更⼤规模的⽣产环境和更多场景的应⽤不断延展迭代。
⽽现在我们更加专注于如何利⽤K8S平台进⾏CICD、发布管理、监控、⽇志管理、安全、审计等等。本期我们将介绍如何利⽤K8S中的Audit事件⽇志来对平台进⾏安全监控和审计分析。
[外链图⽚转存失败，源站可能有防盗链机制，建议将图⽚保存下来直接上传(img-Zho2h2I7-1606798413403)
(/Urs/zhaobei/Library/Application Support/typora-ur-images/image-20201022095953045.png)]
IT设施/系统是当今每个互联⽹公司最为重要的资产之⼀，除了成本外，这⾥承载了所有的⽤户访问，同时保存了⾮常多的⽤户、订单、交易、⾝份等敏感信息。因此每个公司都有必要确保IT设施/系统是可靠、安全、未泄漏的。其中必不可少的环节是审计，通过审计我们可以知道系统在任⼀时间段内发⽣的
事件以及对应关联的内外部⼈员、系统，在损失发⽣后能够⽴即知道具体是谁、在哪个时间对系统做了什么事，同时基于审计事件的实时分析和告警，能够提前发现问题并及时⽌损。
Kubernetes审计⽇志概览
Kubernetes作为容器编排领域的领导者、未来PAAS平台的标准基座，在IT领域有着举⾜轻重的影响，因此审计功能也是Kubernetes⽐不可少的安全功能之⼀。
Kubernetes在1.7版本中发布了审计（Audit）⽇志功能，审计（Audit）提供了安全相关的时序操作记录（包括时间、来源、操作结果、发起操作的⽤户、操作的资源以及请求/响应的详细信息等），通过审计⽇志，我们能够⾮常清晰的知道K8S集群到底发⽣了什么事情，包括但不限于：
当前/历史上集群发⽣了哪些变更事件。
这些变更操作者是谁，是系统组件还是⽤户，是哪个系统组件/⽤户。
重要变更事件的详细内容是什么，⽐如修改了POD中的哪个参数。
事件的结果是什么，成功还是失败。
操作⽤户来⾃哪⾥，集群内还是集群外。
⽇志格式与策略
人脉就是钱脉K8S中的审计⽇志是标准的JSON格式，APIServer会根据具体的⽇志策略将对应的审计⽇志保存本地，并可以设置最⼤保存周期、时间、轮转策略等。
关于审计⽇志格式和策略的详细介绍，可以参考Audit官⽅⽂档。
⽇志记录阶段
审计⽇志根据⽇志策略可以选择在事件执⾏的某个阶段记录，⽬前⽀持的事件阶段有：
RequestReceived - 接收到事件且在分配给对应handler前记录。
ResponStarted - 开始响应数据的Header但在响应数据Body发送前记录，这种⼀般应⽤在持续很长的操作事件，例如watch操作。ResponComplete - 事件响应完毕后记录。
Panic - 内部出现panic时记录。
⽇志记录等级
审计⽇志根据⽇志策略可以选择事件保存的等级，根据等级不同，APIServer记录⽇志的详细程度也不同。⽬前⽀持的事件等级有：
None - 不记录⽇志.
Metadata - 只记录Request的⼀些metadata (例如ur, timestamp, resource, verb等)，但不记录Request或Respon的body。Request - 记录Request的metadata和body。
RequestRespon - 最全记录⽅式，会记录所有的metadata、Request和Respon的Body。
百乐门舞厅
⽇志记录策略
APIServer⽀持对每类不同的资源设置不同的审计⽇志策略，包括⽇志记录阶段以及⽇志记录等级，⽬前官⽅以及很多云⼚商都会提供⽇志策略，⼀般都遵循以下原则：
在收到请求后不⽴即记录⽇志，当返回体header发送后才开始记录。
笔记本插网线对于⼤量冗余的kube-proxy watch请求，kubelet和system:nodes对于node的get请求，kube组件在kube-system下对于endpoint的操作，以及apirver对于namespaces的get请求等不作审计。
对于/healthz，/version, /swagger*等只读url不作审计。
对于可能包含敏感信息或⼆进制⽂件的crets，configmaps，tokenreviews接⼝的⽇志等级设为metadata，该level只记录请求事件的⽤户、时间戳、请求资源和动作，⽽不包含请求体和返回体。
对于⼀些如authenticatioin、rbac、certificates、autoscaling、storage等敏感接⼝，根据读写记录相应的请求体和返回体。
审计⽇志分析
审计⽇志分析现状
⽬前对于K8S上的APIServer审计⽇志的⽀持，⼤部分⼚商还停留在策略设置或⽇志采集的阶段，最多只⽀持将数据采集到⽇志中⼼，配合索引进⾏关键词查询。
私家车广告下图是⼀个Level为Metadata的审计⽇志记录，各类字段有20多个，如果是Level为Request或RequestRespon的⽇志字段会更多，可能达到上百个。要实现审计⽇志分析，必须理解这些字段的含义，此外还需理解每个字段的取值范围以及每种取值对应的含义，学习代价⾮常之⼤。
{
“kind”: “Event”,
“apiVersion”: “audit.k8s.io/v1beta1”,
“metadata”: {
"creationTimestamp": "2019-01-14T07:48:38Z"
},
“level”: “Metadata”,
“timestamp”: “2019-01-14T07:48:38Z”,
“auditID”: “cf2915c0-0b43-4e1d-9d66-fbae481a0e0a”,
“stage”: “ResponComplete”,
“requestURI”: “/apis/authentication.k8s.io/v1beta1?timeout=32s”,
“verb”: “get”,
“ur”: {
"urname": "system:rviceaccount:kube-system:generic-garbage-collector",
"uid": "cd3fbe04-0508-11e9-965f-00163e0c7cbe",
"groups": [
"system:rviceaccounts",
"system:rviceaccounts:kube-system",
"system:authenticated"
]
},
“sourceIPs”: [
保护水资源作文],
“responStatus”: {
"metadata": {},
"code": 200
},
“requestReceivedTimestamp”: “2019-01-14T07:48:38.214979Z”,
“stageTimestamp”: “2019-01-14T07:48:38.215102Z”,
“annotations”: {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticat ed\""
}
}
阿⾥云Kubernetes审计⽇志⽅案
为尽可能减少⽤户对于审计⽇志的分析代价，阿⾥云容器服务将Kubernetes审计⽇志与⽇志服务SLS打通，推出了⼀站式的Kubernetes审计⽇志⽅案，让每个⽤户都能够以图形化报表的⽅式进⾏集群的
审计分析。
为尽可能保证集群安全性，阿⾥云容器服务Kubernetes默认为⽤户打开了APIServer审计⽇志并设置了较为安全且通⽤的审计⽇志策略，所有（符合审计策略）⽤户、组件对APIServer的访问都会被记录下来；
Kubernetes集群中预置的⽇志组件Logtail会将APIServer的审计⽇志⾃动采集到阿⾥云⽇志服务；
⽇志服务默认会为APIServer的审计⽇志创建索引、报表等；
容器服务控制台已经和⽇志服务打通，集群管理员可以直接在控制台上查看审计⽇志的各项报表以及指标；
若集群管理员还有设置告警、⾃定义分析等需求，可直接登录⽇志服务控制台进⾏操作。
得益于阿⾥云⽇志服务的强⼤功能，该⽅案不仅⼤⼤降低了K8S审计⽇志分析的门槛，从分析能⼒、可视化、交互⽅式、性能等各⽅⾯都具有很强的优势：
审计报表
我们默认为Kubernetes集群创建了3个报表，分别是审计中⼼概览、资源操作概览和资源详细操作列表：
审计中⼼概览展⽰Kubernetes集群中的事件整体概览信息以及重要事件（公⽹访问、命令执⾏、删除资源、访问保密字典等）的详细信息。
资源操作概览展⽰Kubernetes集群中常见的计算资源、⽹络资源以及存储资源的操作统计信息，操作包括创建、更新、删除、访问。其中
计算资源包括：Deployment、StatefulSet、CronJob、DaemonSet、Job、Pod；
⽹络资源包括：Service、Ingress；
存储资源包括：ConfigMap、Secret、PersistentVolumeClaim。
资源详细操作列表⽤于展⽰Kubernetes集群中某类资源的详细操作列表，通过选择或输⼊指定的资源类型进⾏实时查询，该表报会显⽰：资源操作各类事件的总数、namespace分布、成功率、时序趋势以及详细操作列表等。
所有的报表均⽀持设置时间范围、⼦账号ID、Namespace等进⾏⾃定义过滤并实时刷新，通过这些报表，集群管理员只⽤点击⿏标就可以获取到：
最近任⼀时间段内创建/删除/修改了哪些资源；
事件的时序趋势如何；
具体是哪个⼦账号操作了资源；
操作的IP源是否为公⽹、地域分布如何、来源IP是否⾼危；
具体操作的事件ID、时间、结果、涉及的资源等详细⽇志；
哪个⼦账号登录了容器或访问了保密字典…
这⾥我们选择⼀个图标做详细说明：上图是Kubernetes资源操作列表，这个报表完全是交互式的，⽤户可以指定⼀种资源（⽐如Deployment、Ingress、Secret等），表报会⾃动渲染出关于这个资源的所有操作，功能包括：
左上⾓会显⽰对这个资源操作的⽤户数、涉及Namespace数、涉及⽅法数、请求成功率等概览信息；
每种不同操作（增、删、改、查）的数量以及Namespace分布，⽤来确定涉及的Namespace；
各类操作的时序分布（按⼩时），数量较多的点⼀般都是发布或系统被攻击的时间点；
低调解析各类操作的详细列表，包括：事件ID、操作事件、操作资源、操作结果、账号、地址；手绘眼睛
图表中所有的事件ID都可以点击并跳转到原始的⽇志，查看具体和这个事件ID关联的详细⽇志；
图表中所有的IP地址都可以点击并跳转到外部的IP查询库，查询该IP对应的地理位置、运营商等信息；
图表还⽀持根据账号、namespace、请求码等过滤，⽐如对某个⽤户进⾏审计时，可以过滤⼦账号，只关⼼该⽤户的操作。
⾃定义告警
例如需要对公⽹访问设置告警策略：出现公⽹访问时⽴即告警，则只需3步就可完成设置：
在审计报表的公⽹访问图表中点击右上⾓⾼级选项-新建告警
填⼊告警名称、事件、判断条件
痛悼
填⼊告警通知⽅式以及通知内容
⾃定义分析
如果容器服务Kubernetes版提供的默认报表⽆法满⾜您的分析需求，可以直接使⽤⽇志服务SQL、仪表盘等功能进⾏⾃定义的分析和可视化。
实践
实践环境应具有：es、fluentd、kibana
[外链图⽚转存失败，源站可能有防盗链机制，建议将图⽚保存下来直接上传(img-aaSAcfwT-1606798413409)
(/Urs/zhaobei/Library/Application Support/typora-ur-images/image-20201022150121703.png)]
Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录每个⽤户、管理员 或系统其他组件影响系统的活动顺序。 它能帮助集群管理员处理以下问题：
