10个确保微服务与容器安全的最佳实践

作者 | Anna Bryk 市场研究专家

原文 | Microservices and Container Security: 10 Best Practices

翻译 | BoCloud博云

容器使微服务在开发人员中很受欢迎，因为微服务具有快速部署、服务独立性增强等优点，使得现在许多公司开始接受微服务。然而，从单体架构迁移到微服务架构也会引发许多问题，其中安全问题最为重要。

用于单体应用程序的传统安全 工具 并不能用于保护微服务和容器。基于微服务架构的应用程序包含数千个容器，这极大地扩大了攻击范围。将容器视为服务单元大大降低了应用程序的透明性和可审计性。

这些安全问题引发了关于这种软件开发新方法到底是“解决问题”更多，还是“制造问题”更多的激烈争论。那么，我们如何将安全性引入应用程序的同时，又不损失使用微服务方法的好处呢?

在本文中，我们观察了安全方面的挑战，并提供了一份确保微服务和容器安全的行业最佳实践列表。本文对微服务实践者和对该技术不熟悉的人都很有用。

目录

什么是微服务和容器?

微服务和容器的安全挑战。

确保微服务和容器安全的10个最佳实践： 1.创建不可变的容器

2.仅从可信来源运行映像

3.使用注册表安全访问图像

4.每个主机部署一个微服务

5.强化主机操作系统

6.以深度防御的方式保护微服务

7.将自动化的安全测试集成到构建或CI过程中

8.使用容器本地监控工具

9.使用业务流程经理

10.使用API访问控制安全访问微服务

什么是微服务和容器?

美国国家标准与技术研究院(National Institute of Standards and Technology,以下简称：NIST)将微服务定义为松散耦合的自包含服务，它是应用程序组件体系结构分解的结果。这些服务可以使用标准通信协议和一组定义良好的API相互通信。这个定义意味着开发人员需要将应用程序服务分解成独立的单元，这些单元可以相互连接并部署在任何基础设施中。为了在任何设备上实现微服务部署，开发人员将微服务放入容器中。

微服务和容器的安全挑战

关于微服务的安全问题通常源于以下内容：

• 许多活动部件

基于微服务的应用程序是由许多活动部件组成，这使得它们比单体应用程序更复杂。一个应用程序可以包含部署在数千个容器中的数百个微服务。对于开发人员来说，这意味着包含1000个dll的单块代码应该被分解成相同数量的微服务。这使得代码更加安全和易于维护，同时也使得基于微服务的应用程序更容易受到网络攻击。

• 通信风险

此外，接口驱动的开发方法需要定义良好的REST API，以确保微服务能够建立彼此一致的通信。与组件内部通信的单体应用程序不同的是，基于微服务的应用程序组件在外部和内部环境中都通信，这带来了速度和安全方面的挑战。开发人员必须更加注意安全性，因为他们必须保护比单体应用程序中更多的东西，保证通信的安全性，并保护更大的攻击面。

对于容器相关的安全挑战，由于所有操作都应该维护安全，因此存在广泛的问题。

• 容器技术的漏洞

容器技术的核心组件——容器、图像、寄存器、编配程序和主机操作系统——也可能成为网络罪犯的目标。例如，攻击者可以破坏图像并访问应用程序或数据文件。此外，黑客可以用恶意代码感染容器，并使用它攻击其他容器、主机操作系统或其他主机。

• 更多的人可以使用代码

虽然DevSecOps旨在打破团队之间的障碍，确保持续集成和持续部署(CI/CD)，但它也会导致在分布式工作环境中更改代码的风险增加。

在选择适当的安全措施时，请记住，这些措施不应该与对开发人员如此有吸引力的优点相悖 : 例如轻量级服务、简化代码构建和打包、即时启动能力以及按需灵活扩展。如果安全措施使这种方法不再有用，那么它们很可能被忽略或拒绝。

确保微服务和容器安全的10个最佳实践

本篇文章的微服务和容器安全最佳实践清单，基于行业专业知识、领先的微服务从业人员提供的安全建议和官方行业标准，这些内容反映在以下文件中：

NIST Special Publication 800-180, NIST

Definition of Microservices, Application Containers and System Virtual Machines

NIST特别出版物800-180：微服务、应用程序容器和系统虚拟机的定义

NIST Special Publication 800-190, Application Container Security Guide

NIST特别出版物800-190：应用容器安全指南

NISTIR 8176, Security Assurance Requirements for Linux Application Container Deployments

NISTIR 8176：Linux应用程序容器部署的安全保证要求

DWP Security Policies and Standards, Security Standard - Microservices Architecture (SS-028)

DWP安全策略与标准：安全标准——微服务体系结构(SS-028)

现在让我们进一步了解如何保护部署在容器中的微服务。

1.创建不可变的容器

开发人员倾向于让 shell 访问图像，这样他们就可以在生产中修复它们。然而，攻击者经常利用这种访问方式注入恶意代码。为了避免这种情况，需要创建不可变的容器。在出现任何缺陷或漏洞时，开发人员可以重新构建和重新部署容器。远程管理是通过运行时API或通过为运行微服务的主机创建远程shell会话来完成的。容器的不可变特性也会影响数据持久性。开发人员应该将数据存储在容器之外，以便在替换其中一些数据时，新版本仍然可以使用所有数据。

2.仅从可信来源运行映像

对于拥有现成可用容器的开发人员来说，有许多开放源码包，包括Node.js.、Apache Web服务器和 Linux 操作系统。但是，出于安全目的，你需要知道容器的来源、更新时间以及它们是否没有任何已知的漏洞和恶意代码。最好是建立一个可信的映像存储库，并仅从该可信源运行映像。此外，开发人员应该在将容器投入生产之前检查脚本中的应用程序签名。如果米在多个云环境中运行，那么可以使用多个映像存储库。如果想使用来自其他来源的图像，建议使用扫描工具扫描它们的内容。

3.使用注册表安全访问图像

Docker Hub、Amazon EC2容器注册中心和Quay容器注册中心等注册中心帮助开发人员存储和管理他们创建的映像。这些注册中心还可以用于提供基于角色的访问控制、只接受来自可信来源的容器、不断更新已知漏洞列表以及标记易受攻击的映像。

基于角色的访问控制非常重要，因为你需要控制谁可以将更改引入容器。最好限制对特定管理帐户的访问：一个负责系统管理，一个负责操作和编排容器。

此外，你应该确保注册中心验证每个容器的签名，并且只接受来自可信来源的签名。你的注册表还应该包含一些功能，帮助你不断检查图像内容的已知漏洞，并告知安全问题。

4.每个主机部署一个微服务

基于微服务的应用程序可以部署在同一个主机上，也可以部署在多个主机上。因此，这种部署模型导致了管理的复杂性。考虑哪些容器应该部署到哪些主机上，哪些容器需要相互访问，以及如何自动扩展软件容量，最佳实践是在单个主机操作系统内核上对特定微服务的容器进行分组。这种方法在深度上提供了额外的防御，可以给攻击者在危害不同群体时增加难度。如果你的环境比较大，有很多主机，请自动化这个过程。

5. 强化主机操作系统

虽然大多数建议都涉及到微服务和容器的安全性，但是还需要确保主机操作系统的安全性。首先，NIST建议使用特定于容器的主机操作系统，因为它们没有不必要的功能，攻击面会比通用主机小得多。使用允许使用路由器或防火墙控制出口流量的平台也是可取的。

其次，CIS Docker基准测试可以提供一系列检查，为你提供关于如何加强系统的良好基线。很可能，它会建议你做以下工作：

• 建立用户认证
• 设置访问角色
• 指定二进制文件访问权限
• 启用审计数据的日志记录

为了避免数据被盗，限制对底层操作系统资源的容器访问，并将容器彼此隔离。最佳实践是在内核模式下运行容器引擎，而在用户模式下运行容器。此外，Linux提供了多层安全性，限制了容器的功能。Linux中的安全性可以通过使用内核安全特性和模块(如Linux名称空间、Seccomp、Cgroups、SELinux和Linux功能)来实现。

6. 以深度防御的方式保护微服务

这种方法是微服务安全的最重要原则之一，因为它创建了多个安全层以防止攻击，包括过滤通信流、对微服务的访问进行身份验证和授权以及使用加密技术等安全措施。保护你的内部环境不受任何外部连接的影响是第一层防御。如果使用来自公共存储库的映像，这可能对应用程序构成安全风险。通过已知的私有网络管理主机，这样就不会有公开的攻击面。

7.将自动化的安全测试集成到构建或CI过程中

有许多工具可以在构建或CI过程中自动测试容器。例如，HP Fortify和IBM AppScan提供了动态和静态应用程序安全测试。你还可以使用像JFog Xray和Black Duck Hub这样的扫描仪来实时检查容器中已知的漏洞。这些工具标记了已发现的问题，并允许你采取适当的行动。

8.使用容器本地监控工具

当我们处理 Docker 时，我们使用Docker安全扫描器或其他特别设计的工具来检测对我们的应用程序的任何潜在威胁。当安全扫描发现恶意软件和已知漏洞时，监控工具会检测出你没有预料到的问题。监控工具首先收集事件，然后根据安全策略检查事件。确定性策略可以定义哪些服务可以运行，以及允许哪些容器发出外部HTTP请求。动态策略可以创建正常通信活动的基线，并通知流量峰值或异常流量。

9.使用编排经理

微服务编排可以通过两种方式实现：

• 通过使用API网关作为编排层
• 通过将编排编码作为独立的微服务

协调器从注册中心提取图像，将这些图像部署到容器中，并管理它们的运行。协调器提供的抽象允许你指定给运行定映像所需的容器数量，以及需要为它们分配哪些主机资源。使用编排管理器，不仅可以自动化微服务的部署，还可以确保一定级别的安全性。例如，编排器允许你管理容器的集群、隔离工作负载、限制对元数据的访问和收集日志。

许多编排管理器还拥有内置的秘密管理工具，允许开发人员安全地存储和共享秘密数据，比如API和SSL证书、加密密钥、标识符和密码。有许多编配管理器，如Kubernetes、Swarm和Mesos以及Azure、GCP和AWS提供的云本地管理系统。

10.使用API访问控制安全访问微服务

API是包含微服务应用程序的关键。基于这种技术的软件具有多个独立的API服务，这些服务需要额外的工具来管理。因此，确保安全身份验证和授权的API访问控制对于微服务安全性至关重要。开发人员和管理员通常使用OAuth/OAuth2服务器来获取使用API进行身份验证的令牌。出于安全原因，还应该确保所有客户机-服务器通信在传输过程中使用传输层安全(TLS)进行加密。

结论

向微服务的转变使开发人员能够改进他们的应用程序和基础设施。然而，这些技术需要一种完全不同的安全方法。对于基于微服务的软件，一个全面的安全程序应该处理其整个应用程序的生命周期。使用所描述的最佳实践，可以确保容器和微服务的安全开发和部署。