来自StackRox高级软件工程师Connor Gorman的客座文章
与容器生态系统的成熟同时出现的还有Kubernetes,它是运行容器化应用程序编排器的实际标准。这种新的声明式和不可变的工作负载设计,为检测和响应的全新操作模型铺平了道路。
Kubernetes丰富的工作负载元数据集增强并提升了传统的检测方法,比如异常检测。在Kubernetes,异常检测由观察应用程序的正常行为,学习应用程序的典型行为,在学习阶段创建一个活动基线,然后基于基线测量未来事件,包括文件的读和写、网络请求和流程执行。任何明显超出正常基线的都可以被认为是异常的,以进行调查。
传统VM基础设施中的异常检测
传统虚拟机(VM)基础设施中异常检测的挑战,在于需要更多的专业知识来进行调优,而且更容易出现误报。这是因为VM的操作方式。VM运行一个完整的操作系统;为了平摊运行操作系统的成本,几个核心应用程序通常在每个操作系统中运行。在这样的基础设施中,随着可能的活动范围的显著扩大,正确地进行异常检测意味着创建依赖于机器学习的复杂模型和算法。你的工作就是大海捞针,而使用虚拟机,大海捞针的规模就大得多了。
容器和Kubernetes中的异常检测
与VM相比,容器是轻量级的,通常运行单个应用程序,该应用程序通常由单个进程组成。这种形式因素与Kubernetes的声明式相结合,通过为每个正在运行的应用程序提供上下文,提高了异常检测的效率。
下图强调了为什么创建利用声明式信息的活动基线比单独建模运行时数据更有效。运行时之下的每个项由开发人员或操作人员显式设置,并构成异常检测的约束。
镜像
镜像所遵循的不变性原则,为创建活动基线提供了基础。通过定义安装在应用程序特定版本中的二进制文件和包,检测变得非常简单。Dockerfile是由应用程序开发人员创建的所需应用程序依赖项的清单。由于容器不需要支持完整的操作系统,因此与VM相比,此架构依赖于一组小得多的包和二进制文件。通过减少应用程序的已知二进制文件和包的数量,开发团队可以更容易地验证,是否只执行预先存在的二进制文件。这种方法可以捕获恶意参与者插入二进制文件并执行它们作攻击。
你应该做什么:
Pod规范
PodSpecs允许开发人员通过定义他们的安全上下文(分配特权、Linux功能、以及文件系统是否是只读的)来为他们的Pod定下规则。这些配置缩小了Pod的活动范围,并指定了基线中不需要在运行时进行推断的方面。例如,尝试在带有只读文件系统的Pod上进行有效负载删除和执行将被拒绝,并且会引发检测系统中的异常。相比之下,在VM基础设施中,这些严格的控制是不可行的,因为主机上的每个应用程序都需要兼容这种类型的更改。
你应该做什么:
网络规范
类似于防火墙,但是在一个更细粒度的层次上,Kubernetes网络策略使开发人员能够根据Pods和IP子网描述所需的入口/出口。这种转变至关重要。微服务环境中的开发人员对他们的应用程序的网络交互有很好的理解,并且可以仅对已知的依赖项进行访问。Kubernetes在应用程序到应用程序的通信中抽象出IP地址,并提供诸如命名空间和标签之类的逻辑分段结构。仔细定义的L3/L4分段通过缩小要分析的网络活动来增强异常检测。
你应该做什么:
不让坏人靠近
Kubernetes和容器为开发人员和操作人员创建了一个独特的机会来显式地声明应用程序应该运行的环境。在传统的VM基础结构中,很难有效地定义应用程序的活动。另外,通过使用单一应用程序容器,用户可以定义最小的权限集,并利用Kubernetes提供围绕服务到服务交互的高级抽象。这些细粒度的控制可以通过确定哪些行为是恶意的,哪些是良性的,并突出显示违反用户策略的活动,从而增强异常检测。因此,应用程序的攻击面要小得多,从而降低了一个糟糕的参与者在基础设施中获得立足点的可能性。
相关资源
Kubernetes安全的九个最佳实践
Kubernetes配置的12个最佳实践
Kubernetes安全101
Docker容器安全101
https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/
https://www.stackrox.com/post/2019/09/12-kubernetes-configuration-best-practices/
https://www.stackrox.com/post/2019/07/kubernetes-security-101/
https://www.stackrox.com/post/2019/09/docker-security-101/