前言：熟悉当前微服务架构的各界人士就哪种安全技术和工具能够最有效地保护微服务达成了共识：了解API和API访问控制及网关能够确保微服务的安全。

API访问控制
• 大部分微服务支持内部API，它们是不可见的，外部代理服务器无法访问。如果API出故障，就只能使用HTTP访问微服务器，但是在HTTP中可以完成的操作就会被限制，只能从Cloud本身打开HTTP访问，这种方式可以达到需求。应用于许多微服务的经验法则是：不访问数据库，通过JSON就可以再访问其他微服务器或API本身。
• 安全域边界 – 基于角色的身份验证。每一次使用访问、部署和扩展权限都会进行识别和认证，将安全性从数据库层扩展到应用程序API，不会失去对该服务的控制。
• 微服务的API访问控制。 借用开放Web API功能。通过使用Torch，Kubernetes和CloudFoundry的网络证书、令牌将API架构中的访问控制标准汇总在一起 。
• 需要API网关密钥才能登录。传输层的SSL，白名单可以访问的ISP。
• JSON Web令牌，Amazon虚拟私有云和API网关模式。

API网关
• 对于API网关来说没有适合的新技术，只能采用分层方式编码标准，同行评议，自动测试和第三方笔测试。 在API上公开提供更安全的配置文件。
• API网关成为最常用的解决方案的一个很好的理由就是除了保证安全性外，还提供了许多出色的开箱即用管理服务。当使用独立的微服务器时，OpenID和OAuth都是可以采用的方法。
• 从开发和设计人员的思维出发，安全是一开始就需要考虑。最佳选择就是带有用户认证的OWAT2。确保没有遗漏进行常规的安全扫描。Docker也具有安全扫描功能，所有通过API访问与API网关和安全平台都有一个入口点。
• API安全性与应用程序安全性相同。重要的不仅是原生的第一方应用程序， ID也变得更加关键。需要考虑如何集成到身份层 ，如何随时应用，如何授权访问以及从前端到后端的覆盖。从开发人员角度来分析，更复杂的不仅仅是前端安全，还包括安全零信任架构。
• API是在微服务体系结构中建立治理的有效途径。开发人员通过API确认微服务器下一步将做什么，以及还不能做到的有哪些方面。 这使得IT中心管理微服务变得容易，因为它们的SLA可以通过作为微服务的代理的API网关进行管理。确保了IT领域管理层面的平衡性和团队协作的灵活性。

其他方法
• 如果有正在运行微服务器，则基本上必须使用SELinux。 SELinux将防止程序在除了自身系统之外的任意系统运行，这就使得攻击者无能为力，不能在系统上做任何事情。 对于任何生产工作负载容器，正确认识和使用SELinux是必要条件。 除此之外，用操作系统相同的方式处理容器及其依赖容器，并进行定期的更新和测试。
• 由于专注于具有成熟生态系统的企业的应用程序现代化，经常将安全模式适用到其他的地方。理想的配置就是可以配合现有的SSO和授权方案来生成JWT模型。“双重包装”和JWT加密，以允许服务适当地访问公共会话数据，包括企业外部不太安全的API。加密的内层只有可信赖的服务器才能保存密钥。具有内部安全层的JWT保持了服务层的无状态，同时开放了不同级别的信任架构中的交互。
• 与其他应用程序相同， 将静态应用程序安全性测试集成到构建过程中。 这一方法更适用于微服务，因为微服务使用更频繁地。以流程方式将安全性带入流程定义， 转向动态与静态测试。应用程序一经部署，就能对其产生的风险进行更好的监测。
• 安全技术和工具的效果取决于微服务部署的环境。OAuth能够明显保护端口，Web服务端点的大多数提供者都依赖于OAuth的安全性。
• 安全地对所有数据进行全盘加密。验证授权工具中的安全组设置。使用负载均衡器自动化性能提升，安全的考虑和架构的加密就变得非常重要。 使用第三方对所有过程进行记录、审核和验证，以确保PCI，ISO和其他合规性要求的所有内容都被锁定。
• 与信息安全，建筑师和工程师合作进行代码审查和静态代码分析。 InfoSec收集问题报告，观察模式并进行概念证明。
• 使用一个强大的容器调度引擎来管理微服务可以帮助解决安全问题。
• 当提供的微服务是用于较小团队时，可以采用供应链方式，通过适当的基于角色的访问控制进行交付。 锁定输入到服务，可以控制发布的对象，是一种用于进行大量集中式身份验证和授权的策略。

原文链接：https://dzone.com/articles/how-do-you-secure-microservices