【51CTO.com快译】
随着微服务流程和系统部署在DevOps实践中的广泛使用，DevOps工程师在软件开发项目中的安全责任日益增大。我们需要通过良好的DevSecOps流程，在保证应用部署、运营和服务监视的同时，通过容器与微服务来加持安全性。
身份标识
在设计新的分布式系统，或将单体应用(monolithic application)重构与增强为微服务时，人们往往会考虑每个微服务与其他微服务进行通信的业务应用和流程。那么与客户、以及其他开发伙伴的合作过程中，我们需要采用微服务级别的身份标识。此类标识可以为我们带来如下优势：
- 由于身份标识通常不会被经常更改，因此它有助于我们理解分布式应用的处理过程。
- 由于不需要通过限制某些微服务来提供各类节点，因此我们可以充分利用容器编排的敏捷性。
- 无论是容器还是虚拟机，由于它们的主机身份可以被抽象地用身份标识来表示，因此我们可以据此实现平台化。
跨云、域、主机和应用的负载
在微服务实际应用中，一个最大问题是：横跨多个域环境、计算类型、以及混合云的身份标识传递问题。通常说来，由于分布式系统横跨了不同的安全与身份域，我们很难实现对不同复杂环境的可用性管理，以及动态扩展。
有研究表明：各类企业的大多数数据泄露事件都是由误解所导致。这些误解体现在：各种云服务和系统的安全配置策略，到底是云服务提供商的责任、还是应用所有者的职能。DevOps团队应当确保在部署微服务之前，将合适的安全策略配置到云端环境中。
针对上述需求，我们可以采取的方法是：在所有环境中使用单一的证书颁发机构，来作为CA(certificate authority)。例如，作为开源工具的服务网格(service mesh)，就可以在越来越多的项目中被用作CA中心。虽然，各种服务网格系统的配置过程可能相当繁琐，但是它们可以充当非常实用的安全和运营的控制点。在具体实现上，我们可以在Kubernetes的多个集群中配置Istio(译者注：一种微服务系统管理工具)。通过向Istio添加非Kubernetes服务，进一步扩展其信任范围。当然，这也会增加配置的复杂性，最终还是取决于每个项目所有者将如何限制其控制权限。总的说来，鉴于可操作微服务的复杂性，随着应用程序的迭代和操作管控的加强，此举会带来如下方面的好处：
- 更快地完成代码的编写与部署。
- 可重复的dev-sec-ops流程。
- 使用质量检查与安全扫描工具，来获取更高的安全性。
- 增加对于用户使用的可用性。
- 实现软件级的故障转移(鲁棒性)。
- 快速或动态地实现可扩展性。
当然，有些用户也可以选择仅使用内部身份表示，以及只使用一个简单的在线证书，然后将两者在分布式微服务的不同CA处实现同步。由于此类设置具有一定的复杂性，因此仅被那些在微服务开发、安全性和运营管理方面，有着丰富经验的DecSecOps流程和团队所采用。此外，我建议您在围绕着自身的业务流程和计算架构的成熟度，进行充分评估的基础上，酌情采用。
有了前面的基础，用户在对多个不同的实体实施身份管理(包括：识别，控制，构建，保护，配置，监控，以及信任传递)时，就容易得多了。通常，微服务的信任建立过程是一组DevSecOps的流程和架构。它们定义了如何在新的分布式系统环境中(无论是否使用Kubernetes)，如何对微服务进行身份验证。同时，我们需要通过成功落地DevOps，来实现基于身份的云服务负载。也就是说，为了保护微服务，我们需要自动化定义，创建，管理和保护各种负载的身份，以及微服务实体，并促进无摩擦的零流程安全(frictionless zero process security)。
DevSecOps中的安全细节
在此，我们给出的一种解决方案是：建立一个平台，通过CI/CD管道，为每一种微服务创建一个身份标识，以确保这种嵌入式身份能够通过密码绑定到内存中。那么，当微服务被发布到生产环境中时，该标识便可利用相关策略，自动化地创建并加固其安全性。据此，我们不但可以保护生产环境免受攻击的侵害和泄露的危险，而且能够确保微服务仅与那些已完成标识和认证的微服务间进行通信。
此类方案实际上充当了一个自动化的安全层。它将CI/CD无缝地添加到了DevSecOps的实现中。此外，为了保护CI/CD之外的负载，我们还可以借用Cyber Armor(请参见--http://www.cyberarmor.io/)平台，自动将身份标识作为CI/CD的一部分，予以创建，并在部署的过程中持续实施保护。
在Kubernetes里，由于认证服务适用于整个集群的各种默认帐户，因此在实践中，除非我们需要为某个帐户的身份识别，采取特殊的配置，否则通常不会将其用于微服务的身份认证之中。在此，Istio的服务度量控制(service measurement control)正好能够发挥作用。它可以用作微服务的身份标识，融入DevOps的流程和处理之中。
用户身份与服务身份
从单体发展到基于微服务，应用所处的环境越来越复杂，并行运行的软件也越来越多。就安全问题而言，每一个组件都会给服务架构带来攻击面。因此，无论是用户，还是微服务，都应当在服务架构中得到充分的验证，以保障合理的安全态势。
在过去的单体应用中，应用只需在内部完成了对于某个用户的身份识别与验证，便可决定该用户的使用权限。如今，用户需要在前端(front-end)的微服务处提供自己的身份标识，而各个微服务则利用JSON Web令牌，并结合AUTH0等框架，根据用户在整个信任链条中传递的身份信息，来认证该用户权限，进而决定其是否可以获取某些敏感数据。
运维管理中的微服务安全性：工具和流程
有时候，针对微服务的攻击并非来自某个用户，而是针对应用运行环境中的某些程序逻辑漏洞。因此，我们需要持续进行扫描，并与既定的构建和配置状态相比较，通过自动发现和应用映射，做出相应的安全性调整，以防止各种潜在的攻击。而且，在检测到攻击时，我们可以使用Grafana(译者注：开源的分析与监控平台)，来通过查看图表的方式，深入获悉攻击的类型和其他具体信息。
此外，我们可以使用Radware这种应用配置管理工具，来保护基于微服务的应用。例如，在应用发生更改时，Radware会根据配置策略，将变更信息反馈送到Sec Ops处进行评估和处理。也就是说，一旦发现更改，此类工具会进一步检查容器的注册表，Kubernetes也会将其与上一个状态的配置镜像作比较，通过记录已发现的更改，进而在所有不同的DevOps团队之间共享这些更改信息，以便实施补救。
【原标题】DevSecOps Using Container and Microservices Security，作者: Larry Gordon
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
