使用Vault

以前曾经介绍过关于 KMS的用法 ，其中，提到了它的优点和用处，我们使用的场景有如下几点:

如果脱离AWS，选择好像还真是不太多，Harshicorp的 Vault 是我仅知道的一个， RatticDB 算半个吧。

Vault提供了对token，密码，证书，API key等的安全存储(key/value)和控制，。它能处理key的续租、撤销、审计等功能。通过API访问可以获取到加密保存的密码、ssh key、X.509的certs等。它的特性包括:

因为使用Vault的目的是为了

Vault存储[backend( https://www.vaultproject.io/docs/secrets/index.html)] 可以是

我在用Docker启动Vault服务的时候使用的Production模式，为了简单使用了磁盘作为存储，但是为了persist，所以将valut的文件存在了docker volume上面。

docker-compose 文件如下:

创建volume，启动vault服务器，配置通过环境变量 VAULT_LOCAL_CONFIG 传入。

从本地的 8200 端口应该就可以访问到了:

下面的API请求可以对Vault进行初始化，两个参数的意思将master key分成几份以及还原，这里就用1吧。

返回结果:

第一个是master key的public key，第二个是unseal key,最后一个是root token。unseal vault之后才能验证进行具体的操作。

结果:

为了安全起见，我们可以用root token创建出有限权限的新token，来继续后面的操作。假设这个token可以读写的路径为 secret/* 。在这个之前我们先创建访问这个路径的policy:

对应的创建 user-policy :

然后我们分别创建两个token，admin token和 user token:

这样就有了对于 secrets/* 路径下进行读写的两个 token，可以尝试去admin的token去添加新的键值对:

这样就有了基本的权限管理。假设vault服务器和应用服务器或者CI的服务器部署在同一私有网络中，应用服务器和CI slave是不可以ssh的，那么通过应用服务器或者CI在启动的时候通过HTTP请求，利用读权限的 user-token 就可以拿到API-TOKEN，同时没有暴露给外部。

AWS的EC2 instance上可以绑定 instanceProfile , instanceProfile对应的是IAM的role，这个role可以设置对AWS资源的访问权限，比如对S3某个bucket的写权限，或者对Dynamodb的写权限等。Vault提供的AppRoles的功能比 instanceProfile 要差很多，不过确实可以将机器和一定权限的Role绑定起来，控制访问的范围。

允许使用approle的验证方式同时创建一个给CI slave使用的role:

下面的API请求可以拿到 role-id ，以及根据 role-id 生成 secret-id ，利用它们可以登录获得从vault读取数据的权限:

使用 secret_id 和 role_id 联合登录，拿到新的token:

然后利用 client_token 去读取前面写入到vault中的search api token:

AWS的EC2 instance的服务器，在启动时，可以绑定一对ssh keypair，以方便用户使用缺省的 ec2-user ssh到服务器上。从最佳实践的角度来说，应该把服务器当做immutable的设施，不允许ssh。但是现实比较嘲讽，这样的需求仍然存在，那么我们可以换种方式，尽量做好ssh key的管理。

比如，对于每个新启动的服务器，动态的生成一对ssh keypair，只应用在这台服务器上，服务器销毁后，吊销key pair。

Vault提供了ssh keypair的管理功能，利用这个功能我们可以对key的生命周期的管理。它支持两种方式:

要让vault发放keypair, 需要先注册一个private key，这个key必须有服务器的管理权限.之后，你需要创建一个role，包括一些限定条件，如admin用户的名字，缺省用户，目标服务器的IP地址应该匹配的CIDR地址，具体过程如下:

整个的过程大概是这样，vault利用注册的private key登陆到目标服务器上，然后将新生成的key pair中的public key写入到目标服务器的 authorized_keys 文件中。在你想登陆到服务器上的时候，用对应的client token验证，获取private key，ssh登陆。key有过期时间，过期之后就被revoke了。

我觉得全站https困难之一就在于PKI的管理，今年出现过几次certficate过期导致的产品环境的问题，还好及时的切换到了AWS Certificate Manager，免费而且到期自动续租，基本上不用担心管理的问题了。而我们原有的内部PKI管理要稍微麻烦些，需要用自己业务线的LOB Intermediate CA去签发新的certs，运行一些自动化的脚本，还得从RatticDB里面找到对应的private key。

但是如果基础设施不是基于AWS，好像就没有很合适的工具了，只能自己维护PKI，Vault也提供了PKI的管理，可以在这方面提供帮助。考虑环境的一致性，开发、测试以及staging也需要certificate，我觉得这个功能是有意义的。

Vault会安全的保存Root CA 的private key。 可以通过http请求拿到ca的pem文件。

需要给Vault配置访问CA和CRL(certificate revocation list)的地址。

创建intermediate CA.

把这个csr内容存在 example_lob.csr 文件中，请求root ca签发这个intermediate ca。

得到Root CA的签发过的intermediate CA certs后，保存为文件，导入。最后就是要设置CA/CRL，和上面相同。

在开始给server签发certs前，需要创建role，之后就可以签发了。

拿到private key和crt就可以放在服务器上测试了，感觉用这个 grunt-connect-proxy 测试起来可能会快点。

Vault还有一个我觉得很好的特性是可以将LDAP作为auth的backend，感觉维护的压力又小了很多:) 剩下的特性大家可以自己尝试，我们也正在考虑把替换RatticDB保存一些private key之类的credential，下次的security meetup上面我可以展示下spike的成果……。

首先做好Vault服务器的安装与配置，然后修改原有的INV项目至Vault项目，设置、映射目录，再将所有的项目文件检入到服务器。这个还是要有一定的经验才能做好，特别是的Vault项目。INV项目文件设计不好就会带来很多问题，Vault项目设计的时候更要注意了。

---