在本文中，我们将讨论各种可遵循和实施的容器安全优秀实践与工具，以降低容器化工作负载的各项安全风险。

众所周知，网络安全事件会对一个组织的声誉、以及市场竞争力造成严重的影响，甚至可能导致由最终用户发起的诉讼、以及各种不必要的法律纠纷。根据IBM的一份调查报告，全球范围内的各个组织平均每次由数据泄露所带来的总体成本约为392万美元。通常，一个组织会因为如下方面的疏漏，而拉低整体的安全态势：

  • 缺乏安全管理工具和实践的技能和培训

  • 缺乏风险的可见性和漏洞的发现机制

  • 未能持续监控当前系统与服务的安全状态

而根据PaloAlto Networks最近的一份《云安全状况调查报告》表明，有94%的组织正在使用着一个或多个云平台，并且其中有大约45%的计算会发生在他们容器或CaaS(容器即服务)上。随着应用容器的主导地位的逐步攀升，由此引发的安全威胁也在不断增加。同时，该报告也罗列出了如下八大主要安全威胁：

  • 由恶意软件引发的数据泄露

  • 应用程序的代码级漏洞

  • 系统身份验证组件的薄弱或被破坏

  • 应用的配置错误

  • 不正确的访问或权限过高

  • 源自内部的威胁

  • 身份认证凭据的泄漏

  • 不安全的端点

针对上述威胁，我们将在下面和您讨论一些有关容器安全性的优秀实践。您可以通过遵循并实施，来降低容器化工作负载中的各种安全风险，进而实现对于应用程序的保护。

1. 来自受信存储库的基于源代码的镜像

当我们创建容器镜像时，通常会依赖那些来自流行的、私有的或公共注册表的种子镜像。不过请注意，在镜像制作的供应链中，有人可能会渗透进去，并植入能够为攻击者打开“大门”的恶意代码。例如，在2018年，一些黑客曾攻击了英国航空公司的软件供应链。他们将恶意的JavaScript代码插入英国航空公司的Web应用程序之中。具体请参见链接--https://www.wired.com/story/british-airways-hack-details/。同样，就在几年前，Docker在其Docker Hub上也发现了一些被安装了Cryptominers(加密货币挖矿软件)的镜像。

因此，您需要在如下方面引起足够的重视：

  • 在创建容器镜像时，请使用来自知名可信发布者的、经过安全加固的基础性镜像源。

  • 请选择那些经常被更新的、带有最新安全修复和补丁的镜像。

  • 请使用那些经过签名和标记的镜像，并在拉取的过程中验证镜像的真实性，以阻断中间人攻击。

2. 安装经过验证的包

出于同样的原因，我们也需要保障被安装在基础镜像上的软件包，也源自经过验证和受信任的来源。

3. 最小化镜像中的攻击面

我们常说应用的受攻击面与镜像中已安装的软件包和库的数量有关。通常，如果此类对象的数量较少，那么出现漏洞的机率也就越低。可见，我们应当在满足应用程序运行时的基本要求的前提下，尽可能地保持镜像的体积最小。理想状况下，我们最好在一个应用程序容器中，仅保留一个应用程序。同时，您可以从如下方面入手：

  • 删除不必要的工具和软件，包括：包管理器(如，yum和apt)、网络工具、客户端、以及镜像中的shell和netcat(可用于创建反向的shell)等。

  • 使用多阶段(multi-stage)的Dockerfile，并从生产环境的镜像中删除各个用于软件构建的组件。

  • 为了减少威胁，请不要在容器中暴露不必要的网络端口、套接字、以及运行不需要的服务(如SSH的守护程序等)。

  • 与其选用带有完整操作系统的镜像，不如选择alpine镜像、临时镜像或专为容器优化了的操作系统。

4.不要在镜像中留存信任凭据

所有的信任凭据都应该“远离”镜像和Dockerfile。包括SSL证书、密码、令牌、以及API密钥在内的各种机密信息，都应当被保存在外部，并通过容器编排引擎、或外部密钥管理器，进行安全地挂载。目前，Hashicorp Vault工具，由AWS Secrets Manager、Kubernetes Secrets、Docker Secrets Management、以及CyberArk等提供的云端密钥管理服务，都可以改善您在此方面的安全态势。

5. 使用安全的私有或公共注册表

企业通常拥有自己的基础镜像，其中包含了各种他们不想公开分发的专有软件库。为了确保镜像能够被托管在安全且受信的注册表处，以防止未经授权的访问，请使用具有可信根CA的TLS证书，并实施强身份验证，以防范MITM(中间人)攻击。

6.不要使用特权或root用户，在容器中运行应用程序

这是容器化工作负载中最常见的配置错误。请牢记最低权限原则，创建一个应用程序的专用用户，并使用它在容器内运行应用程序的对应进程。您也许会问为何不能用root用户呢?其原因是：除了通过其带有的额外元数据，来识别是否为容器的一部分，在容器中运行的进程，与在主机操作系统上运行的进程十分相似。而一旦容器中的root用户有了UID和GID，那么它可以访问、甚至修改其在宿主机上的文件。

注意，如果您没有在Dockerfile中定义任何USER的话，那么容器就会以root用户运行。

7. 在CI/CD中实施镜像漏洞扫描

在为容器的构建和交付设计CI/CD时，请包含一个镜像扫描方法，以识别那些由CVE公布到的知名漏洞。同时，请不要在没有修复的情况下，部署任何可用的镜像。常见的漏洞扫描工具包括：Clair、Synk、Anchore、AquaSec、Twistlock等。同时，AWS ECR和Quay.io等容器注册表也需要配备各种相应的扫描方案。

8. 启用AppArmor等内核安全配置文件

AppArmor是一个Linux安全模块，可被用于保护操作系统、及其应用程序免受各种安全威胁。Docker通过提供默认配置文件的方式，允许程序访问诸如：网络访问、内核功能、文件权限等有限的资源。该方法不但减少了潜在的攻击面，而且提供了很好的深度防御。

9. 安全集中式的远程日志记录

通常，容器将所有内容记录到标准输出--STDOUT上。显然，这些日志会因为中断而丢失。因此，我们需要将日志安全地、以传输流的方式集中到一处，以供未来的审计和按需取证。当然，我们需要确保此类日志系统的安全性，以免敏感数据信息从日志中泄漏出去。

10. 部署运行时(Runtime)的安全监控

前面给出的九项安全建议，只是最大限度地减少了安全威胁，并不能完全阻止攻击的发生。对此，我们仍然需要通过持续监控和记录应用程序的行为，来及时检测并发现任何可疑或恶意的活动。同时，我们还可以实施分层防御，对不同的监控范围，部署不同的审计与容器保护工具。

可用于安全控制的开源工具

常言道：“工欲善其事，必先利其器”。为了简化上述针对容器的安全加固，我在此为您罗列了如下六大开源和商业工具，以方便您按需采用：

  • Docker-bench-security– 属于Docker的官方工具。作为由CIS Benchmark针对Docker提出的行业标准，它可以被用于审计容器的各种工作负载。

  • Hadolint Linter for Dockerfile – 可以使用linter对Dockerfile进行静态代码分析。作为一种优秀实践，linter可与各种流行的代码编辑器和集成管道相整合。

  • Clair – 是一种流行的应用容器静态漏洞扫描工具。它会定期从各种漏洞数据库中获取元数据。其同类工具包括：Anchore、Synk、以及Trivy。

  • OWASP Cheatsheet– 该漏洞备忘录来自备受安全专家欢迎的开放社区--OWASP。

  • OpenSCAP for Container– SCAP(Security Content Automation Protocol，安全内容自动化协议)是一个多用途的规范框架，可以支持自动化配置、漏洞和补丁检查、技术控制的合规活动与安全测量等。它执行的是NIST各项标准。

  • Sysdig Falco– 随着黑客的持续进步和新漏洞的不断涌现，静态扫描工具已显得力不从心。我们需要能够持续进行行为监控、以及基于AI/ML的高级引擎。而作为一种可用于实现运行时安全性的工具，Falco使用高效的eBPF去拦截各种调用与流量，并能实时进行监控和取证。

此外，您还可以选用AquaSec、Twistlock、Sysdig、Synk、以及Qualys等企业级安全工具和商业产品。

希望上述各种解决方案能够真正为您抵御黑客攻击，协助您及时发现当前系统中的异常状态，以及为您的容器负载提供合理化的改进建议。

译者介绍

陈峻 (Julian Chen)，51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式，分享前沿技术与新知;经常以线上、线下等方式，开展信息安全类培训与授课。

原文标题：Top 10 Ways To Secure Containers，作者：Anjul Sahu