最全Kubernetes审计日志方案

前言

当前Kubernetes（K8S）已经成为事实上的容器编排标准，你们关注的重点也再也不是最新发布的功能、稳定性提高等，正如Kubernetes项目创始人和维护者谈到，Kubernetes已经再也不是buzzword，当咱们谈起它的时候，变得愈加的boring，它做为成熟项目已经走向了IT基础设施的中台，为适应更大规模的生产环境和更多场景的应用不断延展迭代。

而如今咱们更加专一于如何利用K8S平台进行CICD、发布管理、监控、日志管理、安全、审计等等。本期咱们将介绍如何利用K8S中的Audit事件日志来对平台进行安全监控和审计分析。

IT设施/系统是当今每一个互联网公司最为重要的资产之一，除了成本外，这里承载了全部的用户访问，同时保存了很是多的用户、订单、交易、身份等敏感信息。所以每一个公司都有必要确保IT设施/系统是可靠、安全、未泄漏的。其中必不可少的环节是审计，经过审计咱们能够知道系统在任一时间段内发生的事件以及对应关联的内外部人员、系统，在损失发生后可以当即知道具体是谁、在哪一个时间对系统作了什么事，同时基于审计事件的实时分析和告警，可以提早发现问题并及时止损。

Kubernetes审计日志概览

Kubernetes做为容器编排领域的领导者、将来PAAS平台的标准基座，在IT领域有着举足轻重的影响，所以审计功能也是Kubernetes比不可少的安全功能之一。

Kubernetes在1.7版本中发布了审计（Audit）日志功能，审计（Audit）提供了安全相关的时序操做记录（包括时间、来源、操做结果、发起操做的用户、操做的资源以及请求/响应的详细信息等），经过审计日志，咱们可以很是清晰的知道K8S集群到底发生了什么事情，包括但不限于：

1. 当前/历史上集群发生了哪些变动事件。
2. 这些变动操做者是谁，是系统组件仍是用户，是哪一个系统组件/用户。
3. 重要变动事件的详细内容是什么，好比修改了POD中的哪一个参数。
4. 事件的结果是什么，成功仍是失败。
5. 操做用户来自哪里，集群内仍是集群外。

日志格式与策略

K8S中的审计日志是标准的JSON格式，APIServer会根据具体的日志策略将对应的审计日志保存本地，并能够设置最大保存周期、时间、轮转策略等。
关于审计日志格式和策略的详细介绍，能够参考Audit官方文档。

日志记录阶段

审计日志根据日志策略能够选择在事件执行的某个阶段记录，目前支持的事件阶段有：

• RequestReceived - 接收到事件且在分配给对应handler前记录。
• ResponseStarted - 开始响应数据的Header但在响应数据Body发送前记录，这种通常应用在持续很长的操做事件，例如watch操做。
• ResponseComplete - 事件响应完毕后记录。
• Panic - 内部出现panic时记录。

日志记录等级

审计日志根据日志策略能够选择事件保存的等级，根据等级不一样，APIServer记录日志的详细程度也不一样。目前支持的事件等级有：

• None - 不记录日志.
• Metadata - 只记录Request的一些metadata (例如user, timestamp, resource, verb等)，但不记录Request或Response的body。
• Request - 记录Request的metadata和body。
• RequestResponse - 最全记录方式，会记录全部的metadata、Request和Response的Body。

日志记录策略

APIServer支持对每类不一样的资源设置不一样的审计日志策略，包括日志记录阶段以及日志记录等级，目前官方以及不少云厂商都会提供日志策略，通常都遵循如下原则：

• 在收到请求后不当即记录日志，当返回体header发送后才开始记录。
• 对于大量冗余的kube-proxy watch请求，kubelet和system:nodes对于node的get请求，kube组件在kube-system下对于endpoint的操做，以及apiserver对于namespaces的get请求等不做审计。
• 对于/healthz，/version, /swagger*等只读url不做审计。
• 对于可能包含敏感信息或二进制文件的secrets，configmaps，tokenreviews接口的日志等级设为metadata，该level只记录请求事件的用户、时间戳、请求资源和动做，而不包含请求体和返回体。
• 对于一些如authenticatioin、rbac、certificates、autoscaling、storage等敏感接口，根据读写记录相应的请求体和返回体。

审计日志分析

审计日志分析现状

目前对于K8S上的APIServer审计日志的支持，大部分厂商还停留在策略设置或日志采集的阶段，最多只支持将数据采集到日志中心，配合索引进行关键词查询。
下图是一个Level为Metadata的审计日志记录，各种字段有20多个，若是是Level为Request或RequestResponse的日志字段会更多，可能达到上百个。要实现审计日志分析，必须理解这些字段的含义，此外还需理解每一个字段的取值范围以及每种取值对应的含义，学习代价很是之大。

{
  "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": "ResponseComplete",
  "requestURI": "/apis/authentication.k8s.io/v1beta1?timeout=32s",
  "verb": "get",
  "user": {
    "username": "system:serviceaccount:kube-system:generic-garbage-collector",
    "uid": "cd3fbe04-0508-11e9-965f-00163e0c7cbe",
    "groups": [
      "system:serviceaccounts",
      "system:serviceaccounts:kube-system",
      "system:authenticated"
    ]
  },
  "sourceIPs": [
    "192.168.0.249"
  ],
  "responseStatus": {
    "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:authenticated\""
  }
}

阿里云Kubernetes审计日志方案

为尽量减小用户对于审计日志的分析代价，阿里云容器服务将Kubernetes审计日志与日志服务SLS打通，推出了一站式的Kubernetes审计日志方案，让每一个用户都可以以图形化报表的方式进行集群的审计分析。

1. 为尽量保证集群安全性，阿里云容器服务Kubernetes默认为用户打开了APIServer审计日志并设置了较为安全且通用的审计日志策略，全部（符合审计策略）用户、组件对APIServer的访问都会被记录下来；
2. Kubernetes集群中预置的日志组件Logtail会将APIServer的审计日志自动采集到阿里云日志服务；
3. 日志服务默认会为APIServer的审计日志建立索引、报表等；
4. 容器服务控制台已经和日志服务打通，集群管理员能够直接在控制台上查看审计日志的各项报表以及指标；
5. 若集群管理员还有设置告警、自定义分析等需求，可直接登陆日志服务控制台进行操做。

得益于阿里云日志服务的强大功能，该方案不只大大下降了K8S审计日志分析的门槛，从分析能力、可视化、交互方式、性能等各方面都具备很强的优点：

审计日志方案概览

审计报表

咱们默认为Kubernetes集群建立了3个报表，分别是审计中心概览、资源操做概览和资源详细操做列表：

1. 审计中心概览展现Kubernetes集群中的事件总体概览信息以及重要事件（公网访问、命令执行、删除资源、访问保密字典等）的详细信息。

2. 资源操做概览展现Kubernetes集群中常见的计算资源、网络资源以及存储资源的操做统计信息，操做包括建立、更新、删除、访问。其中

   1. 计算资源包括：Deployment、StatefulSet、CronJob、DaemonSet、Job、Pod；
   2. 网络资源包括：Service、Ingress；
   3. 存储资源包括：ConfigMap、Secret、PersistentVolumeClaim。
3. 资源详细操做列表用于展现Kubernetes集群中某类资源的详细操做列表，经过选择或输入指定的资源类型进行实时查询，该表报会显示：资源操做各种事件的总数、namespace分布、成功率、时序趋势以及详细操做列表等。

全部的报表均支持设置时间范围、子帐号ID、Namespace等进行自定义过滤并实时刷新，经过这些报表，集群管理员只用点击鼠标就能够获取到：

1. 最近任一时间段内建立/删除/修改了哪些资源；
2. 事件的时序趋势如何；
3. 具体是哪一个子帐号操做了资源；
4. 操做的IP源是否为公网、地域分布如何、来源IP是否高危；
5. 具体操做的事件ID、时间、结果、涉及的资源等详细日志；
6. 哪一个子帐号登陆了容器或访问了保密字典...

这里咱们选择一个图标作详细说明：上图是Kubernetes资源操做列表，这个报表彻底是交互式的，用户能够指定一种资源（好比Deployment、Ingress、Secret等），表报会自动渲染出关于这个资源的全部操做，功能包括：

1. 左上角会显示对这个资源操做的用户数、涉及Namespace数、涉及方法数、请求成功率等概览信息；
2. 每种不一样操做（增、删、改、查）的数量以及Namespace分布，用来肯定涉及的Namespace；
3. 各种操做的时序分布（按小时），数量较多的点通常都是发布或系统被攻击的时间点；
4. 各种操做的详细列表，包括：事件ID、操做事件、操做资源、操做结果、帐号、地址；
5. 图表中全部的事件ID均可以点击并跳转到原始的日志，查看具体和这个事件ID关联的详细日志；
6. 图表中全部的IP地址均可以点击并跳转到外部的IP查询库，查询该IP对应的地理位置、运营商等信息；
7. 图表还支持根据帐号、namespace、请求码等过滤，好比对某个用户进行审计时，能够过滤子帐号，只关心该用户的操做。

自定义告警

例如须要对公网访问设置告警策略：出现公网访问时当即告警，则只需3步就可完成设置：

1. 在审计报表的公网访问图表中点击右上角高级选项-新建告警
2. 填入告警名称、事件、判断条件
3. 填入告警通知方式以及通知内容

自定义分析

若是容器服务Kubernetes版提供的默认报表没法知足您的分析需求，能够直接使用日志服务SQL、仪表盘等功能进行自定义的分析和可视化。

尝鲜

为了让你们能够体验Kubernetes审计日志功能，咱们特别开通了体验中心，你们能够经过 https://promotion.aliyun.com/ntms/act/logdoclist.html 进入，该页面提供了很是多和Kubernetes相关的报表。

参考文档

1. kubernetes auditing
2. Kubernetes 的审计日志和采集
3. 阿里云容器服务Kubernetes审计日志
4. 阿里云日志服务
5. 阿里云容器服务Kubernetes版

 

原文连接 更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight