如何保守秘密？ 在存储库中，在部署系统中还是在配置管理系统中？ 在个人计算机上，在服务器上还是在床底的盒子里？ 以及如何管理机密以防止泄漏？
Avito平台信息安全小组负责人Sergey Noskov（ Albibek ）知道这些问题的答案，并将与我们分享。 在Avito，HashiCorp Vault两年来一直在积极使用HashiCorp Vault，在此期间，他们遇到了麻烦，并将经验提升到了“大师”级别。
在本文中，我们将全面讨论Vault：它的用途，在公司中的位置和使用方式，Avito如何使用HashiCorp Vault管理秘密，Puppet和Kubernetes的使用方式，Puppet和其他SCM的用例，出现什么问题，什么会损害安全性和开发人员，当然还有分享解决方案的想法。
什么是秘密？
任何机密信息：
- 登录名和密码，例如，到数据库；
- API密钥
- 服务器证书密钥（* .google.com）
- 客户证书密钥（合作伙伴，Yandex资金，QIWI）；
- 签署移动应用程序的密钥。
我们想要保密的所有信息，我们都称为秘密。 这就产生了一个存储问题：以加密形式存储在存储库中很不好-您需要将加密密钥保存在某个地方。
HashiCorp Vault是解决该问题的很好方法之一。
- 安全地存储和管理密钥。
- 自从微服务本身以来，就在微服务领域变得更加敏锐。
- HashiCorp Vault在验证和授权对机密（例如ACL和最低特权原则）的访问方面做了很多工作。
- 带有JSON的REST接口。
- 安全性不是完美的，但是在相当高的水平上。
我认为，这是一个相当方便的工具。
HashiCorp Vault的新功能
该工具正在开发中，近年来出现了许多有趣的功能：不带中介的GUI的CORS标头； 内置GUI； 与Kubernetes的本地集成; 逻辑和身份验证后端和框架的插件。
我个人最喜欢的更改是
不编写该工具外部的
扩展和添加项的功能。
例如，有一个保管箱，您想要扩展它-编写其他逻辑或您自己的UI自动化，这将使某些东西自动化。 进行更改之前，我不得不提出一个额外的服务，该服务将由Vault处理，并代理所有请求：首先将请求转到服务，然后再发送给Vault。 这是很糟糕的，因为在中间服务中，安全性可能会降低，并且所有秘密都会通过它。
当秘密同时经过多个点时，安全风险会更高！鸡鸡蛋问题
当您提出存储机密信息并决定进行加密的问题时，一旦您对某些内容进行加密，您的机密就会从加密位置转移到存储密钥的位置。 这无时无刻都在发生：一旦您在某个地方保存了一个秘密或更改了现有的秘密，您就会拥有另一个秘密，并且开始迷惑的圈子-
在哪里保存秘密以访问秘密 。
访问秘密的秘密是称为
身份验证的安全性部分。 安全还有另外一部分-
授权。 在授权过程中，将检查用户是否可以准确访问他所请求的位置。 对于Vault，有一个受信任的第三方可以决定是否泄露机密。 授权只能部分解决问题。
阿维托的HashiCorp保险库
在Avito，HashiCorp是整个网络中唯一的大型安装。 HashiCorp Vault具有许多不同的后端。 我们也使用HashiCorp的基于
Consul的后端，因为Vault仅可以通过Consul支持其自身的容错能力。
开封是一种不将主密钥保留在一个位置的方法。 保管箱启动后，它将对密钥上的所有内容进行加密，然后再次出现“鸡与蛋”问题：在哪里保存秘密，这将对所有其他秘密进行加密。 为避免此问题，保险柜提供了一个复合钥匙，该钥匙需要钥匙的多个部分，我们将其分配给多个员工。 在Avito中，我们为7个选项中的3个配置了Unseal，如果我们启动Vault，则必须至少有3个人进入并输入密钥的一部分才能开始工作。 钥匙分为7个部分，您可以随身携带。
我们建立了一个小型测试库，供开发人员在其中玩耍的沙箱。 它采用Docker容器的形式，并创建简单的秘密，以便人们可以用手触摸工具并感到舒适。 沙箱中没有Consul和群集，它只是Vault拥有加密机密的文件系统，还有一个用于初始化的小脚本。
这是我们现在存储在保险柜中的内容：
- Kubernetes微服务几乎所有的秘密：数据库密码，API密钥，以及以上所有内容。
- 放置在“铁”服务器和LXC上的秘密。
- 我们还在Vault的TeamCity中提供了CI / CD构建的秘密。 覆盖率不是100％，但可以接受。
- 所有证书的密钥：内部PKI，外部CA，例如GeoTrust等。
- 团队的共同秘密。
在内部，Vault仅将所有内容存储在JSON中，并不总是很方便，并且需要开发人员采取其他措施，因此基本上我们以文件形式发布机密信息。
我们尝试以文件形式提供机密信息。
我们没有告诉开发人员：“转到保管箱，保密！”，但是将文件放在磁盘上并说：“开发人员，文件将出现在磁盘上，从中获取机密，我们已经弄清楚了如何从保管库中获取并带来它。给你。
我们为JSON字段采用了一个简单的协议，其中指出了上传文件的权限。 这是文件系统的元数据，数据字段是带有密码本身的编码字符串，它将成为文件的内容。
木偶+希拉+保险库
几乎所有的Avito基础架构都使用Puppet，它部署了所有服务器。
Puppet具有用于组织层次结构的便捷工具
-Hiera 。 Vault通过附加模块与Hiera很好地集成，因为键值请求已发送到该库，并且Vault是键值数据库本身，但具有所有安全功能-透明加密和选择键访问的能力。
因此，我们首先实现的是Puppet中的Vault，但有一个附加功能-我们有一个称为
Router backend的中间层。 路由器后端-一个单独的Hiera模块，只是磁盘上的文件，上面写着Hiera应该存放密钥的位置-在保管箱或其他位置。
需要他是为了使Hiera不会一直访问Vault，因为她始终遍历整个层次结构。 这不是Vault的问题或负载，而是Hiera本身的功能。 因此，如果只为Vault保留模块而不保留路由器后端，则Puppet主服务器将花费很长时间收集Puppet代理的配置，因为它将检查Vault中的每个密钥。
对于Puppet，由于授权方是Puppet管理员，因此解决了鸡肉和鸡蛋的问题。 是谁提供了秘密来访问秘密。 Puppet主机可以一次访问所有机密，但每个主机只能接收旨在供其使用的机密。 Puppet主服务器上的主机已经通过其证书授权，该证书是在本地生成的，不会超出主机限制。 原则上，访问机密的机密仍然存在，但这并不是那么关键。
我们在Puppet中揭示新秘密的过程包括以下步骤。
- 我们在某个地方隐瞒秘密-有人将其透露给我们或将其发布。
- 在Vault中放置一个秘密，其层次结构类似于Hiera ： /puppet/role/www/site.ssl.key 。
- 我们在人偶清单中注册了一个前缀，表明该文件在Vault中以及在何处获取。
- 我们在YAML的保管箱中为Hiera路由器和后端编写路径，以便Hiera可以找到它。
- 通过GIT将请求拉到清单存储库。
- 运行或等待Puppet代理运行。
人偶代理每30分钟与我们一起逃跑一次，因此您必须稍等片刻，直到秘密发布为止。 这不会引起问题-
我们不会每天共享秘密 。 只要不参与Kubernetes的业务，就不会有太多开销，并且我们准备用最少的自动化就可以在Vault中保密。
另外，我们还获得了“芯片” Hiera-
可以立即为一组主机或根据
主机角色（将角色设置为可变角色）
布置秘密 。
唯一的
危险 ：如果您拥有Puppet并且使用了Hiera，请不要用任何方式替代变量模板，因为许多事实和变量都是在客户端收集的。 如果攻击者将事实替换为客户，则master大师将向他提供其他人的秘密。
确保检查变量 ：仅使用Puppet主服务器不允许在客户端确定
的变量 。
在没有向导的情况下如何处理SCM？
如果突然之间您没有Puppet，那么很可能是Ansible。 对于Chef和其他集中式SCM，它们的解决方案是可以访问Vault的插件。 我提供了可以使用Ansible实现的几个选项。
本地代理商
在服务器本地生成一个令牌，该令牌实际上是访问Vault的密码。 令牌正在进行中。 您可以对其进行更新或自动化。 使用此令牌，您可以进入保险柜并带走您的秘密。
这个想法是，在您需要传递机密的服务器上，Vault附带的代理正在旋转，它查看所有机密并将其以文件的形式放置。 我们在没有Puppet的几台单独服务器上使用代理。
缺点：- 令牌很容易在很小的范围内输入，但是如果您每天部署几十个服务器，则必须为每个服务器生成一个令牌并规定一个策略。 这很不方便。
- 令牌需要更新。
- 按角色，目的或事实对服务器进行分组很困难，必须将其与保管库同步。
传输加密
Vault具有传输加密功能，其本质是Vault充当
加密服务器 。 您只给他带了纯文本，然后他用他只有的私钥对它加密并发出封闭的文本。 然后，您可以选择谁可以解密此封闭文本。
Ansible有一个实体，也称为Vault。 这不是HashiCorp保险库，而是
Ansible保险库 。 无需混淆，秘密可以存储在第一个和第二个中。 Ansible有一个现成的插件，用于从Hashicorp Vault传递秘密。 如果您授予对保险柜的个人访问权限，则可以解密机密。 当您滚动Ansible时，它将代表您转到Vault，解密存储库中加密的机密，并将其投入生产。
还有一个缺点-
每个管理员都可以访问机密 。 但是需要进行审核：保险柜知道如何保存活动日志，以记录有关哪些用户进入，他们阅读了什么秘密以及哪些用户可以访问的信息。 您总是知道谁，什么时候和什么秘密。 这个选项对我来说似乎很好。
大缺陷＃1
给我们造成最大痛苦的最大缺点是，在Vault中，您无法
将对 数据的任何
部分的完全控制权委派给任何人。 在Vault中，以类似于UNIX中的方式来访问机密-名称通常用斜杠分隔，结果是“目录”。 当您拥有这样的路径时，有时您希望参与其中，并将其交给其他人进行控制。
例如，您获得了名为
/ certs的证书 ，并且想要将其交给与PKI进行交易的各个安全人员。 保管箱无法执行此操作。 您不能在此前缀内授予发布权限的权利-以便安全卫士自己可以将证书的权利分发给其他人。
保管库没有能力选择性地授予权利以授予权利 。 一旦您授予了授予权利的权利，您就也有机会获得对所有机密的完全访问权限。 换句话说，您不能授予对保管库零件的访问权限。
这是最大的问题之一。 我有一个解决方法的想法，稍后再告诉您。
Kubernetes
在RIT ++上，我
谈到了我们为
Kubernetes实现的单独系统：它充当第三方，使用API，检查访问权限，然后在Vault中请求密码。
现在我们的系统失去了相关性，因为在Vault 0.9中，已经出现了对Kubernetes的本机支持。 现在，保险柜本人知道如何访问Kubernetes，并确保允许访问机密。 他使用
服务帐户令牌进行此操作 。 例如，当您推出一个Pod时，会有一个专用的，经过签名和授权的
JWT ，专门用于向Kubernetes API发出请求。 使用令牌，您还可以登录Vault并获取专门针对您的命名空间的机密。
一切都在Vault本身的级别完成。 没错，有必要为每个名称空间启动一个角色，也就是说，告诉Vault有这样一个名称空间，其中将有授权，并注册进入Kubernetes的位置。 完成一次，然后Vault将转到API本身，确认JWT的有效性并颁发其自己的访问令牌。
Kubernetes规则
在服务名称和其他元数据方面，我们信任开发人员。 开发人员极有可能偶然或有意获得在一个名称空间中旋转的其他服务的秘密，因此我们引入了一条规则：
一个服务 -
一个名称空间。新的微服务？ 使用您的秘密获取新的名称空间。 您不能越过边界到达相邻的边界-它们拥有自己的服务帐户令牌。
目前，Kubernetes的安全领域是名称空间。 如果在两个不同的命名空间中，您需要一个秘密-复制它。
Kubernetes具有
kubernetes的秘密 。 它们以未加密的形式存储在Kubernetes中的etcd中，并且可以在仪表板中或启动kubectl get pod时“点亮”。 如果在群集中禁用了etcd中的身份验证，或者您为某人提供了完全的只读访问权限，则所有机密对他都是可见的。 这就是为什么我们引入了两个规则的原因：
禁止使用kubernetes机密 ，并且
禁止在清单中的环境变量中指定机密 。 如果您在Deployment.yaml中的环境中编写一个秘密，这很不好，因为清单文件本身可以被任何不懒惰的人看到。
Kubernetes交付
正如我所说，我们必须以某种方式将文件放入Kubernetes。 我们有一个秘密：密码（本质是密码），该密码在Vault中以JSON编写。 现在如何在Kubernetes中将其转换为容器内的文件？
第一个交付选项。
- 我们开始一个特殊的初始化容器。
- 它从我们的形象开始。
- 该映像包含一个小型实用程序，该实用程序将使用服务帐户令牌转到保管库，获取机密并将其放入共享卷中。
- 对于实用程序，仅在TMPFS内存中安装特殊的共享卷，以使机密不会通过磁盘。
- 初始化容器转到保管库，以文件形式将在指定路径中找到的所有机密信息放入该卷中。
- 接下来，将共享卷安装在需要它的主容器中。
- 启动主容器后，它将立即获得开发人员需要的内容-磁盘上文件形式的秘密。
开发人员只需记住他的秘密所在的道路。
我们使用以下前缀：
/k8s/<cluster>/<namespace>/<service>/some_secret
前缀名称包含集群名称，名称空间和服务名称。 每个服务都有自己的秘密，每个名称空间都有自己的秘密。
第二个选项是您
自己的入口点 。 我们现在在Avito中转移到它，因为开发人员在使用init-container时遇到了问题。 在图中，此选项在右侧。
并非每个人都能负担得起自己的切入点。 我们可以，所以在每个容器中我们都强制使用特殊的入口点。
我们的入口点与init-container的作用相同：它通过服务帐户令牌转到Vault，获取秘密并将其发布出去。 除了文件之外，他还把它们放回了环境中。 您将有机会按照“
十二要素应用程序”概念的建议运行该应用
程序 ：该应用程序从环境变量获取所有设置，包括机密信息。
环境变量在清单和仪表板中不可见，因为它们是在启动时由PID 1（主容器进程）设置的。 这些不是Deployment.yaml中的环境变量，而是进程中入口点设置的环境变量。 它们在仪表板上不可见，即使您在容器中使kubectl exec也不可见，因为在这种情况下，将启动另一个与PID1并行的进程。
工作流程
从组织的角度来看，该过程如下。 开发人员从安全支持者或文档中了解到，他不应在存储库中保守秘密，而应仅在Vault中。 然后他来找我们，问在哪里放秘密-他向安全提交了一个建立前缀的申请。 将来，您可以在创建服务时立即创建没有请求的前缀。
开发人员正在等待，这很糟糕，因为 对他来说，最主要的是上市时间。 然后，他阅读说明，处理长文件-“在此插入行，在此插入行”。 开发人员以前从未启动过init-container，但是他被迫弄清该问题并将其注册到deployment.yaml（头盔图表）中。
Commit -> deploy -> feel pain -> fix -> repeat它提交，等待TeamCity推出，看到TeamCity中的错误，开始感到痛苦，尝试修复某些问题，再次经历痛苦。 此外，叠加起来，TeamCity中的每个部署仍可以排队。 有时，开发人员无法自己弄清楚，而是找我们，然后我们一起整理。
基本上，开发人员会因自己的错误而受苦：
错误地指定了init-container或未阅读文档 。
安全也有问题。 安全卫士收到的应用程序中几乎总是没有什么信息，我们仍然找出缺少的问题：找出集群的名称，服务的名称空间，因为开发人员没有在应用程序中指出它们，甚至不总是知道它是什么。 当我们找到所有内容，在Vault中创建策略和角色，为组指定策略并与开发人员一起时，我们开始找出他在哪里以及为什么出错了，并一起阅读日志。
“架构”单元通过对Deployment.yaml开发人员隐藏来帮助解决问题。 他们正在开发一块为开发人员生成所有东西的工具，包括入口点。 由于我们替代了入口点，因此我们不仅可以使用它来传递秘密，还可以将其用于启动时可能需要执行的其他操作。
Kubernetes机密的明显问题。
- 开发人员和安全防护人员的工作流程都非常复杂 。
- 您不能将任何内容委托给任何人。 安全卫士具有对保险柜的完全访问权限，并且无法部分访问（请参阅大缺陷＃1）。
- 当需要共享机密时，在将开发人员从一个群集移动到另一个群集，从一个名称空间移到另一个名称空间时会遇到困难，因为最初假定不同的群集中不同的秘密是不同的。
我们说：“为什么在开发集群中需要生产机密？ 获取测试秘诀，顺其自然！” 结果，存在难以管理的
地雷 和秘密 。 如果机密已更改，则您一定不要忘记它，在任何地方都应进行更改，并且除非通过服务名称，否则无法确定它是相同的机密。
想法：Kubernetes KMS
在新版本的Kubernetes中，KMS子系统密钥管理服务是Kubernetes的新秘密加密功能。 在v1.11中，它处于Alpha状态；在v1.12中，它已转换为Beta。
该图片来自Vault的KMS提供程序项目站点，并且上面有错误。 如果找到-在评论中写。KMS的意思是消除一个单一的缺陷-etcd中未加密的数据存储。
像Ansible一样，KMS可以做到这一点。
- 到某个地方，对Kubernetes本地机密进行加密，然后将其以加密形式保存。
- 如有必要，将其传递到Pod，解密并以解密形式放置。
开发人员已编写了一种特殊的服务，该服务使用传输加密来执行此操作。 这个想法似乎行得通，但是请务必记住，秘密不再仅由Vault控制，而是转移到Kubernetes管理员负责的其他地方。
缺点KMS。
- 存储分散化 - 从保管库到Kubernetes（etcd）的接管 。 保管库变得无法控制机密，它可以用作机密的集中存储库。 事实证明，保险柜中有一半秘密，其他地方有一半。
- 仅Kubernetes的解决方案 。 如果您拥有仅Kubernetes的基础架构，则可以选择Vault，并且几乎不认为存储在其中的内容是因为 它仅包含您正确管理的加密密钥-定期旋转等。...秘密本身在Kubernetes中，这很方便。
- 集群之间很难共享秘密 。 对于每个新群集，您都需要重新开始，复制机密（如使用单个保管库的情况）可能不起作用。
KMS的优点。
- Kubernetes的本地支持 ，包括在显示环境时隐藏。
- Kubernetes责任区的授权 。
- 几乎不需要保管库支持 。
- 开箱即用的钥匙旋转 。
CI / CD：TeamCity
在TeamCity中，一切都很简单，因为JetBrains编写了一个插件，该插件本身可以规定用于访问秘密的秘密，使用TeamCity对其进行加密，然后将其替换为模板中某个位置的百分比参数。 此时，TeamCity代理本身会转到Vault，获取机密并将其作为参数带入内部版本。
部署过程中需要一些秘密，例如数据库迁移或Slack中的警报。 每个项目都会启动AppRole-设置还包含一个机密（AppRole的数据），但以仅写模式输入-TeamCity不允许以后读取它。
TeamCity自身会注意，当机密信息输入构建日志时，它会自动伪装自己。 结果，机密要么根本不“通过”磁盘，要么使用TeamCity工具从磁盘清除。 结果，TeamCity本身和插件很好地确保了秘密的所有安全性，并且不需要额外的铃鼓跳舞
CI / CD不是TeamCity吗？
如果您使用其他系统（而非TeamCity）作为CI，则这些是要考虑的主要问题。
- 隔离：将机密范围限制为项目，团队等。
- 谁授权访问秘密。
- 排除查看授权方秘密的能力。
- 构建的另一个阶段是将机密导入文件中。
- 自己清理一下。
结果，很可能您会为CI / CD编写与TeamCity插件非常相似的内容。 这里的授权方很可能是CI / CD，由她来决定此构建版本是否可以访问此机密，以及是否根据结果自行提供机密。
重要的是，不要忘记
在组装结束时清理构建结果（如果将它们布置在磁盘上），或者确保它们仅在内存中。
资质认证
证书没有什么特别的-我们主要使用保险柜来存储证书。
保管箱具有用于颁发证书的特殊PKI后端，您可以在其中创建证书颁发机构并签署新证书。 我们只有一个内部PKI ...根CA和第二级CA分别存在，并且我们已经通过Vault管理第三级CA。 为了存储任何级别的已发行证书，包括由外部CA签名的证书，我们使用单独的前缀，并在其中放置几乎所有有效证书以进行记帐和监视。 存储证书的格式是专有的，适用于存储单独的私钥和证书本身。
总结
尽管我真的很想...但是对于安全卫士来说，
手工工作 太多了，对开发人员来说门槛太高了，并且没有内置的委派工具。
如何成为 然后，梦想开始了。
想法：如何做得更好
如何摆脱一堆秘密？
交付主从
我们有一个主密钥和一个特殊的守护程序，该守护程序四处走动，查看该密钥及其元数据，将其放在必要的地方，结果是一个从机密钥。 在守护程序发布从属服务器的方式上，无法进行任何手动更改，因为守护程序将过来并将主密钥重新放置在从属服务器上。
最初，我们想建立一个符号链接机制来简单地指出：“在Linux上寻找这个秘密！”。 事实证明，访问权限存在问题：不知道如何检查访问权限-不管是否在Linux上，使用父路径，以及在安装点之间进行转换。 错误的时刻和机会太多了，因此我们拒绝了符号链接。
所有权授权
我们要做的第二件事是
确定每个秘密的所有者 。 默认情况下，秘密属于创建它的人。 如有必要，您可以通过发布所有者组将职责范围扩展到单位。
当我们学习委托时，我们将授予所有者秘密的权利，并且他将能够使用他想要的秘密。
- 散布在k8s中-生成策略，创建从属副本。
- 在服务器上传播-生成策略，创建从属副本。
- 传播在CI / CD中...
- 转让给另一个所有者。
- 赋予新的访问权限，生成新的ACL。
现在，我们对所有机密和安全性负责，但我们希望将责任转移给创建者。
安全不会受到影响 ，因为向我们提出保密要求的人知道他需要安全保密，并且知道自己的责任。
由于他是机密的所有者，因此对于主从传递选项，他可以选择将机密传递给他的位置和格式。 事实证明，所有者自己管理一切，无需提交申请，您可以自己添加必要的前缀，还可以自己创建和删除机密。
通过ACL模板进行委派
保险柜中的访问控制列表访问策略分为两个部分：
- 经典视图中的访问控制列表，它描述对前缀的访问，哪种读取和写入方式，哪些只能读取等。
- 在内部创建ACL时，您可以在末尾写一个星号，表示“此前缀及其下的所有内容”。 可以将前缀分配为单独的操作，赋予用户或组，即附加到几个不同的实体。
目前，只有保险柜管理员可以更改ACL。 获得了对此类ACL的访问权限后，您可以在其中指定所需的所有内容，例如，
path “*” { capabilities = [sudo, ...] }并获得完全访问权限。 这是
最大缺陷 1的本质-
无法禁止更改 ACL 的 内容。我们要使用现成的模板设置ACL，该模板包含允许在其上为此模板生成新ACL的路径和占位符。
例子
下面是黄色字体，来自Vault的完成的标准ACL的路径，以及该路径上允许的操作。 我们将其视为允许以下更改另一个ACL的ACL，它以模板的形式给出。
我们要委派对/ k8s的访问，我们只允许生成此类模板。 例如，授予对特定群集，名称空间，服务的只读访问权限，但不要更改功能字段。
此外，我们想授予绑定这些ACL的权限并发出不同的权限。
我们应用了模板向开发人员授予权利。 进行模板制作时，他运行
$ vault write policy-mgr/create/k8s-microservice ... 。 结果，我们得到了一个ACL，它声明cluster = prod，namespace = ...，service = ...等。 权限是自动设置的，使用
/k8s/some-srv名称创建了一个策略-这只是可以从模板生成的ACL名称。
结果，开发人员可以根据自己的判断将此ACL分配给任何想要的人，并成为所有者本人，可以作为秘密来管理它：删除，放弃用户和组。 现在，此人本人负责其前缀：他管理所有机密信息，根据模板生成ACL，可以将ACL分配给他想要的人。 当然，我们也可以限制它。
所有魔术都可以与新的Vault实体
插件一起使用 。 它们是一项单独的服务，与我一开始提到的服务非常相似，并且工作几乎完全相同。 唯一重要的区别是它们不是代理。 插件在Vault的“侧面”启动，并启动其主要Vault流程。 因此，所有请求都不会通过服务，而是通过保管库，该保管库本身已经与插件进行交互，并向其发送经过验证和清除的请求。
关于插件，插件的排列方式和编写方式，您可以
在Vault网站上阅读。 最好在Go上编写它们，这很简单，因为 Go有一个框架。 保险柜通过grpc与插件进行通信，将其作为服务启动，但是请不要害怕，您不必动手-框架中已经包含了所有内容。 您只需要编写一个或多或少的标准REST应用程序，即可在其中指定端点，为它们提供现成的函数以及在其上具有逻辑的处理程序。
不要担心会破坏主保险库中的东西。 插件是一项单独的服务。 即使您的插件惊慌并崩溃了，它也不会破坏Vault的工作。 保管箱将简单地重新启动插件并继续工作。
此外，插件本身还有其他设置：它始终检查哈希值，因此没有人更改二进制文件。
提供了运行插件的安全性 。
有用的链接：
我们将讨论DevOps和安全性，CI / CD，k8s，Puppet以及HighLoad ++ （4月在圣彼得堡最接近）和DevOpsConf中的所有内容 。 快来分享您的经验或看看其他人。 为了避免忘记，请订阅博客和时事通讯 ，我们将在其中提醒您截止日期并收集有用的材料。