Vault: Trying to understand approle

[gtmtech]

Forgive me if there is a better place to raise and understand this such as a forum, but is it possible to get help on the following? It also may help others coming across a similar situation.

I am trying to understand in the Pull model of AppRole based authentication, which actor is best placed to generate a wrapped secret-id.

My use case is I wish to bootstrap a simple jenkins server which requires the set up of some secrets which I wish to store in vault. I'm using AWS, Packer, Terraform and Vault together

As I understand it, in order for the jenkins server when booted up to be able to pull secrets out of vault it needs access to a role-id and a secret-id. Best practice suggests including both, using the pull model and using Response wrapping.

So as a human operator, I first of all generate a role-id:

vault write auth/approle/role/jenkins_slave bind_secret_id=true \
                                            secret_id_ttl=10m \
                                            secret_id_num_uses=99999 \
                                            token_ttl=10m \
                                            tokenmax_ttl=10m \
                                            policies=jenkins_slave

I can then read the role-id with:

role_id_jenkins_slave=$( vault read -format=json auth/approle/role/jenkins_slave/role-id | jq -r '.data | .role_id' )

Now I write the role-id into configuration management (e.g. ansible), and packer build an AMI with the role-id baked in. When the AMI spins up, it will know one side of the tuple

Now I need to generate a secret-id. However using the pull model and response wrapping, i dont wish to expose the secret-id anywhere. So this is the command that should be run:

vault write -wrap-ttl=60s -f auth/approle/role/jenkins_slave/secret-id

However, my question is, what should do this? I can eliminate some actors from the list:

• It cant be the EC2 instance itself when spun up, because it would need to be authenticated in order to call this secret-id api endpoint, so it must have been done before the EC2 instance spins up
• It cant be done by the operator and put into ansible/packer, because the unwrap() function can only happen once, and this means the AMI could only be instantiated once.
• It must have to be done between the AMI bake phase and the EC2 launch phase, which means it must have to either be part of EC2 launch metadata (user-data), or when the EC2 instance spins up, it requests a secret-id from some other daemon which is preauthenticated with vault and can supply it a secret-id.

User-data is the obvious choice, so I assumed (being a user of Terraform) that terraform would be able to supply user-data containing a wrapped secret-id. - but terraform has no integration with vault's approle function, because approle is a POST operation and terraform only supports write with PUT/DELETE operations > https://www.terraform.io/docs/providers/vault/r/generic_secret.html

However, even supposing there WAS a terraform way of injecting the wrapped secret-id into the ec2 instance, the ec2 instance when spun up could not itself unwrap the response-wrapped secret-id in order to login to vault, because:

ec2-instance:

$ vault unwrap 3b7a4930-4ce5-c8ba-7522-228e0ac4ebc2
Error making API request.
...
* permission denied

In other words, the instance needs to be authenticated in order to unwrap the secret-id.

Could the authors pour some light on how this should work? Who should be creating the secret-id (the operator? an automated script at terraform time? an automated script at ec2 spinup time? a separate daemon?) and how to distribute it to the newly spun-up instance so that it is able to log in (according to best practice).

I'm a bit confused, sorry

[gtmtech]

For those following, I reposted this on https://groups.google.com/forum/#!topic/vault-tool/Y7QaQaBM3fo

[gtmtech]

@vishalnayak , I read your excellent post on google-groups, so you clearly know a lot about this.

https://groups.google.com/forum/#!topic/vault-tool/1yf-oqgLnec

I raised https://github.com/hashicorp/terraform/issues/12687 over at terraform as I think it is the most appropriate place for generating secret-ids. Would be interested to hear your thoughts

[samizadsom]

@gtmtech did you ever get a resolution to your #128687?