关于如何在Nomad中保护工作部署的工作流的简要历史

许多HashiCorp用户和员工都喜欢我们的整套产品，但就像您的祖母一样，几乎不可能不对我们的某一个产品有一点偏爱(最喜欢的孙子说)。

在我的例子中，我对HashiCorp Nomad的偏爱是很明显的，甚至在欧洲团队中是一个持续的笑话。我想，每一次客户会议都会有人说:“是啊，这就是Nomad, Nico最喜欢的产品……”

因此，你可以想象我的兴奋之情，去年9月，Armon 上台公开宣布了Nomad 0.7发布的过多特性。我终于对企业调度程序有了完整的认识。配额和命名空间将企业客户本来就很低的操作开销降至最低，ACLs将提供对开放源码用户的安全访问。关于最后一点，就在我拍摄这张照片的时候，我有了一个短暂的顿悟(并没有很多人有这些照片的真实记录)。一个团队如何运作ACLs?

• 操作人员可以为进行部署的用户和系统(如CI管道)创建长寿命的令牌。绝对不会。
• 共享令牌?别让我开始。
• 为用户构建LDAP集成，为机器构建长时间使用的令牌。听起来有很多工作要做。

如果我们有一种能够代理凭证访问的技术，并且已经有了一种方法，可以使用LDAP(用于用户)和EC2工作人员(在技术上也可以在Nomad中运行)来建立身份。等等，我们的确有一些东西能做到。HashiCorp Vault实际上是最合适的选择。我已经在脑子里玩这些流程了:

用户使用LDAP对Vault进行身份验证，获得Vault令牌

该Vault令牌与特定的Vault策略绑定在一起，而该策略又与Vault中可以使用精确的Nomad策略生成Nomad令牌的路径绑定在一起。

用户请求一个具有较短过期时间的Nomad令牌

根据需要与Nomad交互

幸福:D

只有一个小问题，我们(当时)没有一个Nomad的Secret引擎。关于这家公司，你肯定需要知道的一点是，一个好的想法永远都是不够的，你需要执行它。因此，由于缺乏Vault的内部知识，而且从未写过一行Go，我就去了。

结果证明了Vault是多么的神奇，就在我编写代码的时候，这个东西似乎在工作，大约3个小时后，Vault实际上生成并撤销了Nomad标记。稍后的长代码回顾(https://github.com/hashicorp/vault/pull/3401)将秘密引擎合并到0.9.1中。让我们快速看看如何快速设置它。

当然，ACLs需要通过配置文件中的acl节在Nomad中启用:

acl {enabled = truetoken_ttl = "30s"policy_ttl = "60s" }

应该为ACLs引导集群，并且应该有一个初始管理令牌。值得注意的是，初始管理令牌可以被撤销，但它可能会修改子令牌，所以您很可能不想将该令牌交给Vault，而是生成一个可以独立管理的子令牌:

$ NOMAD_TOKEN=${INITIAL MANAGEMENT TOKEN} nomad acl token create -type=management Accessor ID = 5f7d8875-1bf9-ed80-c8c3-e4e6e20c2408 Secret ID = ea83681b-9ca8-4393-999f-a25731ad3b55 Name = <none> Type = management Global = false Policies = n/a Create Time = 2018-03-17 11:36:12.696245 +0000 UTC Create Index = 8 Modify Index = 8

您还应该在Nomad中创建一组策略，因为Vault将利用这些策略最终创建令牌，在本例中，您可以创建一个示例策略，如下所示:

namespace "default" {policy = "read" } agent {policy = "read" } node {policy = "read" }

并将其引入Nomad:

$ NOMAD_TOKEN=${INITIAL MANAGEMENT TOKEN} nomad acl policy apply policyone ./payload.json Successfully wrote "policyone" ACL policy!

现在开始配置Vault。首先将nomad秘密引擎安装到一个挂载点，并配置到nomad的连接:

$ vault mount nomad Successfully mounted 'nomad' at 'nomad'! $ vault write nomad/config/access \address=http://127.0.0.1:4646 \token=adf4238a-882b-9ddc-4a9d-5b6758e4159e Success! Data written to: nomad/config/access

现在在Vault中创建一个角色来发布与我们刚刚创建的Nomad策略相关联的Nomad标记:

$ vault write nomad/role/role-name policy=policyone Success! Data written to: nomad/roles/role-name

以及一个Vault策略，用于生成Vault令牌，允许在此角色中创建Nomad令牌:

$ echo 'path "nomad/creds/role-name" {capabilities = ["read"] }' | vault policy-write nomad-user-policy - Policy 'nomad-user-policy' written.

例如，作为最后一步，您可以只生成一个与策略相关联的Vault令牌，并检索一个Nomad令牌，如下所示:

$ vault token-create -policy=nomad-user-policy Key Value --- ----- token deedfa83-99b5-34a1-278d-e8fb76809a5b token_accessor fd185371-7d80-8011-4f45-1bb3af2c2733 token_duration 768h0m0s token_renewable true token_policies [default nomad-user-policy] $ vault read nomad/creds/role-name Key Value --- ----- lease_id nomad/creds/test/6fb22e25-0cd1-b4c9-494e-aba330c317b9 lease_duration 768h0m0s lease_renewable true accessor_id 10b8fb49-7024-2126-8683-ab355b581db2 secret_id 8898d19c-e5b3-35e4-649e-4153d63fbea9

这种技术可以与任何通过Vault进行身份验证的东西结合使用，最终为Nomad管理和调度提供一个非常安全的工作流。

您是否有兴趣告诉别人您的HashiCorp故事，或者HashiCorp产品如何帮助您构建了令人惊奇的东西?让我们知道。把你的故事或想法发邮件到guestblogs@hashicorp.com

总结

以上是生活随笔为你收集整理的关于如何在Nomad中保护工作部署的工作流的简要历史的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。