AppRole help(!) Unwrapping a secret needed for authentication when youre not authenticated...

[ge...@gtmtech.co.uk]

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 am using AWS, Packer, Ansible, Terraform and Vault. I wish to create an AMI of a simple server which when spun up will fetch a secret from vault in order to run some software. The server will be part of an autoscaling group so everything needs automating. The required secret is already in vault.

As I understand it, in order for the server EC2 instance when booted up to be able to pull secrets out of vault it needs access to a role-id and a secret-id, so that it can perform the vault approle login function. 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/myappserver bind_secret_id=true \
                                          secret_id_ttl=10m \
                                          secret_id_num_uses=99999 \
                                          token_ttl=10m \
                                          tokenmax_ttl=10m \
                                          policies=myappserver

I can then read the role-id with:

role_id_myappserver=$( vault read -format=json auth/approle/role/myappserver/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 an EC2 instance based on this AMI spins up as part of the auto-scaling-group, it will know one side of the tuple. Great!

Now I need to generate a secret-id - the other side of the tuple. However reading the documentation, they advise using pull model, with response wrapping, so as not to expose the secret-id anywhere. So here is an example command that needs to be run by something:

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

However, my question is, who should do this, and how should the wrapped secret-id be distributed? I can eliminate some possibilities from the list:

• It cant be the EC2 instance itself when spun up, because it would need to be authenticated in order to run this command, 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 generated by terraform. - 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, and here is the crux of the matter!!!-- 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 anyone 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).

Any help gratefully received!

[Vishal Nayak]

Hi Geoff,

There is no best practice around this since it's really up to the
convenience of users.

Requesting secret-id from another service which is pre-authenticated
to create them seems reasonable.

Also, if you inject/import a wrapped secret-id into the EC2 instance,
it *can* unwrap the secret-id all by itself.

In your example, `vault unwrap 3b7a4930-4ce5-c8ba-7522-228e0ac4ebc2`,
the authenticated token might not have the permissions to unwrap (not
sure why since the `default` policies allows it). The wrapped token
itself will have the permissions to unwrap itself. Hence,
`VAULT_TOKEN=<wrapping_token> vault unwrap` should work.

Hope this helps!

Regards,
Vishal

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/84ab8fcb-f0ef-49cd-b7b0-baeb3a6e18cf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
vn