annexe 1 - approles
When you use tools like Vault to automate the creation and sharing of secrets (includings tokens, certs, etc.),
it could be also interesting to rethink the way thoses secrets are provided to each hosts.
There is already a very interesting article on the Hashicorp blog about using Vault Approles.
In this demo, I try to apply as most as possible the good practices:
credentials, with privileges allowing to create/generate/revoke secrets for different host/resources/people, should never be used (even temporary) on a host: they must stay in a secure host (the bastion for example)
credentials/secrets should not be written in an image
if possible, generic credentials should not be used to avoid impersonation: each host/user should have unique credentials
there are different users to manage credentials:
- one to create the policies/roles/access
- one to provide the public part of the credential (the username or the role ID when using AppRoles)
- one to provide the private part of the credentials (the password or the secret ID when using AppRoles)
In this demo, we have to be able to provide:
- credentials for asking for new SSL certificates (each host has its own certificates but the AppRole Role is the same)
- credentials for asking for new Consul tokens, unique for each host, in order to be part of the Consul cluster
- some secrets (for example the Consul cluster encryption key or the AWS token to call the API for Consul Agent Cloud Auto-join feature)
2. Image creation with Packer
First, an image is created with Packer.
Packer is used to prepare and install everything that does not need per host (or per datacenter, if you don’t want to have differents AMIs in different datacenters) customizations.
As yo can see in the image, the bastion host, that runs Packer, makes all the requests to the Vault-PKI.
It then writes the results on the image being created by Packer.
The host will also need SSL Certificate Authorities, so we copy them from the bastion host.
3. Preparing the host to join the Consul cluster
After the host is started using the previous AMI, we can prepare its accesses to the Consul cluster.
The bastion host makes one more time all the requests in order to create the unique AppRole Role for the host.
4. Host provisioning
The host can be now provisioned.
First, it needs the newly created AppRole Role ID for its unique accesses
Then, it needs the Approle Secrets IDs and all other secrets
Finally, we can let the host itself make some requests because they are unique to it:
- asking for new SSL certs
- asking for new Consul cluster tokens
A lot of tasks are done in Ansible because Terraform providers don’t offer (for now) enough features to do it directly.
I hope more features will be added to be able to do more works in Terraform: that should increase speed and maintanability.