AppRole authentication can be used to separate app based login capabilities for applications. For example, access to app1 secrets can be mapped to App1 AppRole. We can use the
roleID of the related role and the generated
secretID for it which will then be used by an app for login purposes for accessing app secrets. The gist of it is as below.
Let’s see it in action.
First we need to enable approle auth. See here for details on enabling an authentication method.
Name it something non-default to see non default endpoints more clearly and to make life more miserable.
After this, our business with the UI is apparently at an end. We will continue with the CLI to create roles
Before that though, we need a policy for our appRole (details on policies are here). Below policy should be good enough for a start. It allows all capabilities on secret engines with root dirs starting with t1. Create a kv engine with a directory that starts with t1 (e.g. t1/secrets) if you don’t have one yet.
capabilities = ["create","update","delete","read","list"]
We now need to attach this policy to an approle. We are creating one named
testapprole1 with the
testapp-pol policy attached.
vault write auth/approle-test/role/testapprole1 token_policies="testapp-pol"
Note: In the above command we can add additional attributes like token_ttl, secret_id_num_uses to limit what an approle secret-id can do.
Policy is now attached and we can read the role-id of our new role with the below command
vault read auth/approle-test/role/testapprole1/role-id
To generate a secret-id for our role,
vault write -f auth/approle-test/role/testapprole1/secret-id
We now have all elements for an app to use approle auth to login to Vault and work on secrets allowed by policies. Login with the new role_id and secret_id you have.
vault write auth/approle-test/login role_id="cc...d4" secret_id="3...58"
Using our shiny new token to read some secrets as below. Remember that we only have permissions to read t1/secrets
Thanks for reading and see you next time on another post.