零信任策略下K8s安全监控最佳实践（K+）

作者 |  徐可甲(烨陌) ,,传统的网络安全架构理念是基于边界的安全架构，企业构建网络安全体系时，首先要做的是寻找安全边界，把网络划分为外网、内网等不同的区域，然后在边界上部署防火墙、入侵检测、WAF等产品。然而这种网络安全架构是基于内网比外网更安全的假设建立起来，在某种程度上预设了对内网中的人、设备和系统的信任，忽视加强内网安全措施。不法分子一旦突破企业的边界安全防护进入内网，会像进入无人之境，将带来严重的后果。此外，内部人员100%安全的假说也是不成立的，我们可以从《内部威胁成本全球报告》里看到，不管是内部威胁的数量，还是威胁成本都是呈显著上升的趋势。,随着云计算、大数据、物联网、移动办公等新技术与业务的深度融合，网络安全边界也逐渐变得更加模糊，传统边界安全防护理念面临巨大挑战。以办公网络安全为例，已经逐步从仅支持公司内部网络设备连接，发展到使用办公电脑通过VPN远程连接，甚至移动办公的到来，使得个人手机等个人设备接入变成了可能。在这样的背景下，零信任架构（Zero Trust Architecture, ZTA）应运而生。它打破传统的认证，即信任边界防护、静态访问控制、以网络为中心等防护思路，建立起一套以身份为中心，以持续认证、动态访问控制、审计以及监测为链条，以最小化实时授权为核心，以多维信任算法为基础，认证达末端的动态安全架构。,我们知道Kubernetes在容器编排市场中占据了主导地位，用户基数呈逐年上升的趋势。K8s提供了强大的运维部署、弹性伸缩、故障恢复能力，极大地便利了分布式系统的开发和管理，但是随之而来的安全问题却也比较突出。,,根据《容器和Kubernetes安全态势报告》报告，针对云原生应用的威胁已越来越多，仅有6%的人没有经历过与容器或K8s相关的安全事件。同时，还指出近70%的安全风险都是由人为错误配置而引发的，此外运行时安全及重大安全漏洞引发的安全事件也是重要的因素。《中国云原生用户调查报告》同样也支持，容器安全问题成为用户应用的最大担忧。63%的用户认为容器安全是紧迫的需求，大量用户反馈网络安全技术实施难度复杂度高，且监控系统、日志系统不完善，很难进行有效的安全监控。,从上述的报告可以看出，K8s安全问题会分布在整个生命周期的各个阶段。一些常见的安全风险表现为：容器镜像漏洞或滥用镜像仓库导致的漏洞；容器大量部署导致很难发觉安全问题；K8s核心组件漏洞威胁，多个高危漏洞爆出；集群配置不当，甚至一些默认配置有安全隐患；没有明确网络边界，网络隔离性问题；攻击面变大、监控和防护难度大。因此，我们迫切需要建立一个全方位的安全体系，覆盖整个容器生命周期的各个阶段。,,上图为阿里云容器服务Kubernetes版给出的安全体系，可以看出构建完善的安全体系从下到上需要覆盖基础架构安全、可信软件供应链、运行时安全三个维度。,我们发现上述安全体系可以跟零信任策略的“从不信任、始终验证”的思想相呼应的。,,为了更好的理解K8s系统的安全风险，接下来我们从K8s内外部网络边界的角度展开分析。其中，红色曲线部分可以被视为独立边界的子系统。,,K8s安全攻击来源众多，既可能是来自外部的控制平面攻击，也可能是来自外部流量的数据面攻击，甚至可能是来自内部成员的恶意攻击或者误操作等。因此，K8s攻击面特别广，防护难度大，为了更好的保护K8s安全运行，需要建议起一套策略防护跟监控防护相结合的防护体系。本文重点将围绕监控防护展开，逐层递进地介绍如何在复杂的分布式容器化环境中借助可观测性平台，持续监控K8s集群，及时发现异常的 API 访问事件、异常流量、异常配置、异常日志等行为，并且结合合理的告警策略建立更主动的安全防御体系。,安全数据是作为K8s安全监控的根本，如果没有数据那就是“巧妇难为无米之炊”，任何高级的监控策略都无从谈起。因此，首先我们将会介绍K8s相关的安全数据源及相关的采集技术。,K8s审计日志,在 Kubernetes 中，Api Server是K8s集群资源变更、查询的入口，所有对集群状态的查询和修改都是通过向 Api Server 发送请求，对 Api Server 的请求来源可以分为4类：,,Kubernetes 审计日志是 Api Server 产生的结构化日志，记录了对 Api Server 的访问操作（包括时间、来源、操作结果、发起操作的用户、操作的资源以及请求/响应的详细信息等）。通过审计日志，可以追溯对集群状态的变更；了解集群的运行状况；排查异常；发现集群潜在的安全、性能风险等等。包括不限于如下行为：,Kubernetes Event,事件（Event）主要是用来记录K8s集群内发生的状态变更，大到集群节点异常，小到 Pod 启动、调度成功等。事件详细记录了集群状态变更发生的时间、组件、等级（Normal、Warning、Error）、类型、详细信息，通过事件能够知道应用的部署、调度、运行、停止等整个生命周期，也能通过事件去了解系统中正在发生的一些异常。K8s事件存储在etcd中，默认情况下只保存1个小时，由于etcd并不支持一些复杂的分析操作，只提供了非常简单的过滤方式，比如通过Reason、时间、类型等。同时这些事件只是被动的存在etcd中，并不支持主动推送到其他系统，通常只能手动的去查看。而实际上我们对事件的使用需求非常高，比较典型的场景如下：,支持自定义的订阅这些事件去做自定义的监控，以便和公司内部的部署运维平台集成。,,默认情况下，Kubernetes事件只关注容器管理相关的问题，对于硬件、操作系统、容器运行时、依赖系统（网络、存储等）并不会提供更多的检测能力。NPD（node-problem-detector）作为Kubernetes节点诊断的工具，可以将节点的异常转换为Node的事件，并推送到APIServer中，交由APIServer进行事件的统一管理。NPD支持多种异常检查，例如：,之后，可以借助开源事件工具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响应时间等额外信息。从这些信息中，我们能够分析出非常多的信息，例如：,K8s配置安全,,CIS Kubernetes Benchmark是CIS推出的一系列用于构建一个安全可靠的Kubernetes集群的安全配置建议，K8s使用者可以基于这些规范构建安全的K8s集群。但是人工一个个去比对安全配置规则的建议显然是不合适的，一般会结合一些巡检工具进行。,,security-inspector是一款针对K8s Workload配置进行多维度扫描工具，可以在巡检报告中查看巡检扫描结果，包括健康检查、镜像、网络、资源、安全等扫描信息。此外，kube-bench、kube-hunter等其他开源项目也是可选用的CIS规则巡检方案。,K8s运行时安全,,Falco是一款云原生运行时安全开源项目，用于监控Kubernetes上应用的运行时异常活动。Falco在内核态通过监控文件更改、网络活动、进程表和其他数据是否存在可疑行为，并可以通过可插拔后端发送警报。通过 Falco 可轻松检测以下异常：,K8s安全数据源特点,以上我们列举了一些K8s安全监控场景下常见的数据源，而且每种日志特点各异。我们可以发现安全类数据种类繁多，来源众多，格式也不统一。总结下来具有如下特点：,为了更全面的采集安全数据，需要具备一个性能强大、生态支持全面、K8s原生支持的安全数据采集器。该采集器需要具备以下能力：,阿里云SLS开源的可观测数据采集器iLogtail，可以完全满足上述安全数据的特点及场景要求，并且经过阿里双十一、公有云等众多复杂场景考验，在安全数据采集领域也是一个很好的选择。接下来，我们重点介绍下iLogtail的技术特点及K8s下的采集原理。,可观测数据采集器iLogtail,iLogtail的核心定位是可观测数据的采集器，帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景。2022年6月底，阿里云iLogtail代码完整开源，正式发布了完整功能的iLogtail社区版。,,iLogtail核心优势,,轻量级、高性能,超强可靠性,毫秒级延时,云原生支持,插件化扩展能力,上下游生态：通过插件系统的扩展，目前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部署模式,作为容器编排领域的标准，Kubernetes（K8s）应用的场景越来越广泛，iLogtail 在K8s下也提供了完备的采集能力。在K8s场景下，iLogtail主要常用的有3种工作模式：,,,iLogtail采集原理,自K8s问世以来，Docker运行时一直是主流，但是随着K8s将dockershim移除，K8s官方推荐优先选择Containerd 或 CRI-O作为容器运行时。Docker份额目前虽然还是主流但是已经在呈逐年下降的趋势，Containerd、CRI-O地位逐年都在快速上升。因此，从K8s支持全面性上，iLogtail需要支持主流的运行时，目前已经支持Docker和Containerd两种容器引擎的数据采集。,,K8s提供了强大的运维部署、弹性伸缩、故障恢复能力，极大地便利了分布式系统的开发和管理，然而这也带来了可观测数据采集难度的增大。特别是一些短Job场景，比如一些机器学习的训练任务，生命周期只有几分钟甚至几秒，如何快速准确地发现所需要采集的容器至关重要。iLogtail在K8s场景下的采集分为如下几个步骤：,此外，对于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 + ...以下就是一个比较典型的分析的例子：,虽然不同阶段的数据产生自不同的系统，也有着不同的格式，但是由于它们的存储和分析是一致的，我们可以非常轻松地实现统一的安全态势及安全事件监控。,,
,,Ingress访问日志产生量极大，而且日积月累后会造成大量数据存储，会造成存储成本的急剧上升，并且在长时间跨度查询分析场景下也会效率极低。为了达到高性能、低成本、快速、智能等要求，我们对Ingress这种超大数据量的方案进行了架构升级。,通过以上3层数据链路，实现了从原始访问日志到预聚和的指标最后再到机器学习的异常事件整个数据的流转，对于用户来说，告警和监控只需要基于指标和智能巡检的结果进行，而涉及到具体服务的问题分析可以再回到原始的访问日志并基于统一查询分析引擎进行自定义的排查和分析。,针对以上问题，我们推出智能巡检功能，通过自研的人工智能算法，对指标、日志等流数据进行一站式整合、巡检与告警。使用智能巡检功能后，只需要组织一下具体的监控项，算法模型就会自动完成异常检测、业态自适应、告警精细。,我们提供了安全态势大盘，帮助用户全局了解安全事件、安全态势，便于进行告警链路查看及排错使用。此外，报表还可自由扩展。例如审计日志、Ingress中心等大盘，可以清楚的展现K8s集群的控制面、数据面访问情况，包括统计、趋势、地域等；事件中心可以展现集群内的一些异常活动，例如POD OOM、节点重启等。,,
,通过上文提到的统一的数据采集能力、统一的存储及查询分析能力，我们可以做到对安全威胁的基本探测能力。但是要构建完备的监控体系，接下来就要解决如何持续监控的问题。为此，我们开发了一套一站式智能运维告警系统。它提供对日志、时序等各类数据的告警监控，告警模版化扩展能力，亦可接受三方告警，对告警进行降噪、事件管理、通知管理等。我们也针对K8s下一些典型安全场景的历史经验，提供了众多内置告警规则，开箱即用并持续增加中。这些规则库有覆盖了CIS和安全场景的最佳实践，用户仅需开启对应规则，即可享受到全天候的安全保障。,,当告警规则探测到异常发生时，需要尽快的将威胁事件通知给相应的开发人员。我们对接了丰富的通知渠道，便于威胁事件的全方位触达。,,安全事件发生后，如果不及时处理或不慎遗漏都会造成更大的安全风险扩展。因此，一定要建立完备的反馈机制，将安全问题处理形成闭环。基于这个问题，我们提供了安全事件管理中心，便于用户全局查看安全事件，并进行相应的管理动作。当开发或安全人员接收到安全告警事件通知后，可以登陆安全事件管理中心进行事件的确认、处理人的指派、处理动作记录等操作。,综上，我们可以基于阿里云SLS搭建一个功能完备的K8s安全监控体系。整体分为四个层次：,,未来已来，K8s安全监控体系未来将朝着生态化、轻量化、智能化、一体化的方向继续发展，为企业安全保驾护航。,,iLogtail作为阿里云SLS提供的可观测数据采集器，可以运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据（日志、监控、Trace、事件等），已经有千万级的安装量。目前，iLogtail已正式开源，欢迎使用及参与共建。,GitHub: https://github.com/alibaba/ilogtail,社区版文档：https://ilogtail.gitbook.io/ilogtail-docs/about/readme,企业版官网：https://help.aliyun.com/document_detail/65018.html