容器安全基础知识： 工作量

如果你刚刚开始阅读本系列，你可能想从头开始： 
容器安全基础知识： 介绍
容器安全基础知识： 管道
容器安全基础知识： 编排

工作负载是一个相当新的术语，通常用于描述applications，但也可以指基础设施服务。 这很重要，因为您的容器集群中可能运行着各种各样的“工作负载”，而这些工作负载不一定来自您的开发人员。 在容器环境中，免费和开源服务用于各种用途的使用正在增长。 整个 IT 运营领域确实如此，IT 运营是过去一年免费和开源软件下载量最大的类别。

因此，当我们说工作负载安全时，我们的意思是您下载、开发或部署到容器环境中的任何软件。 想想领事。 想想Kubernetes本身。 想想Prometheus和Elasticsearch 。 想想NGINX和istio 。

然后还将您部署的任何 API 网关、缓存和入口控制器放入该列表中，以支持您的 Kubernetes 环境。 这就是为什么一份详尽的物料清单很重要，以及为什么定期盘点对于维护安全的环境至关重要。

一旦你有了列表，就该解决关键的工作负载安全问题了。

• 1. 身份验证不是可选的
  如果您一直在关注整个系列，那么这对您来说就是老生常谈了。 这是集装箱安全各个方面的共同主题之一：锁上前门。
  
  所有这些服务都作为工作负载在集群中运行。 这通常意味着用于访问 API 和数据的默认凭证或“开放”初始配置。 工作负载安全包括应用功能和运行所需的所有组件、软件和应用服务。 
  
  

• 2. 恶意内容是恶意的
  即使您通过要求提供凭证和应用访问控制锁上了门，您仍然需要担心恶意内容。 对于正在使用的applications、微服务和运营服务来说，情况都是如此。 所有向用户（无论是操作员还是消费者）提供界面的工作负载都存在潜在风险。

  这是必须进行扫描和操作的地方。 第一步是查找应用层的漏洞（无论是 HTTP 还是应用逻辑）。 一旦找到了它们，就该采取措施来解决它们了。 如果它是一个定制的应用程序，请将其发回开发部门。 如果是第三方组件，请确定是否存在修补/升级版本。 第三方组件通常以容器镜像的形式交付，正如Snyk 在其 2019 年开源安全状况报告中指出的那样，其中 44% 的组件存在已知漏洞，而针对这些漏洞，已有更新、更安全的基础镜像可用。
  
  让我们再说一遍：如果您不采取补救措施，运行扫描对于提高安全性毫无作用。
  
  如果您家的墙上有一个洞，让窃贼可以轻易绕过上锁的门，那么您就应该把洞补好。 因此，修补虚拟墙上的虚拟洞吧。
  
  当开发人员无法立即解决漏洞或第三方提供商尚未解决漏洞时，使用 Web应用防火墙或 API 安全网关可以提供一种补救手段。
  
  这最好概括为“筛选你的电话”，因为它是在接受任何工作负载之前检查和评估其请求。
  
  
• 3. 共享资源意味着共享风险
  与传统虚拟化一样，容器并不是完全隔离的。 容器最终共享相同的物理操作系统。 这意味着共享操作系统中的漏洞意味着共享漏洞。

如果攻击者能够利用操作系统组件中的漏洞，他们就可以危害一个或多个工作负载。 这些漏洞可能会由于未能“锁门”或“筛选电话”而暴露。 这不是一个牵强的场景，正如我们在CVE-2019-5736中看到的那样，其中操作系统层的 runc 漏洞导致互联网陷入恐慌。 

这里的核心安全原则是由 SELinux 和 RedHat 容器安全专家 Dan Walsh 提出的： “容器不包含” 。 

值得注意的是，所有与节点外部服务和用户相关的网络流量都必须经过主机操作系统。 节点上的 pod 和容器之间的网络是通过虚拟网桥的虚拟网络和巧妙使用 iptables 来实现的。 但最终，流量必须离开该物理节点，这意味着在主机操作系统上进行处理。 代理、插件和其他守护进程可能会出于安全或可见性目的观察或捕获该流量。 这些都是潜在的危害点，在阅读有关管道安全性的文章后，您应该将其添加到您开始编制的清单中。

• 4. 记录敏感细节
  您可能没有想到有关容器安全的讨论会包含有关日志的警告。 但事实确实如此，原因是有时敏感信息会出现在日志文件中。 授权令牌、加密提供商密钥、凭证。 所有内容都可能被stderr上的工作负载无意中记录或显示。 这通常是由于需要追踪因身份验证错误而导致的问题。 一般来说，您应该阻止（如果可以的话，禁止）将秘密记录到系统中。
  
  为了帮助确保开发人员意识到这种风险，请考虑提供日志设计指南并指定可以写入日志的内容和不可以写入日志的内容。

容器环境中的大部分工作负载安全性与生产环境中运行的任何其他应用工作负载的安全性相同。 控制访问并要求强身份验证，注意恶意内容，并注意共享和平台级别的漏洞。