云原生的生命周期由四个连续的阶段组成，分别是开发、分发、部署和运行时，上次《云原生正在统治世界：却成为了安全的梦魇？》详细讲解了开发、分发、部署三个阶段的安全建设，本文将重点介绍在运行时阶段，云原生的安全挑战及解决方案。
云原生运行时环境安全防护全景图
运行时阶段包括三个关键领域：计算、存储和访问。尽管运行时环境取决于开发、分发和部署阶段的成功完成，但是运行时的安全性取决于先前各阶段安全实践的有效性。下文详细介绍了每个关键领域的安全要求及其意义。
>>计算
云原生计算是一个非常复杂且不断发展的结构。若没有核心组件来提高计算利用率，组织机构将无法确保工作负载的安全性。
从容器云多租户角度考虑，使用容器专用的操作系统非常重要。通常，容器专用操作系统是一个只读操作系统，禁用了其他服务，使用这种OS有助于减少攻击面，还提供了独立性和资源限制，让开发人员能够在共享主机内核上运行独立的应用。为了实现深度防御，还建议不要在相同的OS内核上运行不同的数据敏感度的工作负载。
为了保障容器平台和服务所有层的安全，可以使用基于可信平台模块（TPM）或 vTPM 的硬件信任根。可以将源于硬件的信任链扩展到 OS 内核及其组件，以对可信启动、系统镜像、容器运行时和容器镜像等进行加密验证。
1.编排
对于任何编排工具而言，由于存在多种威胁，使用最佳实践和配置加固以防止遭受威胁是很重要的。监控和检测在运行时阶段对初始配置所做的任何更改对于确保集群的持续安全状态也很重要。其他安全的最佳实践，如最大限度地降低对控制层的管理访问权限、职责划分和最小权限原则，均应予以执行。
①资源请求和限制
通过 cgroup进行系统资源使用的限制，有助于防止由于加密货币挖矿这样恶意行为，导致工作负载出现问题，耗尽节点和集群资源。
②日志审计分析
日志审计分析是识别和关联系统入侵、滥用或配置错误的最成熟的方法之一。自动化的日志分析和关联对于安全团队而言至关重要。因为与传统系统相比，云原生架构能够为工作负载生成更细粒度的审计配置和过滤功能。此外，通过云原生日志的互操作性，可以进行高级过滤，防止下游处理中的过载问题。与传统的日志分析一样，此处至关重要的是生成可操作的审计事件，将日志中的数据关联起来形成上下文，形成事件响应“信息”。
③身份验证和信任根证书
除了加固现有控制平面之外，编排工具管理人员还应配置所有编排工具控制平面组件，如控制器——管理器、调度器、API服务器和kubelet，以便通过定期轮换的证书完成相互认证和证书验证，进行通信。发出命令的CA可以是默认编排工具CA或外部CA。管理人员应特别注意保护CA的私钥。
2.容器
①运行时环境
需要从进程、文件和网络的角度监控和保护容器的运行时环境。主机操作系统只应允许在容器中执行或调用经过批准的功能和系统调用（例如seccomp过滤器）。应监控并阻止对关键挂载点和文件的变更。必须通过配置防止更改二进制文件、证书和远程访问配置。还必须通过配置阻止容器的出入网络访问，只访问需要操作的内容。此外，应检测并拒绝恶意域名的网络流量。
在云原生运行时，青藤蜂巢可以做到工作负载清点与可视化；并使用微隔离对容器的网络访问进行控制，可以进行事件应急，发生问题之后，可以采用隔离方式阻止威胁进一步扩散；还会持续进行入侵检测和响应，针对运行时的入侵行为进行检测和发现，提供响应处理方式。青藤蜂巢遵循“持续监控&响应”原则，真正做到完全自适应，保证云原生运行时环境安全。
②微服务架构
以微服务架构部署的容器化应用，其边界即微服务本身。因此，有必要定义好策略，限制仅经认证的微服务之间方可进行通信。在微服务架构中纳入零信任，则可以在微服务架构被入侵时，通过防止横向移动来减小影响范围。运维人员应确保他们正在使用诸如网络策略之类的功能，以确保容器部署内的东西网络通信仅限于授权访问的范围。NIST SP 800-204文件为微服务安全提供了一些策略，已经做了一些初步工作，并且可以作为实现安全微服务体系结构的指南。
③镜像信任和内容保护
利用策略代理来强制执行或控制已签名授权的容器镜像，这样组织机构便能够保证工作负载的镜像来源。此外，引入加密容器可以保护容器内存在的敏感源、方法或数据。
3.服务网格
服务网格将各项服务连接起来，以此实现流量控制、服务发现、负载平衡、弹性、可观测性、安全性等。服务网格能够让微服务架构从应用库中卸载这些功能，并让开发人员能够专注于区分业务逻辑。为了有效地确保云原生环境中各服务之间的安全通信，组织机构应执行服务网格以消除其Pod内部和不同工作负载之间通过动态数据加密实现的绝对信任。使用服务网格还解决了身份问题，其中，传统的第3层和第4层身份（即IP地址）不再明确地映射到工作负载。服务网格不仅提供网络级别的独立性和安全性，而且还提供网络级别的弹性功能，例如，重试、超时和实现各种断路功能。值得注意的是，服务网格的执行可以有助于减少云原生部署的攻击面，并提供用于构建零信任应用网络的关键框架。
4.运行时阶段的检测
工作负载在部署之时或之后将变得易受攻击。组织机构应不断扫描其环境，以检测哪些工作负载易受攻击。了解每个工作负载的组成或构成清单有助于组织机构快速确定漏洞的位置。有关这些漏洞的其他信息，例如，漏洞利用成熟度和使用时易受攻击的路径，对于确定工作负载的实际风险至关重要，并且可以帮助组织机构对有风险的应用进行优先更新。
5.函数
无服务器函数易受到各种攻击，因此，需要得到适当的保护。进程必须只能执行在允许列表中明确定义的函数。此外，不允许函数更改关键文件系统的挂载点。
这些函数必须具有限制条件，仅允许通过网络限制或权限模型中的最小权限来访问已批准的服务。此外，出口网络连接必须由管理人员进行监控，以检测并阻止（在可能的情况下）对C＆C（命令和控制）和其他恶意网络域的访问。还必须考虑进行入口网络检查，以检测和删除可在数据渗出中使用的恶意载荷和命令。例如，可以通过检查来检测SQL注入攻击。
无服务器函数有多种威胁，而可供租户使用的控件是有限的。其中一些问题，如身份验证失效和API与相关服务的集成不安全。确保所有无服务器函数都在基于租户的资源中运行，或者通过性能隔离对类似的数据分类可能有助于解决此问题，但是，由于隔离环境可用的地址空间有限，它们可能会对性能产生影响。
>>存储
云原生存储涵盖很多技术，包括两类存储方式，一类是可用于工作负载（例如数据卷）的存储，包括块存储、文件系统和共享文件系统；另一类是访问存储，可通过应用 API 访问，包括对象存储、键值存储和数据库。
1.存储堆栈
任何存储解决方案都由多层功能组成，这些功能定义了如何存储、检索、保护数据以及数据如何与应用、编排工具或操作系统进行交互。每层功能都有可能影响存储系统的安全性。一个常见的示例是，通过一个文件系统将文件或块持久保存到对象存储中。保护拓扑结构中的每一层都同等重要，而不仅仅是访问数据的顶层。
2.存储加密
存储系统可以提供通过数据加密来确保数据密钥性的方法。可以对传输中的数据或静态数据执行数据加密，并且在存储系统中使用数据加密时，可以确保单独对应用实现加密功能。
加密可能会影响性能，因为它隐含了计算开销，但是许多系统上都提供了加速选项，可以减少开销。在为数据选择加密类型时，请考虑数据路径、大小和访问频率，以及可能需要使用更安全算法的任何规定或其他安全保护。此外，团队在考虑其架构的加密需求时，不应忽略使用缓存。
3.持久卷保护
数据卷存取保护对于确保仅授权的容器和工作负载可以利用所提供的数据卷至关重要。必须为命名空间定义信任边界，以限制对数据卷的访问。利用现有安全策略或创建新的安全策略，防止容器组访问工作节点上的数据卷挂载，并确保只有适当的工作节点才能访问数据卷。这一点尤其重要，因为特权容器可以访问其他名称空间中挂载的数据卷，所以需要采取额外的预防措施。
为数据卷指定UID或GID后，同一名称空间内的容器仍可以访问，但不提供数据保护。在执行保护时，必须考虑在何处进行身份验证和授权，以及是否存在对该操作进行确认，这一点至关重要。
4.工件存储库
存储库应提供用于签署和验证OCI工件的技术。还有一点很重要，要确保缓存和分发工具也提供签名、加密功能和校验码功能，进而确保缓存层可以检测到篡改或破坏数据集的行为。
>>访问
1.身份和访问管理
云原生架构的综合性身份和访问管理（IAM）解决方案至少应包括服务身份。维护或运营本地私有云或混合云的组织机构需要用户和设备身份管理。对于跨多云环境分布的应用和工作负载，身份联合对于IAM的成功执行至关重要。
身份验证和授权必须在环境内和整个环境中各自确定（决策点）并强制实施（实施点）。理想情况下，应实时地确认所有工作负载的安全操作，并在可能的情况下验证更新的访问控制和文件权限，因为可能通过缓存实现未经授权的访问（如果访问被吊销且从未经过验证）。根据已为工作负载分配的属性和角色/权限对工作负载进行授权。强烈建议组织机构同时使用基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC）在所有环境以及整个工作负载生命周期中提供细粒度的授权执行。这种做法可以实现纵深防御，其中所有工作负载都可以接受、使用和转发最终用户的身份以进行上下文或动态授权。这可以通过使用身份证明文件和令牌得以实现。若不强制执行此操作，组织机构对系统到系统以及服务到服务的调用执行最小权限访问控制的能力就会受到限制。
2.凭证管理
①硬件安全模块（HSM）
只要有可能，读者应尽可能使用诸如HSM之类的技术，通过加密密钥对加密密钥进行物理保护，因为加密密钥永远不会离开HSM保护边界。如果无法做到这一点，则应使用基于软件的凭证管理器。
②凭证管理周期
加密密钥应在HSM或基于软件的密钥管理系统中安全生成。
密钥的有效期限或存在时间应尽可能短，有效期过后失效。密钥管理应该是高度可用的，且易于生成，因为这些特征是密钥保持短暂性的前提。但是，如果组织机构使用的是使用期长的密钥，则应建立适当的流程和指南进行定期轮换或撤销（但不建议这样做），特别是在偶然泄露密钥的情况下。所有密钥必须通过安全的信道在传输过程中进行分发，并应根据其所保护的访问或数据级别进行相应的保护。
不管怎样，应在运行时通过非持久性机制将密钥信息注入工作负载中，这些机制可以防止通过日志、审计或系统转储（即内存中共享的数据卷而非环境变量）而造成密钥泄漏。
3.可用性
云原生应用环境下的拒绝服务攻击（DoS攻击）是指一类网络攻击。攻击者试图让云原生应用暂时或长期无法供其目标用户（人工或自动化）使用。攻击者可以通过破坏关键的云原生应用组件（例如微服务架构），破坏负责保持微服务架构运行的编排层或破坏负责应用扩容的运行状况监控系统来实现攻击。DoS通常是通过向关键微服务架构或资源注入过多的请求来使系统超负荷工作，并阻止某些或所有合法请求实现攻击。
分布式拒绝服务攻击（DDoS攻击）通常涉及大量传入流量，这些流量会对云原生应用服务或其所依赖的上游网络造成洪泛攻击。通常情况下，攻击的来源各不相同。在攻击到达云原生应用之前对其进行检测和分流，可以缓解大部分攻击。
（责任编辑:郭健东）