Kubernetes审计：使日志审计再次成为可行的实践

之前由Nitzan Niv在Alcide博客上发表

在安全领域，识别系统被破坏、滥用或错误配置的最成熟方法之一，是收集系统用户和自动化服务执行的所有活动的日志，并分析这些日志。

作为安全最佳实践的审计日志

一般来说，审计日志有两种用途：

1. 主动地识别不合规行为。根据一组已配置的规则，它应该忠实地过滤对组织策略的任何违反，调查人员在审计日志条目中发现，证明发生了不符合的活动。使用自动过滤器，此类警报的集合将定期报告给遵从性调查人员。
2. 被动地对特定的操作或安全问题进行调查。通过事后调查，将已知的问题追溯到责任方、根本原因或促成因素，从而推断出状态与引起行为和先前状态之间的关联。

Kubernetes审计日志

让我们研究一下如何在Kubernetes世界中配置和使用审计日志，它们包含哪些有价值的信息，以及如何利用它们来增强基于Kubernetes的数据中心的安全性。

Kubernetes审计日志的目的，是使集群管理员能够以取证的方式恢复服务器的状态和导致Kubernetes API中数据的当前状态的一系列客户机交互。

在技术术语中，Kubernetes审计日志是对Kubernetes API-Server的每个调用的详细描述。Kubernetes组件向外界暴露Kubernetes API。它是Kubernetes集群中所有用户、自动化和组件访问的中心接触点。API服务器通过HTTP实现RESTful API并执行所有API操作。

当接收到一个请求时，API服务器通过以下几个步骤来处理它：

1. 身份验证：建立与请求（又称主体）相关联的身份。有几种身份验证机制。
2. RBAC/授权：API服务器确定与请求关联的标识是否可以访问请求中的谓词和HTTP路径的组合。如果请求的标识具有适当的角色，则允许继续处理。
3. 准入控制：确定请求是否格式良好，并可能在处理请求之前对其进行修改。
4. 验证：确保请求中包含的特定资源是有效的。
5. 执行请求的操作。支持的操作类型包括：
   1. 创建资源（例如pod、命名空间、用户角色）
   2. 删除资源或资源集合
   3. 列出特定类型的资源（例如，pod、命名空间），或者获得特定资源的详细描述
   4. 打开到API服务器的长时间运行的连接，并通过它连接到特定的资源。然后使用这样的连接在用户和资源之间传输数据。例如，这使用户能够在运行的pod中打开远程shell，或连续查看在pod中运行的应用程序的日志。
   5. 监视集群资源的更改。

请求及其处理步骤可以存储在Kubernetes审计日志中。可以将API服务器配置为存储所有或部分请求，并提供不同程度的详细信息。此审计策略配置还可以指定审计日志存储在何处。分析工具可以通过这个钩子请求接收这些日志。

审计Kubernetes集群的挑战

虽然审计日志收集和分析的原则自然适用于云，特别是构建在Kubernetes上的数据中心，但在实践中，这种环境的规模、动态特性和隐含的上下文使得分析审计日志变得困难、耗时和昂贵。

集群中活动的规模意味着，任何仅依赖手工检查成千上万个每日日志条目的分析都是不切实际的。“安静”集群没有人类触发行动，没有重大变化应用活动，仍然是每小时处理成千上万的API调用，由内部Kubernetes机制生成，确保集群是活的，根据指定的部署，利用其资源和失败会自动识别并恢复。即使使用日志过滤工具，审核员也需要大量的经验、直觉和时间来放大一些有趣的条目。

Kubernetes集群这样的系统的动态特性，意味着工作负载正在快速地添加、删除或修改。这不是审核员专注于访问包含数据库的几个特定工作负载的问题，而是确定在审核时间段的每个特定时刻哪些工作负载包含敏感数据库的问题，以及哪些用户和角色有合理的理由访问每个数据库 这些数据库工作负载在什么时间等等。

此外，虽然找到一些有趣的结果只是在日志中查找预先已知的与不良活动相关的特定条目，但是在日志中查找可疑但先前未知的活动需要一套不同的工具和技能，尤其是在这种可疑行为只能在很长一段时间内从更广泛的上下文中理解，而不仅仅是一个或两个相关的日志条目。例如，检测用户未能向系统进行身份验证非常简单，因为每次登录尝试都显示为单个日志条目。然而，识别潜在的盗窃用户凭证只能检测到，如果审计员连接看似不同的条目到一个整体的模式，例如访问系统使用特定用户的凭证从一个组织以外的未知的互联网地址，而使用了相同的用户的凭证并发从内部组织的网络访问系统。

使日志审计再次成为可行的实践

为了使大型、复杂的Kubernetes集群的审计成为一种可行的实践，我们需要使审计员的工具适应这种环境。这些工具将自动和主动地识别异常和有问题的行为，特别是在Kubernetes控制安全的情况下，以便：

1. 检测与安全相关的Kubernetes集群滥用，特别是那些只能通过观察多个活动的扩展上下文来检测的行为。
2. 将遵从性调查集中在Kubernetes的误用上，这些误用超出了简单日志过滤规则的检测范围。

当然，为了实现这些目标，这样的工具必须能够：

1. 自动分析Kubernetes审计日志，检测用户和自动服务帐户的异常行为和对敏感资源的异常访问。
2. 总结检测到的异常以及审计信息的重要趋势和统计数据，以方便用户理解。在一天结束时，审核员应该有足够的信息，使她能够理解、限定或忽略自动分析的结果。

让我们描述一些更复杂的威胁场景，我们希望预想的审计日志分析仪自动检测：

• 对手可能会窃取特定用户或服务帐户（在集群之外）的凭据，或者通过社会工程在侦察过程中更早地捕获凭据，从而获得对集群资源的初始访问权。
• 对手可以使用令牌盗窃（在集群内，从被破坏的或合法访问的资源）或令牌模拟不同的用户或服务帐户（即安全上下文）执行横向移动、权限升级、数据访问和数据操作的操作，同时避免检测。
• 对手可能使用不充分或配置错误的RBAC在自己的安全上下文中获得对特权和敏感资源（集群的秘密、配置映射、授权策略等）的访问权限，用于横向移动、特权升级、数据访问和数据操作。
• 对手可能会利用Kubernetes API服务器中的漏洞（身份验证、授权、准入控制或验证请求处理阶段）来获得对特权和敏感资源（集群的秘密、配置映射、授权策略等）的访问，以便进行初始访问、横向移动、特权升级、数据访问和数据操作。

显然，这种场景的检测远远不止使用预先确定的规则对审计日志进行简单的过滤。必须使用复杂的机器学习算法来自动地、大规模地和在实际威胁活动之后的合理时间内实现这一点。

分析工具应该收集日志中显示的集群的操作和安全活动的特征，并将它们提供给机器学习算法进行测量、加权和链接。在这个过程的最后，可疑行为的可能模式可以提交给审核员进行验证和进一步的调查。

总结

对系统日志的审计是一种成熟的实践，用于识别对系统的安全威胁，无论这些威胁在实现之后是否会产生有害影响。事实上，某些形式的定期审计是法律和规章规定的。

然而，在复杂、大规模、动态系统（如现代的Kubernetes集群）的审计日志中识别可疑模式是一项艰巨的任务。虽然使用某种类型的自动化对于这样的分析是强制性的，但是大多数现有的审计工具只是一些不需要动脑筋的过滤器，很难帮助审计员应对其任务的更深层的挑战。

在本文中，我们提出了一个自动化Kubernetes审计日志分析工具的设想，它远远超出了这个范围。使用机器学习，这样的工具可以自动检测审计员可以关注的日志中的潜在威胁模式，甚至是实时的。此外，以用户可理解的方式汇总审计日志中的信息可以让审计员快速验证已识别的模式，并帮助她调查其他隐藏的可疑活动。