11 种微服务和容器安全最佳实践（上）

在Statista 2021 年的一项调查中，34% 的受访者表示他们已经采用了微服务，37% 的受访者表示他们部分使用了微服务，证明了这种开发方式的流行。

尽管微服务方法具有许多好处，包括易于扩展和管理，但它也隐藏了一些安全问题，例如可能的漏洞和通信风险。在开始开发过程之前了解预期的网络安全风险以及如何解决这些风险将帮助您创建可靠且安全的产品。

在本文中，我们观察了在开发应用程序时可能出现的基于容器和微服务的架构中的安全挑战。我们还提供 11 种微服务和容器安全最佳实践。本文对那些想要有效提高产品安全性的人以及对容器和微服务不熟悉的人很有用。

什么是容器和微服务？

容器和微服务是应用程序开发的流行方法，尤其是对于复杂的解决方案。O'Reilly 的2020 年微服务采用报告显示，77% 的受访者采用了微服务，其中 92% 的人通过这种方法获得了成功。此外，使用容器部署微服务的受访者比不使用容器的受访者更有可能报告成功。

在我们讨论如何在微服务和容器中实现安全性之前，让我们确切地探讨一下这些方法是什么以及它们为应用程序开发过程带来了什么好处。

容器化是一种虚拟化形式，使您能够在称为容器的隔离空间中运行应用程序，这些容器使用相同的共享操作系统 (OS)。虚拟化允许在单个物理服务器的硬件上运行多个操作系统，而容器化允许您在单个虚拟机或服务器上使用相同的操作系统部署多个应用程序。

容器，也称为应用程序容器或服务器应用程序容器，是包含应用程序代码及其库和依赖项的可执行软件单元。根据美国国家标准与技术研究院(NIST) 的说法，应用程序容器相互隔离但仍共享底层操作系统的资源这一事实使开发人员更容易跨云有效地扩展应用程序。

开发人员更喜欢使用基于容器的架构，因为容器轻量级、可移植且易于维护和扩展。由于这些品质，容器可用于现代开发方法，如 DevOps、无服务器和微服务。此外，开发人员可以精细控制每个容器可以使用多少资源，从而提高物理机的 CPU 和内存利用率。

容器的好处

微服务架构，或简称微服务，是一种应用程序开发的架构方法，其中单个应用程序由许多小型自治服务组成。

微服务是可独立部署的，与单体架构相比，它允许您改进应用程序代码、添加新功能和扩展每个服务。使用微服务，您可以更新现有服务，而无需重建和重新部署整个应用程序。

每个服务代表一个单独的代码库，因此可以由一个小型开发团队管理。微服务架构简化了创建和维护复杂应用程序的过程，但不适合小型应用程序。

微服务是松耦合的，所以如果一个服务发生故障，其余的继续工作，提高了整个应用程序的容错能力。此外，它们支持多语言编程，这意味着服务不需要共享相同的技术堆栈、库或框架。

微服务的好处

您可以单独或一起使用容器和微服务。由于在本文中我们讨论了使用这两种方法开发应用程序的安全实践，因此让我们简要探讨如何将容器和微服务结合起来。

简单来说，容器为应用程序封装了一个轻量级的运行时环境。因此，当在容器中开发微服务时，它继承了容器化的好处，例如可移植性、可扩展性和额外的安全层。容器为每个容器化应用程序或微服务提供隔离。因此，它们降低了安全漏洞传播的风险。

通过在单独的容器中运行微服务，您可以独立部署它们，而不管每个微服务是用什么语言编写的。通过这种方式，容器化消除了语言、库和框架之间任何摩擦或冲突的风险。

在服务发现方面，容器化使微服务之间的定位和通信变得更加简单，因为它们都运行在位于同一平台上的容器中。出于同样的原因，开发人员编排微服务也更容易。

容器微服务方案

尽管有这些优势，但容器和微服务都有其细微差别和挑战，包括网络安全问题。让我们讨论一些最重要的安全问题。

基于容器和微服务的应用程序的安全挑战

与任何其他方法一样，容器和微服务都可能给应用程序开发带来某些安全挑战。为了确保产品的良好网络安全，了解最常见的安全风险并计划如何预防和减轻它们至关重要。

具有微服务架构的容器化应用程序的安全挑战

1、可被利用的漏洞

一般来说，与微服务和容器相关的安全问题的讨论已经转移到编排平台的安全要求上。但是，并非所有安全风险都可以在编排级别处理。例如，必须密切关注可能被利用的漏洞。

1. 镜像漏洞是基于微服务和容器的应用程序中最常见的安全威胁。它们通常来自不安全的库或其他依赖项。易受攻击的图像本身不会构成主动威胁。但是，当容器基于易受攻击的镜像时，会将漏洞引入整个环境。

2. 应用程序漏洞可能来自应用程序源代码中的缺陷。例如，如果您的某个应用程序存在缓冲区溢出漏洞，攻击者可能会利用它执行恶意代码并接管您的容器。

3. 网络攻击的脆弱性。基于微服务的应用程序比单体应用程序更复杂，因为它们由许多移动部件组成。一个应用程序可以包含数百个部署在数千个容器中的微服务。对于开发人员来说，这意味着具有 1,000 个动态链接库 (DLL) 的单体代码应该被分解为相同数量的微服务。它使基于微服务的应用程序很容易受到网络攻击，因为很难确保这么多组件的适当安全性。

2、恶意软件风险

恶意软件攻击的可能场景包括：

· 黑客可以访问容器并向其中注入恶意代码，这些代码还可以攻击该容器、其他容器或主机操作系统中的微服务。

· 恶意行为者会破坏您的 CI/CD 环境并将恶意软件注入用于构建容器映像的源代码存储库中。

· 攻击者破坏容器注册表并用包含恶意软件的图像替换图像。

· 黑客诱使开发人员从外部来源下载恶意容器映像。

恶意软件的问题在于，如果您在启动容器之前没有检测到它，恶意软件将感染您在该容器内的微服务以及整个环境。例如，它可以收集敏感数据、阻止进程或中断其他容器的工作。

3、代码访问风险

可以访问和更改代码的人越多，出现的安全风险就越大。最常见的两种是：

1.访问权限太宽泛。许多开发公司选择使用微服务和容器构建应用程序的 DevOps 方法，因为它打破了团队之间的障碍并确保了持续集成和持续部署 (CI/CD)。但是，DevOps 可能会导致访问权限过于宽泛，从而增加有人在分布式工作环境中更改代码的风险。

2.保密管理薄弱。如果安全实践不佳或违反安全规则，更多人可以访问容器。例如，开发人员可能会将脚本中的硬编码凭证放入容器中，或者他们可能将机密存储在配置不安全的密钥管理系统中。

4、容器间无限制通信

通常，容器不能访问它们直接控制的环境之外的任何资源——这称为非特权模式。工程师应该只允许容器之间正确的应用程序工作所必需的通信能力。例如，应用程序容器可能会连接到数据库容器。

每当容器拥有比严格要求更多的权限时，它可能会导致额外的安全风险。由于缺乏经验或编排器管理不善导致的错误配置，容器可能会获得过多的权限。

5、安全地管理数据

微服务架构的分布式框架使得保护数据变得更具挑战性，因为难以控制对单个服务的访问和安全授权。因此，工程师必须更加关注他们的应用程序如何确保每个服务中的数据机密性、隐私性和完整性。

另一个问题是，微服务中的数据不断移动、更改，并在不同的服务中用于不同的目的，这为恶意行为者创造了更多的数据入口点。

6、选择和配置工具

在开发和维护微服务架构时，DevOps 团队使用了很多工具，包括开源和第三方。虽然此类工具可帮助工程师实现 DevOps 管道所需的效率，但它们并不总是提供所需的安全性。

如果您不仔细评估计划集成到环境中的开源工具的安全功能，您就有可能在微服务和容器中产生漏洞。即使一个工具看起来足够安全，你在配置它的设置时仍然应该小心，并随着时间的推移不断评估工具的安全性。

选择适当的安全措施来解决我们上面提到的风险可能具有挑战性。原因是容器和微服务都对开发人员如此有吸引力，因为它们简化和加速应用程序开发的方式。如果安全措施使开发方法变得更慢、更不直接，那么它们很可能会被忽视或忽视。

为了帮助您在不牺牲网络安全的情况下利用容器和微服务进行应用程序开发，我们收集了 11 个有用的实践。让我们详细探讨如何保护微服务和容器。

本文介绍了基于容器和微服务的应用程序的安全挑战，下一章节我们将讲述保护微服务和容器的 11 个最佳实践。