前言

当前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

最全Kubernetes审计日志方案的更多相关文章

  1. Kubernetes审计日志方案

    前言 当前Kubernetes(K8S)已经成为事实上的容器编排标准,大家关注的重点也不再是最新发布的功能.稳定性提升等,正如Kubernetes项目创始人和维护者谈到,Kubernetes已经不再是 ...

  2. Kubernetes Ingress 日志分析与监控的最佳实践

    摘要: Ingress主要提供HTTP层(7层)路由功能,是目前K8s中HTTP/HTTPS服务的主流暴露方式.为简化广大用户对于Ingress日志分析与监控的门槛,阿里云容器服务和日志服务将Ingr ...

  3. Kubernetes 集群日志 和 EFK 架构日志方案

    目录 第一部分:Kubernetes 日志 Kubernetes Logging 是如何工作的 Kubernetes Pod 日志存储位置 Kubelet Logs Kubernetes 容器日志格式 ...

  4. Kubernetes 常用日志收集方案

    Kubernetes 常用日志收集方案 学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集. 介绍 应用程序和系统日志可以帮助 ...

  5. Kubernetes Ingress日志分析入门

    本文主要介绍如何基于日志服务构建Kubernetes Ingress日志分析平台,并提供一些简单的动手实验方便大家快速了解日志服务相关功能. 部署Ingress日志方案 登录容器服务管理控制台. 将上 ...

  6. Mysql备份系列(2)--mysqldump备份(全量+增量)方案操作记录

    在日常运维工作中,对mysql数据库的备份是万分重要的,以防在数据库表丢失或损坏情况出现,可以及时恢复数据. 线上数据库备份场景:每周日执行一次全量备份,然后每天下午1点执行MySQLdump增量备份 ...

  7. [Kubernetes]容器日志的收集与管理

    在开始这篇文章之前,首先要明确一点: Kubernetes 中对容器日志的处理方式,都叫做 cluster-level-logging ,也就是说,这个日志处理系统,与容器, Pod 以及 Node ...

  8. TopoLVM: 基于LVM的Kubernetes本地持久化方案,容量感知,动态创建PV,轻松使用本地磁盘

    正文 研发测试场景下,一般追求的是一键快速起环境,横向动态复制,一人一套,随起随用,用完即走.作为使用方,其不用关心实际的物理资源是怎样的,环境起在哪里,只要声明自己的使用需求即可.但作为方案构建者以 ...

  9. ABP(现代ASP.NET样板开发框架)系列之19、ABP应用层——审计日志

    点这里进入ABP系列文章总目录 基于DDD的现代ASP.NET开发框架--ABP系列之19.ABP应用层——审计日志 ABP是“ASP.NET Boilerplate Project (ASP.NET ...

随机推荐

  1. Java 多线程 - 创建线程的方法 + Executors.newXXXThreadPool()缺点

    java中创建线程的三种方法以及区别: https://www.cnblogs.com/3s540/p/7172146.html 通过Executor 的工具类,创建三种类型的普通线程池: https ...

  2. 阿里云应用上边缘云解决方案助力互联网All in Cloud

    九月末的杭州因为一场云栖大会变得格外火热. 9月25日,吸引全球目光的2019杭州云栖大会如期开幕.20000平米的展区集结数百家企业,为数万名开发者带来了一场前沿科技的饕餮盛宴. 如同往年一样,位于 ...

  3. bfs+dfs乱搞+类似拓扑排序——cf1182D

    代码不知道上了多少补丁..终于过了 用类似拓扑排序的办法收缩整棵树得到x,然后找到x直连的最远的和最近的点 只有这三个点可能是根,依次判一下即可 另外题解的第一种方法时找直径,然后判两端点+重心+所有 ...

  4. vue cli2.x配置多环境打包

    一.安装 npm install --save-dev cross-env 二.配置步骤 1.修改config下的文件 //test.env.js 'use strict' module.export ...

  5. PAT甲级——A1121 Damn Single【25】

    "Damn Single (单身狗)" is the Chinese nickname for someone who is being single. You are suppo ...

  6. 干货:排名前 16 的 Java 工具类!

    在Java中,工具类定义了一组公共方法,这篇文章将介绍Java中使用最频繁及最通用的Java工具类.以下工具类.方法按使用流行度排名,参考数据来源于Github上随机选取的5万个开源项目源码. 一. ...

  7. <scrapy爬虫>爬取360妹子图存入mysql(mongoDB还没学会,学会后加上去)

    1.创建scrapy项目 dos窗口输入: scrapy startproject images360 cd images360 2.编写item.py文件(相当于编写模板,需要爬取的数据在这里定义) ...

  8. <Python基础>装饰器的基本原理

    1.装饰器 所谓装饰器一般是对已经使用(上线)的函数增加功能. 但是因为一般的大公司的严格按照开放封闭原则(对扩展是开放的,对修改是封闭的),不会让你修改原本的函数. 装饰器就是在不改变原本的函数且不 ...

  9. [洛谷P3672]小清新签到题

    题目描述 题目还是简单一点好. 给定自然数n.k.x,你要求出第k小的长度为n的逆序对对数为x的1~n的排列a1,a2...an,然后用仙人图上在线分支定界启发式带花树上下界最小费用流解决问题,保证存 ...

  10. 【NOI2010】能量采集

    题面 题目分析 对于第\((i,j)\)个位置,对答案的贡献为\(2*gcd(i,j)-1\). 所以有\(ans=2*\sum\limits_{i=1}^n\sum\limits_{j=1}^mgc ...