零信任策略下K8s安全监控最佳实践

2022年09月14日 11:23:34 徐可甲(烨陌) 来源：阿里开发者

　　云原生架构新风险与需求概述

　　安全风险概述

　　传统的网络安全架构理念是基于边界的安全架构，企业构建网络安全体系时，首先要做的是寻找安全边界，把网络划分为外网、内网等不同的区域，然后在边界上部署防火墙、入侵检测、WAF等产品。然而这种网络安全架构是基于内网比外网更安全的假设建立起来，在某种程度上预设了对内网中的人、设备和系统的信任，忽视加强内网安全措施。不法分子一旦突破企业的边界安全防护进入内网，会像进入无人之境，将带来严重的后果。此外，内部人员100%安全的假说也是不成立的，我们可以从《内部威胁成本全球报告》里看到，不管是内部威胁的数量，还是威胁成本都是呈显著上升的趋势。

　　随着云计算、大数据、物联网、移动办公等新技术与业务的深度融合，网络安全边界也逐渐变得更加模糊，传统边界安全防护理念面临巨大挑战。以办公网络安全为例，已经逐步从仅支持公司内部网络设备连接，发展到使用办公电脑通过VPN远程连接，甚至移动办公的到来，使得个人手机等个人设备接入变成了可能。在这样的背景下，零信任架构(Zero Trust Architecture, ZTA)应运而生。它打破传统的认证，即信任边界防护、静态访问控制、以网络为中心等防护思路，建立起一套以身份为中心，以持续认证、动态访问控制、审计以及监测为链条，以最小化实时授权为核心，以多维信任算法为基础，认证达末端的动态安全架构。

　　我们知道Kubernetes在容器编排市场中占据了主导地位，用户基数呈逐年上升的趋势。K8s提供了强大的运维部署、弹性伸缩、故障恢复能力，极大地便利了分布式系统的开发和管理，但是随之而来的安全问题却也比较突出。

　　根据《容器和Kubernetes安全态势报告》报告，针对云原生应用的威胁已越来越多，仅有6%的人没有经历过与容器或K8s相关的安全事件。同时，还指出近70%的安全风险都是由人为错误配置而引发的，此外运行时安全及重大安全漏洞引发的安全事件也是重要的因素。《中国云原生用户调查报告》同样也支持，容器安全问题成为用户应用的最大担忧。63%的用户认为容器安全是紧迫的需求，大量用户反馈网络安全技术实施难度复杂度高，且监控系统、日志系统不完善，很难进行有效的安全监控。

　　从上述的报告可以看出，K8s安全问题会分布在整个生命周期的各个阶段。一些常见的安全风险表现为：容器镜像漏洞或滥用镜像仓库导致的漏洞;容器大量部署导致很难发觉安全问题;K8s核心组件漏洞威胁，多个高危漏洞爆出;集群配置不当，甚至一些默认配置有安全隐患;没有明确网络边界，网络隔离性问题;攻击面变大、监控和防护难度大。因此，我们迫切需要建立一个全方位的安全体系，覆盖整个容器生命周期的各个阶段。

　　构建时：基于安全的镜像仓库、权限最小化的安全镜像构建业务系统，及时修复已知漏洞。

　　部署时：按照K8s最佳实践部署，修复错误配置。

　　运行时：持续监控安全威胁，并及时做出相应。

　　K8s 安全体系

　　上图为阿里云容器服务Kubernetes版给出的安全体系，可以看出构建完善的安全体系从下到上需要覆盖基础架构安全、可信软件供应链、运行时安全三个维度。

　　基础架构安全：基于CIS kubernetes benchmark指导安全部署;依赖K8s的安全体系，建立细粒度的访问控制机制。

　　可信软件供应链：通过镜像扫描发现已知安全漏洞;通过镜像签名保障镜像来源的安全性及不被篡改;通过DevSecOps集成，实现安全左移，与开发、测试、运维等质量动作进行深度融合。

　　运行时安全：通过PodSecurityPolicy针对容器部署时进行安全校验，有效约束应用运行时的行为安全;应用运行时的安全配置巡检;持续的无处不在的运行时安全监控机制和异常事件告警通知机制，保证安全事件的及时发现及解决;选用安全沙箱，提供更强的隔离环境。

　　我们发现上述安全体系可以跟零信任策略的“从不信任、始终验证”的思想相呼应的。

　　K8s 信任边界

　　为了更好的理解K8s系统的安全风险，接下来我们从K8s内外部网络边界的角度展开分析。其中，红色曲线部分可以被视为独立边界的子系统。

　　容器镜像：主要涉及到的安全攻击点就是镜像仓库和镜像本身。其中，使用了不受信任的镜像仓库或被篡改的容器镜像会导致恶意代码被执行。

　　K8s控制平面：涉及K8s 的 API Server、scheduler 和 controller-manager核心组件等。其中API Server为K8s系统管控入口，是重点的攻击对象。另外，核心组件之间调用链的安全也同样重要。

　　K8s数据平面：涉及Ingress Controller跟Service，Ingress作为内部服务对外暴露的端口，被攻击风险较大。

　　节点上运行时安全：涉及kubelet、kube-proxy 和容器运行时环境，需要避免运行时容器越权或容器逃逸等风险。

　　K8s安全攻击来源众多，既可能是来自外部的控制平面攻击，也可能是来自外部流量的数据面攻击，甚至可能是来自内部成员的恶意攻击或者误操作等。因此，K8s攻击面特别广，防护难度大，为了更好的保护K8s安全运行，需要建议起一套策略防护跟监控防护相结合的防护体系。

　　本文重点将围绕监控防护展开，逐层递进地介绍如何在复杂的分布式容器化环境中借助可观测性平台，持续监控K8s集群，及时发现异常的 API 访问事件、异常流量、异常配置、异常日志等行为，并且结合合理的告警策略建立更主动的安全防御体系。

　　K8s 场景下安全数据采集技术方案

　　安全数据是作为K8s安全监控的根本，如果没有数据那就是“巧妇难为无米之炊”，任何高级的监控策略都无从谈起。因此，首先我们将会介绍K8s相关的安全数据源及相关的采集技术。

　　安全数据源

　　K8s 审计日志

　　在 Kubernetes 中，Api Server是K8s集群资源变更、查询的入口，所有对集群状态的查询和修改都是通过向 Api Server 发送请求，对 Api Server 的请求来源可以分为4类：

　　控制面组件，例如 Scheduler，各种 Controller，Api Server 自身。

　　节点上的各种 Agent，例如 Kubelet、Kube-proxy 等。

　　集群的其它服务，例如 Coredns、Ingress-controller、各种第三方的 Operator 等。

　　外部用户，例如运维人员通过 Kubectl。

　　Kubernetes 审计日志是 Api Server 产生的结构化日志，记录了对 Api Server 的访问操作(包括时间、来源、操作结果、发起操作的用户、操作的资源以及请求/响应的详细信息等)。通过审计日志，可以追溯对集群状态的变更;了解集群的运行状况;排查异常;发现集群潜在的安全、性能风险等等。包括不限于如下行为：

　　当前/历史上集群发生了哪些变更事件。

　　这些变更操作者是谁，是系统组件还是用户，是哪个系统组件/用户。

　　重要变更事件的详细内容是什么，比如修改了POD中的哪个参数。

　　事件的结果是什么，成功还是失败。

　　操作用户来自哪里，集群内还是集群外。

　　Kubernetes Event

　　事件(Event)主要是用来记录K8s集群内发生的状态变更，大到集群节点异常，小到 Pod 启动、调度成功等。事件详细记录了集群状态变更发生的时间、组件、等级(Normal、Warning、Error)、类型、详细信息，通过事件能够知道应用的部署、调度、运行、停止等整个生命周期，也能通过事件去了解系统中正在发生的一些异常。

　　K8s事件存储在etcd中，默认情况下只保存1个小时，由于etcd并不支持一些复杂的分析操作，只提供了非常简单的过滤方式，比如通过Reason、时间、类型等。同时这些事件只是被动的存在etcd中，并不支持主动推送到其他系统，通常只能手动的去查看。而实际上我们对事件的使用需求非常高，比较典型的场景如下：

　　对系统中的异常事件做实时告警，例如Failed、Evicted、FailedMount、FailedScheduling等。

　　通常问题排查可能要去查找历史数据，因此需要去查询更长时间范围的事件(几天甚至几个月)。

　　事件支持归类统计，例如能够计算事件发生的趋势以及与上一时间段(昨天/上周/发布前)对比，以便基于统计指标进行判断和决策。

　　支持不同的人员按照各种维度去做过滤、筛选。

　　支持自定义的订阅这些事件去做自定义的监控，以便和公司内部的部署运维平台集成。

　　默认情况下，Kubernetes事件只关注容器管理相关的问题，对于硬件、操作系统、容器运行时、依赖系统(网络、存储等)并不会提供更多的检测能力。NPD(node-problem-detector)作为Kubernetes节点诊断的工具，可以将节点的异常转换为Node的事件，并推送到APIServer中，交由APIServer进行事件的统一管理。NPD支持多种异常检查，例如：

　　基础服务问题：NTP服务未启动。

　　硬件问题：CPU、内存、磁盘、网卡损坏Kernel问题：Kernel hang，文件系统损坏。

　　容器运行时问题：Docker hang，Docker无法启动。

　　之后，可以借助开源事件工具kube-eventer，将集群的事件离线到钉钉、SLS、Kafka等系统，并提供不同等级的过滤条件，实现事件的实时采集、定向告警、异步归档。

　　Ingress

　　K8s中Ingress只是一种API资源的声明，具体的实现需要安装对应的Ingress Controller，由Ingress Controller接管Ingress定义，将流量转发到对应的Service。目前Ingress Controller有非常多种实现，常用的的是Nginx Ingress Controller。

　　日志和监控是所有Ingress Controller都会提供的基础功能，日志一般包括访问日志(Access Log)、控制日志(Controller Log)和错误日志(Error Log)，监控主要从日志以及Controller中提取部分Metric信息。这些数据中访问日志的量级最大、信息最多、价值也最高，一般7层的访问日志包括：URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等，对于Ingress Controller这种转发型的日志，还包括转发的Service名、Service响应时间等额外信息。从这些信息中，我们能够分析出非常多的信息，例如：

　　网站访问的PV、UV;

　　访问的地域分布、设备端分布;

　　网站访问的错误比例;

　　后端服务的响应延迟;

　　不同URL访问分布。

　　K8s 配置安全

　　CIS Kubernetes Benchmark是CIS推出的一系列用于构建一个安全可靠的Kubernetes集群的安全配置建议，K8s使用者可以基于这些规范构建安全的K8s集群。但是人工一个个去比对安全配置规则的建议显然是不合适的，一般会结合一些巡检工具进行。

　　security-inspector是一款针对K8s Workload配置进行多维度扫描工具，可以在巡检报告中查看巡检扫描结果，包括健康检查、镜像、网络、资源、安全等扫描信息。此外，kube-bench、kube-hunter等其他开源项目也是可选用的CIS规则巡检方案。

　　K8s 运行时安全

　　Falco是一款云原生运行时安全开源项目，用于监控Kubernetes上应用的运行时异常活动。Falco在内核态通过监控文件更改、网络活动、进程表和其他数据是否存在可疑行为，并可以通过可插拔后端发送警报。

　　通过 Falco 可轻松检测以下异常：

　　容器内运行的 Shell

　　服务器进程产生意外类型的子进程

　　敏感文件读取(如 /etc/shadow)

　　非设备文件写入至 /dev

　　系统的标准二进制文件(如 ls)产生出站流量

　　K8s 安全数据源特点

　　以上我们列举了一些K8s安全监控场景下常见的数据源，而且每种日志特点各异。我们可以发现安全类数据种类繁多，来源众多，格式也不统一。总结下来具有如下特点：

　　安全数据类型包含了日志、指标、事件。

　　安全数据可能是来自文件，也有可能来自标准输出或者标准错误，甚至可能是Syslog等标准协议。

　　安全文本数据可能会存在于容器内的文件或者宿主机上的文件。

　　Ingress访问日志等涉及数据面流量的日志往往会数据量极大。

　　审计日志作为集群安全审计的必备日志，重要性极高，需要长时间跨度存储(等保2.0要求至少需要存180天)，并且不能有采集的丢失。

　　为了更全面的采集安全数据，需要具备一个性能强大、生态支持全面、K8s原生支持的安全数据采集器。该采集器需要具备以下能力：

　　容器运行时支持的全面性，可以支持Docker、Containerd等运行时。

　　K8s提供了强大的动态扩缩容能力，但也同时给数据采集带了困难。因此，采集器需要适应容器动态的特点。

　　有些安全数据是通过Job触发的，该类任务具有生命周期短的特点，采集器需要提供短生命周期容器的采集能力。

　　所采集需要具备关联K8s上下文的能力，为后续分析提供便捷。

　　强大的数据处理能力，可以在不影响性能的前提下完成安全数据的处理需求，为后续分析场景打下基础。

　　K8s云上托管服务越来越流行，需要能够支持云上服务的采集场景。

　　K8s 采集技术

　　阿里云SLS开源的可观测数据采集器iLogtail，可以完全满足上述安全数据的特点及场景要求，并且经过阿里双十一、公有云等众多复杂场景考验，在安全数据采集领域也是一个很好的选择。接下来，我们重点介绍下iLogtail的技术特点及K8s下的采集原理。

　　可观测数据采集器 iLogtail

　　iLogtail的核心定位是可观测数据的采集器，帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景。2022年6月底，阿里云iLogtail代码完整开源，正式发布了完整功能的iLogtail社区版。

　　iLogtail 核心优势

　　轻量级、高性能

　　iLogtail主体部分通过C++，插件部分Golang实现，不管内存还是CPU具有天然的性能优势。

　　iLogtail也持续针对性的做了很多特定场景的优化，比如针对日志的极简、Json、正则模式采集提供了C++加速能力，极大提升了日志采集效率，单核采集流量最高能到百M/s。

　　超强可靠性

　　iLogtail作为阿里集团内重要的可观测数据采集基础设施，多年来一直稳定支持双11等大促场景，在应对网络拥塞、流量洪峰、进程重启等方面表现突出。

　　公有云上iLogtail也持续支持着各行各业的客户，众多复杂业务场景对于iLogtail的可靠性提供了足够的场景支持。

　　毫秒级延时

　　iLogtail实现如此高吞吐的秘诀之一是使用了无锁化事件处理模型。与业界其他开源Agent为每个配置分配独立线程/Goroutine读取数据不同，iLogtail数据的读取只配置了一个线程。由于数据读取的瓶颈并不在于计算而是磁盘，单线程足以完成所有配置的事件处理以及数据读取。使用单线程使得iLogtail的事件处理和数据读取都可以在无锁环境下运行，数据结构更加轻量化，从而取得了相对多线程处理更优的性价比。

　　文件采集基于inotify与polling相结合的发现机制，既借助了inotify的低延迟与低性能消耗的特点，也通过polling的方式兼顾了运行环境的全面性。

　　云原生支持

　　iLogtail提供了业务容器实时动态发现能力，并支持通过K8s元信息(例如Label、环境变量等)进行采集过滤。特别是一些短Job场景，比如一些机器学习的训练任务，生命周期只有几分钟甚至几十秒，也提供了全面的友好的支持。

　　部署模式上，也支持DaemonsSet、Sidecar等多种模式。

　　为了更原生的K8s支持，也提供了Operator机制，用户可以通过CRD的方式进行采集配置管理。

　　插件化扩展能力

　　上下游生态：通过插件系统的扩展，目前iLogtail已经支持了众多数据源的接入，数据源类型覆盖Log、Metric、Trace，数据源除了文件的采集，还包括了标准协议的支持，例如HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。数据输出生态也从SLS逐步扩展到Kafka、gPRC等，未来也会支持ClickHouse、ElasticSearch等。

　　处理能力扩展：iLogtail采用PipeLine的设计，通过Input插件采集到数据，会经过采集配置中设定的Processor处理，之后经过Aggregator插件打包，最终通过Flusher发送到日志存储系统。数据处理环境包含数据切分、字段提取、过滤、数据增强等环节，所有插件可以自由组合。此外，针对于正则、Json、分隔符等特定格式，iLogtail还提供了C++加速能力。

　　快速迭代：开发者也可以根据自己的需求，定制开发相应的插件。因为每个插件相互独立，所以开发者只需要按照接口规范开发即可，入手门槛较低。

　　多租户隔离

　　iLogtail采用基于时间片的采集调度、多级高低水位反馈队列、事件非阻塞处理、流控/停采策略以及配置动态更新等多项关键技术，融合实现了兼具隔离性、公平性、可靠性、可控性、性价比五大特性的多租户隔离方案。

　　iLogtail 部署模式

　　作为容器编排领域的标准，Kubernetes(K8s)应用的场景越来越广泛，iLogtail 在K8s下也提供了完备的采集能力。在K8s场景下，iLogtail主要常用的有3种工作模式：

　　DaemonSet方式：在K8s的每个node上部署一个iLogtail，由该iLogtail采集节点上所有容器的日志到日志系统。此方式特点是运维简单、资源占用少、支持采集容器的标准输出和文本文件、配置方式灵活，但是在超大集群存在一定的性能瓶颈。

　　Sidecar方式：一个POD中伴随业务容器运行一个iLogtail容器，用于采集该POD中业务容器产生的日志。此方式特点是多租户隔离性好、性能好，但是资源占用较多。

　　Deployment方式：当业务容器用PVC挂载日志目录或者需要全局连接API Server获取K8s元数据等场景，可以选择在集群中部署一个单副本的iLogtail Deployment进行数据采集。

　　iLogtail 采集原理

　　自K8s问世以来，Docker运行时一直是主流，但是随着K8s将dockershim移除，K8s官方推荐优先选择Containerd 或 CRI-O作为容器运行时。Docker份额目前虽然还是主流但是已经在呈逐年下降的趋势，Containerd、CRI-O地位逐年都在快速上升。因此，从K8s支持全面性上，iLogtail需要支持主流的运行时，目前已经支持Docker和Containerd两种容器引擎的数据采集。

　　K8s提供了强大的运维部署、弹性伸缩、故障恢复能力，极大地便利了分布式系统的开发和管理，然而这也带来了可观测数据采集难度的增大。特别是一些短Job场景，比如一些机器学习的训练任务，生命周期只有几分钟甚至几秒，如何快速准确地发现所需要采集的容器至关重要。iLogtail在K8s场景下的采集分为如下几个步骤：

　　容器自动发现与释放：iLogtail通过访问位于宿主机上容器运行时(Docker Engine/ContainerD)的sock获取容器信息，并通过监听Docker Event及增量获取机制，及时感知容器新增与释放。

　　容器上下文信息获取：包括容器层级信息，例如容器名、ID、挂载点、环境变量、Label;以及K8s层级信息，例如Pod、命名空间、Labels。

　　容器过滤及隔离性：基于容器上下文信息，提供采集容器过滤能力，可以将不同采集配置应用到不同的采集容器上，既可以保证采集的隔离性，也可以减少不必要的资源浪费。

　　元信息关联：基于容器上下文信息和容器环境变量，提供在日志中富化K8s元信息的能力。

　　采集路径发现：根据容器元信息自动识别不同运行时的标准输出格式和日志路径;对于overlay、overlay2的存储驱动，可以根据日志类型及容器运行时自动拼接出采集路径，简单高效。

　　此外，对于CICD自动化部署和运维程度要求较高的用户，iLogtail还提供了K8s原生支持，支持通过CRD的方式进行采集配置管理。目前该功能仅企业版可用，后续会逐步开源。该方案中，iLogtail K8s新增了一个CustomResourceDefinition扩展，名为AliyunLogConfig。同时开发了alibaba-log-controller用于监听AliyunLogConfig事件并自动创建iLogtail的采集配置，进而完成日志采集工作。

　　安全数据监测与响应最佳实践

　　统一存储分析引擎

　　安全数据监控一个重要的能力就是对采集到的数据，进行实时的合规监控分析，支持对历史数据的合规审计，对来自外部的威胁和内部的违规进行审计分析。实际安全分析场景往往会面临众多困难：

　　安全威胁往往是一个逐步的过程，可能需要几个月或更长的时间才会真正暴露出来。因此，需要提供低成本的存储能力，及强大的长时间跨度数据分析能力。

　　安全数据来源众多，格式不统一，日志、时序数据都可能涉及。有些安全威胁隐蔽性较强，需要多种数据的联动分析才能发现。因此，需要具备强大的关联分析能力。

　　为此，我们设计了一套统一的可观测数据存储分析引擎。将日志、指标、Meta等数据全部接入到统一的存储中，在一些等保场景可以通过开启智能冷热分层存储，降低不活跃数据的存储成本。之后，我们构建了一套统一的查询分析引擎，该引擎以SQL为基础，扩展了关键词查询、PromQL语法能力及机器学习算子能力，可方便支撑查询分析、可视化、监控告警、AI 等上层应用场景。同时，SQL作为顶层语言，可以起到串联日志、时序、ML模型、CMDB、外部DB的能力，使得大规模多数据关联分析成为可能。

　　可以认为，SLS SQL = Search + SQL92(Agg，WIndow，GroupBy...)+ PromQL + ...

　　以下就是一个比较典型的分析的例子：

　　我们可以通过标准 SQL 语句对日志进行分析。

　　还可以通过 PromQL 扩展的 SQL 函数对指标数据进行分析。

　　还可以通过嵌套查询，对指标数据的分析结果进行再聚合。

　　此外还可以再通过机器学习函数，给查询和分析赋予 AI 的能力。

　　虽然不同阶段的数据产生自不同的系统，也有着不同的格式，但是由于它们的存储和分析是一致的，我们可以非常轻松地实现统一的安全态势及安全事件监控。

　　智能巡检

　　Ingress访问日志产生量极大，而且日积月累后会造成大量数据存储，会造成存储成本的急剧上升，并且在长时间跨度查询分析场景下也会效率极低。

　　为了达到高性能、低成本、快速、智能等要求，我们对Ingress这种超大数据量的方案进行了架构升级。

　　原始访问日志存储：当Ingress Controller产生访问请求后，会实时将请求的访问日志推送到用户自身的日志库中，SLS的Logstore具备高可靠、实时索引、自动扩容等功能，保证日志的可靠性和可扩展性。

　　预聚和：由于原始访问日志量巨大，基于原始日志计算指标性能开销较大，因此我们专门推出了基于访问日志的指标预聚和能力，能够将上百万甚至上亿的访问日志实时聚合成指标类型的时序数据，数据量会降低1-2个数量级，后续的分析与监控可直接基于时序数据进行，大大提高效率。

　　智能巡检：对于预聚和后的Metrics(指标数据)，我们提供了基于机器学习的智能巡检功能，帮助用户自动去检测Ingress的各个维度的指标异常，将异常信息实时展现在时序的图表中，结合实时告警能力及时通知给用户解决。此外后续还会支持异常打标，基于用户反馈的信息进行更加精确的检测。

　　通过以上3层数据链路，实现了从原始访问日志到预聚和的指标最后再到机器学习的异常事件整个数据的流转，对于用户来说，告警和监控只需要基于指标和智能巡检的结果进行，而涉及到具体服务的问题分析可以再回到原始的访问日志并基于统一查询分析引擎进行自定义的排查和分析。

　　成本高、查询效率低：对于日志量极大场景，特别如果再加上长时间跨度的因素，会造成存储成本的急剧上升，查询效率往往也很低。

　　效率低：对于异常现场的定位，需要人工配置各种各样的规则去进行异常的捕获。

　　时效差：大部分时序数据具有时效性特征。故障、变更都会引起对应指标形态的变化，前一种规则条件下的异常可能在下一时刻是正常状态。

　　配置难：时序数据形态各异。有突刺变化、折点变化、周期变化等诸多形态，阈值范围也各有不同。对于复杂形态下的异常，规则往往难以配置。

　　效果差：数据流不断动态变化，业务形态日新月异，固定的规则方法很难在新的业态下起作用，从而产生大量的误报或者漏报。对于异常的程度，不同场景，不同用户，对其容忍的程度不同。在排查问题中，有效异常点捕捉的越多，有助于具体问题的排查;而在告警通知中，高危异常点越少，越有助于提升告警处理的效率。

　　针对以上问题，我们推出智能巡检功能，通过自研的人工智能算法，对指标、日志等流数据进行一站式整合、巡检与告警。使用智能巡检功能后，只需要组织一下具体的监控项，算法模型就会自动完成异常检测、业态自适应、告警精细。

　　安全态势

　　我们提供了安全态势大盘，帮助用户全局了解安全事件、安全态势，便于进行告警链路查看及排错使用。此外，报表还可自由扩展。例如审计日志、Ingress中心等大盘，可以清楚的展现K8s集群的控制面、数据面访问情况，包括统计、趋势、地域等;事件中心可以展现集群内的一些异常活动，例如POD OOM、节点重启等。

　　告警与 On-Call 机制

　　通过上文提到的统一的数据采集能力、统一的存储及查询分析能力，我们可以做到对安全威胁的基本探测能力。但是要构建完备的监控体系，接下来就要解决如何持续监控的问题。为此，我们开发了一套一站式智能运维告警系统。它提供对日志、时序等各类数据的告警监控，告警模版化扩展能力，亦可接受三方告警，对告警进行降噪、事件管理、通知管理等。

　　我们也针对K8s下一些典型安全场景的历史经验，提供了众多内置告警规则，开箱即用并持续增加中。这些规则库有覆盖了CIS和安全场景的最佳实践，用户仅需开启对应规则，即可享受到全天候的安全保障。

　　当告警规则探测到异常发生时，需要尽快的将威胁事件通知给相应的开发人员。我们对接了丰富的通知渠道，便于威胁事件的全方位触达。

　　多渠道：支持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道，同时还支持通过自定义 Webhook 进行扩展。同一个告警，支持同时通过多个渠道、每个渠道使用不同的通知内容进行发送。例如通过语音和钉钉来进行告警通知，既可以保证触达强度，又可以保证通知内容的丰富程度。

　　动态通知：可以根据告警属性动态分派通知。例如：测试环境的告警，通过短信通知到张三，并且只在工作时间通知;而生产环境的告警，通过电话通知到张三和李四，并且无论何时，都要进行通知。

　　通知升级：长时间未解决的告警要进行升级。例如某告警触发后，通过短信通知到了某员工，但是该问题长时间未被处理，导致告警一直没有恢复，此时需要通知升级，通过语音的方式通知到该员工的领导。

　　安全事件发生后，如果不及时处理或不慎遗漏都会造成更大的安全风险扩展。因此，一定要建立完备的反馈机制，将安全问题处理形成闭环。基于这个问题，我们提供了安全事件管理中心，便于用户全局查看安全事件，并进行相应的管理动作。当开发或安全人员接收到安全告警事件通知后，可以登陆安全事件管理中心进行事件的确认、处理人的指派、处理动作记录等操作。

　　基于云原生可观测平台构建 K8s 下的 SecOps 能力

　　综上，我们可以基于阿里云SLS搭建一个功能完备的K8s安全监控体系。整体分为四个层次：

　　数据采集层：主要提供安全数据接入能力。其中以iLogtail为最主要的数据采集方式(支持前置的数据处理能力)，并且同时支持API方式，兼容众多标准协议，例如OpenTelemetry、Prometheus、Syslog、Kafka等。

　　统一存储分析层：提供了针对Logs、Metric、Trace、安全事件、Topo等多种数据的存储层，并且在此基础上提供了统一的数据关联分析能力。对于不规则数据，提供了数据加工能力。

　　智能服务：基于智能告警服务，可以实现安全场景的持续监控及通知响应能力;智能算法服务提供了智能巡检功能可以扩展智能巡检、分析的能力。

　　上层应用：基于上述三层可以打造属于用户自己的SecOps应用。当然对于ITOps、DevOps、BussinessOPS也是不错的选择。