作者：Dale Bingham
NATS 2.0基于操作员、帐户和用户的安全性
继续我的第一篇文章关于服务网格的概念和讨论，接下来我将关注NATS 2.0和服务网格在安全领域的概念。服务网格的安全部分包括端到端加密（相互TLS）、身份验证、授权策略以及服务之间的服务到服务访问控制。有了NATS 2.0和NKeys、JWT以及操作员-帐户-用户安全模型的引入，我相信可以使用NATS，实现更安全的通信基础设施。在这篇文章中，我们将详细讨论这个问题，并将NATS模型与主流服务网格的安全模型进行比较和对比。
https://medium.com/@dale.bingham_30375/using-nats-to-implement-service-mesh-functionality-part-1-service-discovery-5f2e6088843b
服务网格 - 默认安全、深度防御、AuthN、AuthZ等等！
服务网格景观有一船船的流行语为他们的营销架构（marchitecture）。我把它们放在上面。但是，它们的工具和配置中也包含了很多优点，你可以打开和关闭它们来保护你的应用程序服务和它们的通信。因此，让我们对服务网格安全性进行基本了解，然后深入了解一些比较和对比NATS 2.0安全性的操作方式。这并不是对安全性的深入研究。我在这里有链接作作为你空闲时学习的具体细节。
我确实有一个讨厌的事。服务网购（如Istio）的一个特点是，你的应用程序代码或基础设施，不需要进行任何更改来保护你的服务。它们听起来很简单，但实际上，你必须正确安装Istio。更重要的是，你必须理解它，并正确地配置它。在Istio中有很多事情要做，它可以让你完成很多事情。
这种复杂性意味着需要调整配置文件（YAML）和命令来应用和实现配置。这是一个相当大的学习曲线。我不是想让你泄气。要知道你在做什么。一旦完成并实现了服务网格的安全模型，就可以很好地工作。它通过下面的内部组件列表来控制安全性。
它可以是一个PITA（讨厌的事），有一堆YAML文件周围去设置你的项目。如果间隔太大，YAML可能很难调试。所以这是个人缺点。然而，YAML文件=基础设施即代码，所以这是一个加分。
作为安全设置的一个例子，如果你查看Istio文档，你可以看到它有一些运行的安全组件：
- 用于密钥和证书管理的Citadel
- 边车代理实现客户端和服务器之间的安全通信
- Pilot分发策略和安全命名
- Mixer管理授权和审计
示例服务网格设置为AuthN/AuthZ，https://istio.io/docs/conceps/security/
这些组件协同工作以确保安全通信。代理边车（想想摩托车上的边车）可以在你的服务旁边安全地相互通信。你的服务通过这些边车作为代理与其他服务进行通信。客户端确保服务器是有效的。服务器根据策略确保客户端是有效的和经过授权的。他们在特定的时间点审计谁做了什么。当然，我是在5万英尺高的视野来看，还有更多复杂的地方来确保它能工作。
这里的要点是，Istio和类似的工具，通过其设置在内部处理服务之间的安全性。你的API和服务需要知道与谁进行应用程序通信。你可以使用YAML配置Istio来执行安全的服务到服务通信。我鼓励你阅读Istio的安全文档以获得更好的理解。或者Solo.io的Christian Posta等人在YouTube上发表的许多演讲和KubeCon 2018的会议。
NATS 2.0 - 操作员、账户和用户哦，我的天！
与上述服务网格模型相比，NATS 2.0安全模型使用了更分散的安全模型。对于2.0版本的NATS，你可以使用基于内存的解析器（或用于大型部署的NATS帐户服务器）和nsc工具来设置操作员（Operator）、帐户（Account）和用户（User）。查看下面的图像，了解可视化层次结构和分组概念。在我看来，操作员是根权限或顶级安全构造。你首先创建一个操作员，它们负责运行NATS服务器，为帐户签署JSON Web令牌（JWT）。帐户在为该帐户中的用户（或消息客户端）签署JWT方面做了类似的工作。所有这些都支持NATS中的其他安全性和AuthN/AuthZ。
帐户是由操作员建立和签署的，这是在NATS 2.0中实现多租户的方式。想想公寓楼（多租户）和单户住宅。它们相当于Kubernetes或容器中的命名空间及其应用程序隔离。然后有一个或多个用户映射到帐户。默认情况下，用户可以与同一帐户中的其他用户交换消息。你必须使用服务和流（稍后讨论）来跨帐户共享信息。
nsc工具和帐户服务器的NATS文档很好地反映了这一点。我总共花了3个小时反复阅读、做笔记，并尝试这些示例来充分理解安全模型。有关实现细节，请参阅该文档。另外，为了快速介绍NATS安全模型，Kevin Hoffman关于这个主题的文章也有大量信息可供阅读和消化。
https://medium.com/@KevinHoffman/introduction-to-nats-2-0-security-84098916d2
要存储所有这些安全模型信息，可以使用nsc工具创建的文件结构、内存服务器（用于更静态帐户结构的小型部署）或新的NATS帐户服务器来跟踪用户的安全性。我们将在下面讨论帐户服务器。
NATS 2.0操作员-帐户-用户模型作AuthN和AuthZ
所有这些都有利有弊。没有完美的答案，只有适合你和你的团队的方法。但是我相信有其他选择是好的！这就是为什么我要将服务网格的安全通信与NATS 2.0为你和你的团队所做的事情进行比较。
设置权限和策略
一旦你有了操作员、帐户和用户设置，你现在就可以决定用户权限和用户与帐户之间，以及帐户之间允许的策略。如前所述，使用nsc工具指定用户和帐户。有了操作员、每个操作员的帐户和每个帐户的用户的布局之后，就可以指定允许哪些用户使用帐户，哪些用户不使用帐户。
NATS 2.0还包含了流（Stream）和服务（Service）的概念。在我的脑海中，流是在发布/订阅设置中“我的账户发布的可以到我的账户外部的东西”。当我想到服务时，我想到的是在请求/应答设置中“其他帐户可以从我的帐户请求我将回复的东西”。你可以在公共或私有访问中执行这些操作。
公共访问就是这样 — 你需要知道订阅什么或请求什么。私有访问更符合服务网格中的YAML配置，在这些配置中，你可以限制哪些帐户可以导入导出流。或什么帐户可以请求/回复与另一个帐户内的NATS消息服务器。你还可以进一步限制在帐户下创建的用户只订阅或发布某些主题或通配符场景。
这不仅允许你控制帐户内的消息。它允许你控制用户帐户（这里是指到NATS的客户端连接），以便访问其他帐户中的消息。你可以保护围绕帐户和用户的消息流，以分割应用程序中的流量。
默认情况下，用户帐户对他们在自己的帐户下可以订阅或发布的主题没有限制。使用nsc工具，你还可以限制这一点，并将消息流控制到另一个详细级别，甚至在帐户中也是如此。在“_INBOX.>”上有一些细微差别。在请求/应答消息传送中使用的主题你必须记住这一点。在最新发布的版本中，有一个权限是“仅对回复主题发布”。否则，它在限制消息方面非常简单。NATS文档中的示例，可以帮助你查看和理解这些内容。在部署到生产环境之前，一定要对消息主题应该和不应该接受的所有方式进行测试和重新测试。
NATS 2.0用于发布/订阅和请求/回复的跨账户导出和导入
你必须使用nsc工具的一个单独的命令行接口（CLI）来处理帐户和用户以及目前的权限。（有人告诉我，正在进行工具整合！）根据你在应用程序中所做的操作，你需要知道帐户的公钥才能生成适当的JSON Web令牌。据我所知，目前还没有JSON或YAML文件可以做到这一点。这是在NATS中设置策略与使用服务网格设计的另一个区别。再一次，不是更好或更坏，只是不同。你需要知道这些区别来衡量你的情况、产品、团队和环境能够和应该做什么。
NATS账户服务器和NATS本身的一个非常酷的特性是，它不存储私有密匙、用户数据和秘密用户名/密码组合。我发现那很有趣，而且一开始真的让人难以置信。现在我已经开始了解nsc工具和帐户服务器，我看到他们是如何做到的。这是个很酷的设计。当然，DevSecOps自动化（100%）方面的我仍然需要弄清楚如何将所有这些自动化到一个开发/测试设置中。但是，与在Kubernetes中使用base64编码隐藏秘密，或使用Hashicorp Vault进行秘密管理相比，这是一个不错的惊喜。
NATS帐户服务器的NATS 2.0安全性
使用nsc工具的NATS 2.0允许你创建操作员、帐户和用户，并将其作为权限层次结构来运行NATS消息服务器。将内存解析器用于帐户和用户（或NATS帐户服务器用于大型部署），与NATS消息服务器结合使用TLS进行加密，可以确保消息客户端与NATS服务器之间的安全性。它还允许对消息传递的“谁能做什么”进行授权。我们将在下面讨论一些细节。记住：TLS加密的是通信而不是有效载荷。
有几种方法可以运行NATS帐户服务器（NAS）类型的设置。在这篇文章中，你可以找到NATS的相关文档来学习如何使用。对于我的生产环境，我将运行内存解析器，可以重新加载，而无需服务器重启，如果有变化。NATS服务器使用这些信息启动，因此它知道谁可以对帐户和用户做什么。如果账户和用户有更新，它可以很好地处理。
运行带有TLS和证书的NATS 2.0
除了操作员和帐户之外，NATS文档还显示了在启用了TLS客户端并与TLS连接的情况下运行的服务器的大量信息，从而允许使用对客户端证书和根证书颁发机构（CA）的引用进行加密。如果使用自签名证书或自己的CA服务器，则可能需要CA文件。注意，你必须为服务器和连接到NATS服务器的客户机提供证书文件。
这并不是像使用Istio和Linkerd这样的工具来获得AuthN那样，通过向NATS基础设施中添加“设备”来自动实现的。对我来说，这更像是将HTTPS指定为你想要访问的初始服务，而不是Istio和Linkerd可以提供的服务到服务的相互TLS （mTLS）。所以你必须在这里管理你的证书。
使用TLS和用户凭据作NATS客户端连接
在使用NATS进行加密时，你将在所有客户机和服务器上使用证书。或者按照Colin @ Synadia的说法，在某些环境中更简单的模式是只在NATS服务器中使用服务器端TLS。在与服务器通信时，将其与NATS 2.0凭据结合使用。你必须决定你的需求，并相应地设计/开发/测试/部署。
对我来说，使用Linkerd和Istio等工具管理证书是与NATS 2.0进行比较的关键区别。服务网格使所有通信都通过边车代理，这些代理通过其基础设施工具设置启用了加密块。所以他们管理证书。而NATS需要将服务器和客户端指向要使用的证书。所以你必须管理证书。
使用NATS 2.0提供服务网格的安全性
正如你所看到的，你有一种保护NATS的方法，类似于在你喜欢的服务网格中保护服务通信的方法。两者都提供用于加密的TLS，使用NATS你自己管理服务器和客户端证书。这两种构造都提供了限制服务和服务之间调用的方法。主流工具（Istio、Linkerd等）的服务网格设计通常使用YAML配置文件来完成。NATS使用操作员-帐户-用户模型和他们的nsc工具来排列消息主题，以便发布和请求/回复跨帐户以及用户在帐户内的消息。
这篇文章仅仅是一个介绍，向你展示了NATS 2.0的一些安全方法，你可以使用它们来保护你的通信路径。文章中有许多链接，下面是关于NATS 2.0安全变化和2019年10月可用的各种服务网格软件的介绍。我相信更多的服务网络将会出现。只要确保你阅读了文档，而不仅仅是营销网站和Twitter上的咆哮，这样你就知道如何权衡选择和决定方向。
就我个人而言，我喜欢在可以使用的地方使用更轻的NATS，这是最有意义的。但是我已经使用NATS好几年了，并且了解它的消息模型和事件驱动的应用程序构造，因为我已经使用过它。据我所知，并不是每个人都愿意学习这种发展模式。这里的信息有望帮助你权衡为应用程序提供安全通信的选项，并为你提供生成安全软件和保护通信和数据流的几个备选方案。
NATS和服务网格技术的参考链接
下面是我谈到的软件工具的一般链接。当你读到这篇文章的时候，可能会有更多的服务理念和软件，因为这是我们行业的当前状态。只要确保你阅读了文档看到了真相！
- NATS 2.0：https://nats.io/
- Linkerd 2.0：https://linkerd.io/
- Istio 1.x：https://istio.io/
- Hashicorp Consul：https://www.consul.io/
- Kuma，Kong Service Mesh：https://kuma.io/
感谢Colin Sullivan、Ginger Collison以及Derek Collison。
