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

做者 | Anna Bryk 市场研究专家

原文 | Microservices and Container Security: 10 Best Practices

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

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

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

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

目录

1、什么是微服务和容器?

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

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

1. 建立不可变的容器
2. 仅从可信来源运行映像
3. 使用注册表安全访问图像
4. 每一个主机部署一个微服务
5. 强化主机操做系统
6. 以深度防护的方式保护微服务
7. 将自动化的安全测试集成到构建或CI过程当中
8. 使用容器本地监控工具
9. 使用业务流程经理
10. 使用API访问控制安全访问微服务

1、什么是微服务和容器?

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

2、微服务和容器的安全挑战

关于微服务的安全问题一般源于如下内容：

• 许多活动部件

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

• 通讯风险

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

对于容器相关的安全挑战，因为全部操做都应该维护安全，所以存在普遍的问题。

• 容器技术的漏洞

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

• 更多的人可使用代码

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

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

3、确保微服务和容器安全的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)

关注Java技术zhai公众号，后台回复“架构资料”，便可获取整理好的微服务资料

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

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)进行加密。

结论

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