云原生日志审计

云原生日志审计

网络安全的审计是指按照一定的安全策略，利用记录、系统活动和用户活动等信息，检查、审查和检验操作事件的环境及活动，从而发现系统漏洞、入侵行为或改善系统性能的过程。

作为安全审计的重要数据来源，日志展现的是系统和应用运行产生的事件或者程序在执行的过程中产生的一些记录，可以详细解释系统的运行状态。日志描述了一些离散的、不连续的事件，对于应用程序的可见性是很好的信息来源，日志同样也为应用程序分析提供了精确的数据源。

对于云原生架构下的日志审计与分析，其面临的挑战主要包括两个层面，一方面是日志审计本身面临的挑战。

日志存储分散。企业IT系统中的各种网络设备、安全设备、应用系统等分散在网络的不同位置，安全审计人员须通过不同的方式，查看设备/应用产生的日志、设备/应用的状态。

日志数据量大。企业IT系统中的各种网络设备、安全设备、应用系统等每天会产生大量的日志，安全审计人员很难通过人工的手段进行集中存储管理以及有效分析。

日志格式不统一。企业IT系统中的各种网络设备、安全设备、应用系统等不同的设备类型产生的日志格式都不相同，安全审计人员须了解每种设备/应用日志的格式才有可能分析日志，日志分析成本很大。

另一方面，针对云原生环境以及云原生应用的特性，其平台、网络以及应用在架构和行为上较传统IT系统都有着更大的复杂性。因此，相比较传统的日志审计，云原生架构下的日志审计面临的挑战将会更大。

Docker日志审计

Docker支持多种日志记录机制，用以帮助用户从正在运行的容器和服务中获取信息，这种机制被称为日志驱动程序。Docker从1.6版本开始支持日志驱动，用户可以将日志直接从容器输出到如syslogd这样的日志系统中。每个Docker守护进程都有一个默认的日志驱动程序，通常这个默认的日志驱动是json-file，也就是以JSON文件的形式保存日志信息。同时Docker还支持其他日志驱动，比如none、syslog、gelf和fluentd等。

Kubernetes日志审计

另外，对于单个节点上的日志记录，还需要重点考虑日志的轮转（rotation）问题，保证日志记录不会消耗掉节点上的全部可用空间。Kubernetes本身并不负责轮转日志，而是通过部署相关的日志工具来解决这个问题。

集群级的日志架构需要一个独立的后端，用来存储、分析和查询日志。Kubernetes当前并不为日志数据提供原生的存储解决方案，不过，有很多现成的日志方案可以集成到Kubernetes中。Kubernetes针对Pod提供了基本的日志记录，我们使用kubectl logs即可通过标准输出打印相关的日志记录。

Kubernetes系统组件的日志同样需要有一定的方案来记录和存储。系统组件日志主要记录了集群中发生的事件，这对于调试以及安全审计有着重要的作用。系统组件日志可以根据需要配置日志的粒度，灵活调整日志记录的细节程度。日志可以是只粗粒度地显示组件内的错误，也可以是更加细粒度的，如记录事件的每一个追踪步骤（HTTP访问日志、Pod状态更新、控制器操作、调度器决策等）。

Kubernetes默认使用的日志库是klog，它专门用来做日志初始化的相关操作，klog是glog的fork版本。当前，支持Kubernetes的日志管理工具种类也比较多，如Zebrium、ElasticStack、CloudWatch、Fluentd等，这些日志管理工具都有着一个共同的目标，那就是可以尽可能高效、快速地进行日志监控、记录以及分析处理。

日志实现了对系统和应用行为的记录，对云原生可观测性的实现起到了重要的作用。我们可以通过日志系统获取系统以及应用的详细操作数据，是云原生可观测性重要的数据来源。