容器安全基础：工作负载

如果您刚开始阅读本系列，建议从头开始：
容器安全基础：简介
容器安全基础：流水线
容器安全基础：编排

“工作负载”是一个较新的术语，通常用于描述应用，但也可以指基础设施服务。这一点很重要，因为容器集群中可能运行着各种“工作负载”，而它们不一定来自开发人员。为实现各种用途，容器环境正越来越多地采用免费开源服务。事实上，整个IT运维领域也是如此；过去一年，IT运维是免费开源软件下载量最高的类别。

因此，我们所说的工作负载安全，是指下载、开发或部署到容器环境中的任何软件。例如，Consul、Kubernetes本身、Prometheus和Elasticsearch，以及NGINX和istio。

此外，还应将为支持Kubernetes环境而部署的所有API网关、缓存和入口控制器纳入清单。因此，一份详尽的物料清单至关重要，而定期盘点则是维护安全环境的关键。

列出清单后，就该着手解决关键的工作负载安全问题了。

• 1. 身份验证必不可少
  如果您一直在关注本系列内容，对此应该已经很熟悉了。这是容器安全各个方面的共同主题之一：守好入口。
  
  所有这些服务都以工作负载的形式在集群中运行。这通常意味着使用默认凭据，或采用可直接访问API和数据的“开放式”初始配置。工作负载安全涵盖实现应用功能和运行所需的所有组件、软件和应用服务。
  
  
• 2. 恶意内容始终具有危害性
  即使已经通过要求提供凭据和实施访问控制来锁好大门，仍需防范恶意内容。正在使用的应用、微服务和运维服务都是如此。所有向用户（无论是运维人员还是消费者）提供接口的工作负载都可能面临风险。因此，必须进行扫描并采取行动。第一步是发现应用层中的漏洞，无论是HTTP漏洞还是应用逻辑漏洞。发现漏洞后，就要着手处理。如果是自定义应用，应将其交回开发团队修复。如果是第三方组件，应确定是否有已修补或升级的版本。第三方组件通常通过容器镜像交付；正如Snyk在其《2019年开源安全状况报告》中所指出的，其中44%存在已知漏洞，而且已有更新、更安全的基础镜像可供使用。
  
  再强调一次：如果不修复漏洞，仅运行扫描并不能提升安全性。
  
  如果墙上有个洞，让潜在窃贼可以轻易绕过锁好的门，您一定会把洞补上。同样，也要修补虚拟墙上的虚拟漏洞。
  
  如果开发人员无法立即修复漏洞，或第三方提供商尚未解决漏洞，可以使用Web应用防火墙或API安全网关进行缓解。
  
  简而言之，就是“筛查来电”：在接受发往任何工作负载的请求之前，先对其进行检查和评估。
  
  
• 3. 共享资源意味着共同承担风险
  与传统虚拟化一样，容器并非完全隔离。容器最终共享同一个物理操作系统。这意味着，共享操作系统中的漏洞会影响所有共享该系统的容器。

如果攻击者能够利用操作系统组件中的漏洞，就可能攻陷一个或多个工作负载。未能“锁好门”或“筛查来电”，可能会导致这些漏洞暴露。这种情况并非危言耸听，正如我们在CVE-2019-5736事件中所见，操作系统层的一个runc漏洞曾引发整个互联网的恐慌。

这里的核心安全原则由SELinux和RedHat容器安全专家Dan Walsh提出并广为人知：“容器并不能实现隔离”。

需要注意的是，与节点外部服务和用户之间的所有网络流量都必须经过主机操作系统。节点上的Pod和容器之间通过虚拟网络进行通信，其中使用了虚拟网桥，并巧妙运用了iptables。但流量最终必须离开该物理节点，这意味着需要由主机操作系统处理。代理、插件和其他守护进程可能会出于安全或可观测性目的监控或捕获这些流量。这些都是潜在的入侵点，应将其添加到阅读流水线安全后开始编制的清单中。

• 4. 记录敏感信息
  您可能没想到，讨论容器安全时还需要提醒日志相关风险。之所以需要，是因为敏感信息有时会被写入日志文件，例如授权令牌、加密提供程序密钥和凭据。这些信息都可能被工作负载意外记录或显示在stderr中。这通常是因为需要排查身份验证错误导致的问题。一般而言，应避免将机密信息记录到系统中，并尽可能禁止这种做法。
  
  为帮助开发人员了解这一风险，可考虑提供日志记录设计指南，明确哪些内容可以写入日志，哪些不可以。

容器环境中的工作负载安全在很大程度上与生产环境中运行的其他应用工作负载安全相同。应控制访问并要求进行强身份验证，监测恶意内容，同时留意共享组件和平台层面的漏洞。