微服务devops_用于微服务的安全DevOps

微服务devops

容器和微服务彻底改变了应用程序开发和基础架构管理。 他们还提出了新的安全挑战，而没有解决旧的挑战。 有哪些新的安全挑战，您可以如何应对？

新技术，新挑战

微服务正在改变一切。 不变的基础架构，无共享架构和容器化应用程序（微服务）是当今大多数企业路线图的重点。 微服务提供了一种以小型，自治且可自我维持的能力公开业务功能的方法，可以在给定的业务范围内执行单位任务。 这些通常以在虚拟机内部运行，在容器内部甚至在裸机上运行的API（应用程序编程接口）的形式公开。

尽管容器化优势是多重的，但这也带来了一系列新的挑战。 眼前的挑战包括监视容器，容器爬网，容器安全，微服务的跟踪和追踪以及图像来源。

那么，对微服务领域的安全性有何影响？ 整体应用程序环境中存在的安全挑战仍然存在，需要照常解决。 此外，我们需要考虑微服务和容器技术带来的其他安全挑战。

从安全性的角度来看，与单片应用程序相比，在微服务领域，攻击的表面积现在已大大增加。 随着更多可部署单元和端点的暴露，针对这些端点的安全攻击的可能性以及完整性问题也有所增加。

此外，基本Docker映像可能包含安全漏洞，这些漏洞可能会损害微服务。 因此，应管理Docker映像的来源，以确保基础Docker映像的真实性。 将安全更新和补丁以最少的停机时间传播到所有现有容器是另一个挑战。

在微服务领域，DevOps可能会给安全需求带来更多压力。 当前，持续的构建和部署工具专注于简化交付过程，尽管对安全DevOps的关注不多。

最佳实践

为了应对上述挑战，让我们看看以下最佳实践。 作为有效的DevOps策略的一部分，应将连续的安全性和审核步骤集成到DevOps管道中。 连续测试应包括各种安全测试功能，并且图像完整性验证应集成到管道中。 此外，私人注册表可以确保映像在企业内部受到信任和管理。

应该使用异常检测机制来增强监视，以检测容器的任何虚假资源利用或异常事件，并且应该同时使用基于代理的过程和无代理的过程来增强所有监视功能。 补丁程序管理应进行更新和改进，以确保用最新更新对容器进行补丁程序，同时确保最少的停机时间。

Docker引入了一种称为Notary的图像源机制，该机制基于TUF（用于典型软件分发和更新的更新框架）。 由于公证人仍处于发展阶段，因此目前没有多少容器协调员支持它。 公证人还需要企业中成熟的密钥管理流程。

微服务之间的安全性是发生这种情况的另一个关键领域，在这种情况下可以有效利用API网关。 传统的基于PKI的消息安全性不是可扩展的选项。 相反，请看一下JWT（JSON Web令牌）方法。 JWT是一种编码的令牌，具有一组有关请求者的声明策略。 令牌通常由身份服务器签名，可以由收件人系统验证。 还可以对JWT进行数字加密，以维护断言的机密性和完整性（然后称为JWE）。

通常，安全性是（昂贵且困难的）事后才想到的。 使其成为微服务基础结构的基本功能，以获得最佳的安全性和性能。

翻译自: https://opensource.com/business/16/11/secured-devops-microservices

微服务devops