云原生架构新风险与需求概述
安全风险概述
传统的网络安全架构理念是基于边界的安全架构，企业构建网络安全体系时，首先要做的是寻找安全边界，把网络划分为外网、内网等不同的区域，然后在边界上部署防火墙、入侵检测、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 审计日志
