微服务和容器安全应用的10个最佳实践

容器是目前应用系统运行的常用环境，特别是对于复杂的应用系统，开发人员更喜欢使用基于容器的开发架构，因为容器是轻量级的、可移植的，并且易于维护和扩展。由于这些特性，容器非常适用于现代开发模式，如DevOps、无服务器和微服务等。

开发人员可在容器中封装了应用程序的轻量级运行时环境。因此，当在容器中开发微服务时，它继承了容器化的优点，如可移植性、可伸缩性和额外安全层等。同时，在单独的容器中运行微服务，用户可以独立地部署它们，消除了语言、库和框架之间的兼容性风险。在服务监测方面，容器化使微服务更容易定位和相互通信，因为它们都运行在位于同一平台上的容器中，开发人员将更容易编排微服务。

微服务和容器应用的安全挑战

虽然基于容器的微服务开发应用方法有诸多好处，包括易于扩展和管理，但它们也同样存在一些的安全问题。在服务开发之前，企业应该了解可能出现的网络安全风险以及如何消除这些风险，将有助于创建可靠又安全的产品。

1. 可被利用的漏洞

一般来说，与微服务和容器相关的安全问题属于应用编排平台的整体安全需求中。但是，并非所有的安全风险都可以在业务流程中处理。比如说可能被利用的漏洞。

映像漏洞是基于微服务和容器的应用程序内最常见的安全威胁。它们通常来自不安全的库或其他依赖项。当容器基于不安全的映像时，就会将该漏洞威胁引入整个应用环境；
应用程序漏洞主要指应用程序的源代码缺陷。比如某个应用程序中存在一个缓冲区溢出漏洞，攻击者可能会利用它来执行恶意代码并接管容器；
网络攻击的漏洞。基于微服务的应用程序比传统应用程序更复杂，因为它们由许多独立部件组成。一个应用程序可以包括部署在数千个容器中的数百个微服务，这使得基于微服务的应用程序非常容易受到网络攻击，因为很难同时确保这么多组件的整体安全性。

2. 恶意软件风险

恶意软件的危害在于，如果企业在启动容器之前没有检测到它，恶意软件将感染此容器内的微服务以及整个环境。恶意软件攻击带来的安全风险主要包括:

黑客可以访问一个容器并向其中注入恶意代码，通过恶意代码可以攻击该容器、其他容器或主机操作系统中的微服务；
恶意攻击者会危害企业的CI/CD环境，并将恶意软件注入用于构建容器映像的源代码存储库；
攻击者会破坏容器注册表并替换包含恶意软件的图像；
攻击者欺骗开发人员从外部来源下载恶意容器映像。

3. 与代码访问相关的风险

访问和修改代码的人越多，安全风险就越大，最常见的情况是:

访问权限过大。许多开发公司选择DevOps方法来使用微服务和容器构建应用程序，这可能导致访问权限过于宽泛，增加了在分布式工作环境中恶意修改代码的风险。
机密管理薄弱。在安全实践不佳或违反安全规则的情况下，很多人可以访问容器。例如，开发人员可能将脚本中编码的凭证放入容器中，或者将凭证存储在配置不安全的密钥管理系统中。

4. 容器间的通信不受限制

通常情况下，容器不能访问外部任何资源，这被称为非特权模式。工程师应该只允许保障应用系统正常工作所必需的容器间通信。每当容器的通信权限超过严格要求时，它可能会导致额外的安全风险。由于缺乏经验或管理不当而导致的错误配置，会让容器获得过多的特权。

5. 不安全的数据管理

微服务体系的分布式框架使得数据安全管理更具挑战性，因为很难控制对单个服务的访问和安全授权。因此，工程师必须更加关注如何确保每个服务内数据的机密性、隐私性和完整性。另一个问题是，微服务中的数据不断地移动、更改，并在不同的服务中用于不同的目的，这为攻击者创建了更多的数据窃取攻击点。

6. 错误配置工具

在开发和维护微服务架构时，DevOps团队需要使用大量工具，包括开源和第三方工具。虽然这类工具帮助工程师实现DevOps管道所需的效率，但它们很难保证所需要的安全性。

如果不能准确评估开源工具的安全功能，企业就有可能在微服务和容器中创建漏洞。即使一个工具本身是安全，如果没有正确设置，也会出现很多安全问题。

微服务和容器安全防护最佳实践

如何选择适当的安全措施来应对上面提到的风险可能是一个挑战。究其原因，容器和微服务都是因为它们应用的简洁性和快捷性而对开发人员具有如此大的吸引力。如果安全措施使开发流程变得缓慢和复杂，那么就很可能会被开发人员所抵触或故意忽视。为了帮助企业在安全的情况下高效利用容器和微服务进行应用系统开发，本文收集整理了10种有用的最佳实践。

1. 创建不可变容器

开发人员往往保留通过shell访问映像的途径，以便修复生产环境中的映像。然而，攻击者常利用这条途径来注入恶意代码。要避免这种情况，可以创建不可变容器。不可变容器无法被改动。如果用户需要更新应用程序代码、打补丁或更改配置，可以重新构建映像并重新部署容器。如果用户需要撤回更改，只需重新部署旧映像。需要注意的是，容器的不可变特性会影响到数据持久性。开发人员应该将数据存储在容器外面，这样容器被替换时，所有数据仍可供新版本使用。

2. 将自动安全测试集成到CI/CD过程中

有各种工具可以在CI/CD过程中自动测试容器。比如说，HP Fortify和IBM AppScan提供动态和静态应用程序安全测试。还可以使用JFrog Xray和Black Duck等扫描器实时检查容器中已知的漏洞。一旦这类工具发现了漏洞，就会将检测到有问题的部分标注出来，以便检查和修复。

3. 避免使用特权容器

如果容器在特权模式下运行，它就可以访问主机上的所有组件。如果这种容器被破坏，攻击者可以全面访问服务器。因此，应该考虑尽量避免使用特权容器。比如在Kubernetes中，可以使用策略控制器（Policy Controller）禁止特权容器。

如果出于某种原因需要使用特权容器，谷歌云架构中心提供了几个替代方案：

通过Kubernetes的securityContext选项为容器提供特定的功能
在sidecar容器或init容器中修改应用程序设置
使用专用注释修改Kubernetes中的sysctls接口

4. 建立可信映像库

开源社区会为开发人员提供许多具有容器的开源软件包。但是出于安全目的，开发者需要知道容器的来源、更新时间以及它们是否含有漏洞和恶意代码。最好建立可信映像库，只从这个可信源运行映像。如果想使用其他来源的映像，建议首先使用扫描工具扫描映像。此外，在将容器部署到生产环境之前，开发人员应检查脚本中的应用程序签名。如果在多个云环境中运行容器，需要建立多个安全映像存储库。

5. 使用注册中心管理映像

Docker Hub、Amazon EC2 Container Registry和Quay Container Registry等注册中心可以帮助开发人员存储和管理已创建的映像。可以使用这些注册中心执行以下操作：

提供基于角色的访问控制
指定容器的可信源
创建和更新已知漏洞列表
标注易受攻击的映像

基于角色的访问控制非常重要，因为需要控制谁可以改变容器。最好将访问权限分开到不同的管理帐户：一个负责系统管理，另一个负责操作和编排容器。要记住的另一点是，应该确保注册中心验证每个容器的签名，只接受来自可信源的容器。此外，需要充分利用帮助不断检查映像内容查找已知漏洞，并报告安全问题的功能。

6. 加固主机操作系统

保障微服务和容器的应用安全，有必要确保主机操作系统的安全。

首先，建议企业使用针对特定容器的主机操作系统（明确旨在只运行容器的简版主机操作系统），因为它们没有不必要的功能，因而攻击面比通用主机系统小很多。

其次，CIS Docker Benchmark提供了加固系统的核对列表，主要的建议如下：

建立用户身份验证
设置访问角色
指定二进制文件访问权限
收集详细的审计日志

为了避免数据泄露，应该限制容器对底层操作系统资源的访问，并将容器彼此隔离。一个好的做法是在内核模式下运行容器引擎，同时在用户模式下运行容器。比如说，Linux提供了Linux命名空间、seccomp、cgroups和SELinux等技术，从而安全地构建和运行容器。

7. 用纵深防御方法保护微服务

纵深防御可以结合多种安全机制和控制措施，比如杀毒软件、防火墙和补丁管理，以保护网络和数据的机密性、完整性和可用性。

纵深防御方法的三大层是：

物理控制——用于物理限制用户访问IT系统，比如安保系统和闭路电视系统
技术控制——旨在保护系统和资源的软硬件
管理控制——通过各种策略和程序，以确保组织关键基础设施的网络安全性

纵深防御方法是确保微服务安全的最重要原则之一，因为它创建了多层安全以防止攻击。它包括下列安全措施：过滤传输的数据流、验证和授权对微服务的访问以及使用加密技术等。要确保内部环境不受任何外部连接的影响，因为这是安全防护的基础。

8. 严格控制API访问

API是微服务应用程序的关键，很多软件都会有多个独立的API服务。因此，确保安全身份验证和授权的API访问控制对于微服务安全至关重要。当API服务访问敏感数据时，应该需要提供验证令牌，令牌要经过数字签名或得到权威来源的验证。开发人员和管理员可以使用OAuth/OAuth2服务器来获取令牌，以便通过API访问应用程序。出于安全考虑，还应该使用传输层安全（TLS）加密来保护所有客户机/服务器通信。

9. 原生化容器检测工具

持续性监测容器的运行很有必要，因为它可以帮助用户：