如何保障微服务安全

原文：Securing microservices
作者：SERGIUOLTEAN
翻译：无阻我飞扬

摘要：如何保护微服务，确保微服务的安全，作者从保护应用程序安全和保护容器的安全两个方面进行了阐述，以下是译文

保护微服务

实现一个微服务很难。部署一个微服务应用程序复杂性也很高。保护微服务的安全就更难更复杂。从哪里开始呢？脑海中首先出现的一些词是身份验证和授权、防火墙、授信、会话、令牌。我们需要保护应用程序的安全，也需要保护容器的安全。

保护应用程序

一种方法是构建一个单点登录（SSO）网关,像普通的网关一样，它位于应用程序的前端，但需要考虑到其与SSO服务器的握手，并执行URL重定向操作。可以用http报文头传送授权和认证信息给服务。但是除非使用https，否则这样做是不安全的。但是我们知道https有证书，维护多个微服务的证书可能会成为问题，尤其是需要补发或撤销这些证书的时候，复杂性将进一步增加，我们尽量避免这种情况。

另一种方法是用HMAC（基于哈希的消息代码）。这个请求的主体带有哈希私钥，结果是随着请求发送的。然后，服务器通过使用其私钥和请求主体的副本重新创建哈希，并将其与接收到的哈希进行比较。如果一切都匹配，那就意味着消息没有被篡改，请求可以通过。这种模式由JWT（Json Web Tokens）实现。但是，事实上网络侦听器仍然可以看到数据。

Twitter，Google等使用API密钥。使用API密钥，服务可以识别谁在调用，并可以对其设置限制。密钥是成对的（公钥和私钥），它们必须集中管理。

假定一切都准备就绪了，但是还是有一个问题，如何确保用户无法访问其他用户的数据呢？那就需要做更多的限制，可以通过限定用户只能访问他自己的数据来保护我们的服务，但是将导致在许多地方产生大量的样板代码。不幸的是，没有更好的办法。微服务意味着复杂性和一些重复预期会被减少。

还是没有解决嗅探器（sniffer，也叫数据抓包软件）的问题。怎样才能确保sniffer看不到数据呢。答案是加密。先加密，然后根据需要进行解密。这就是微服务复杂系统的另一个组件：密钥服务。

有很多库可以用，最好的选择是使用成熟的库，如OAuth或SAML。

服务可以有状态参数。为网关中初始化的所有服务保持一个全局会话，并将其传播到所有其它服务。会话可以从像KeyCloak这样的中央认证和授权服务器（SSO）获得。

我们更希望服务没有状态参数。这意味着需要将状态从服务器转移到客户端。Json的 Web令牌（JWT）非常符合这种需求。这是一种在双方之间转移声明的安全方式。基本上它的一个json作为Json Web签名（JWS）的主体或Json Web加密（JWE）的明文传递。声明可以进行数字签名，并包含发行者，用户的身份，到期时间，还可以包含自定义属性。

举一个例子，流程看起来如下图：

客户端应用程序将与UAA（用户认证和授权）服务器进行交互。它为包含一个JWT令牌的重定向URL交换其证书。令牌将提交到网关，在UAA服务器进行验证。如果一切正常，它会将该JWT令牌转发到所请求的服务，将会解码它并授予其对所请求资源的访问权限。

保护容器

现在已经知道如何保护应用程序了，是时候关注容器的安全了。Docker是一个广泛使用的容器。可以做些什么来保护它们呢？

答案是深度防御。这意味着需要防火墙；这意味着需要小心记录在日志中的信息（被攻击后，日志有助于快速恢复系统）；这意味着需要监视集群的可疑行为（入侵检测系统和入侵防御系统）；这意味着需要将服务分开并将它们放在不同的位置（虚拟私有云），并创建一组规则，确保它们仍然能够相互通信；这意味着保持操作系统更新（特别是安全更新）。

Aaron Grattafiori在Docker Con 2016年的演讲中谈到三个原则：

• 最小权限原则，这意味着不以root身份运行应用程序
• 最小意外原则
• 最小访问原则，这意味着每个模块只能访问与其相关的数据

这里有篇文章有更多的相关细节。假设已经遵循了上述三原则，想到的下一个问题是：使用的Docker图像安全吗？怎么知道它们没有包含恶意代码呢？幸运的是，在Docker 1.8中引入了Docker Content Trust ，与此同时，Docker图像的发布者在将其推送到注册表之前进行了验证。

保护Docker安全的一个有用的工具是Calico。每个Docker网络都有Calico配置文件，必须设置规则和策略以控制流量。更多相关内容看这里。

现在你应该有足够的信息来启动你的微服务安全保护了。