许多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 = true
token_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产品如何帮助您构建了令人惊奇的东西?让我们知道。把你的故事或想法发邮件到[email protected]