Show List
Using AppRole Id to Access Vault
The appRole authentication method allows applications to authenticate with Vault. An appRole can be created for a machine/user/service.
Enable appRole Auth Method
appRole auth method is not enabled by default. To see which all auth methods are enabled, run command "vault auth list"
mail2@sm15 MINGW64 ~ $ vault auth list Path Type Accessor Description ---- ---- -------- ----------- token/ token auth_token_1875809e token based credentials
Here we see that only token auth method is enabled and for path token/.
To enable the auth method "appRole" we have to run the enable command. Default path for the "appRole" auth method is "approle"
mail2@sm15 MINGW64 ~ $ vault auth enable approle Success! Enabled approle auth method at: approle/
Create a Role
A role is usually associated with an application. Role provides access to the vault paths through the policy. In the command below we are creating a role with name role-to-access-first-app-secrets-path. While creating the role we are also providing the policy (created in the previous chapter) to provide access to the paths.
mail2@sm15 MINGW64 ~ $ vault write auth/approle/role/role-to-access-first-app-secrets-path policies=first-app-secrets-path-access-policy token_ttl=20000m Success! Data written to: auth/approle/role/role-to-access-first-app-secrets-path
To view the role, you can run list command as below:
mail2@sm15 MINGW64 ~ $ vault list auth/approle/role Keys ---- my-role role-to-access-first-app-secrets-path
Role details can further be viewed using read command
mail2@sm15 MINGW64 ~ $ vault read auth/approle/role/role-to-access-first-app-secrets-path Key Value --- ----- bind_secret_id true local_secret_ids false policies [first-app-secrets-path-access-policy] secret_id_bound_cidrs <nil> secret_id_num_uses 0 secret_id_ttl 0s token_bound_cidrs [] token_explicit_max_ttl 0s token_max_ttl 0s token_no_default_policy false token_num_uses 0 token_period 0s token_policies [first-app-secrets-path-access-policy] token_ttl 20000m token_type default
By default the value of bind_secret_id flag is true so secret id is required. It can be updated to false to enable login without secret id.
Get the Role Id for the created Role
Here is the command to get the role id for the created role:
mail2@sm15 MINGW64 ~ $ vault read auth/approle/role/role-to-access-first-app-secrets-path/role-id Key Value --- ----- role_id 4c8539d0-dbbf-624d-cac6-a26b740bdffa
Generate Secret Id for the Role
Below is the command to generate secret id for the specific role
mail2@sm15 MINGW64 ~ $ vault write -force auth/approle/role/role-to-access-first-app-secrets-path/secret-id Key Value --- ----- secret_id 32c58b1f-137a-6403-b18f-b5444cd81bde secret_id_accessor e59bbf0f-c159-ac7e-9ce4-46b5d5c83139 secret_id_ttl 0s
Login using Role id and Secret Id
Once we have role id and secret id we can login using those credentials. Token is provided in the response.
mail2@sm15 MINGW64 ~ $ vault write auth/approle/login role_id=4c8539d0-dbbf-624d-cac6-a26b740bdffa secret_id=32c58b1f-137a-6403-b18f-b5444cd81bde Key Value --- ----- token hvs.CAESIKK5Si310Ea0F4YXc9fyQF7vLW7rCel9CWH4t66_U1ELGh4KHGh2cy5udXRMU0NXOUF3N0FncWVUU3VTQ0hRYXo token_accessor Q5GyHfUCcBAuZ5gyuMaRkIqw token_duration 333h20m token_renewable true token_policies ["default" "first-app-secrets-path-access-policy"] identity_policies [] policies ["default" "first-app-secrets-path-access-policy"] token_meta_role_name role-to-access-first-app-secrets-path
Enable Login without secret id
By default role id and secret id both are required to login. Requirement for secret id can be disabled if we add some additional constraint such as restricting the IPs that can use the role id
mail2@sm15 MINGW64 ~ $ vault write auth/approle/role/role-to-access-first-app-secrets-path bind_secret_id=false secret_id_bound_cidrs=127.0.0.1/24 Success! Data written to: auth/approle/role/role-to-access-first-app-secrets-path
Now from within the provided CIDR, we can login just by using the role id
mail2@sm15 MINGW64 ~ $ vault write auth/approle/login role_id=4c8539d0-dbbf-624d-cac6-a26b740bdffa Key Value --- ----- token hvs.CAESINdxhoNbQ5OKVFE8HFLiyshFiDSFSYqBHZFShr8_ODbPGh4KHGh2cy51ZFZsMUpqV3dyUDVmbG5IWDQ4M3NwaVo token_accessor q5uPiXcskv3dHi0XtkCXZYEO token_duration 333h20m token_renewable true token_policies ["default" "first-app-secrets-path-access-policy"] identity_policies [] policies ["default" "first-app-secrets-path-access-policy"] token_meta_role_name role-to-access-first-app-secrets-path
Note the token id. We are going to use it to verify access
Verify Access to Role Id
The role "role-to-access-first-app-secrets-path" created above is linked to the policy "first-app-secrets-path-access-policy" which grants access to the paths secret/first-app-secrets/* (As we saw in the previous tutorial)
mail2@sm15 MINGW64 ~
$ vault policy read first-app-secrets-path-access-policy
path "secret/*" {
capabilities = ["list"]
}
path "secret/data/first-app-secrets/*" {
capabilities = ["create", "update", "read", "delete", "list"]
}To verify the access, we are going to create two secret paths. First one here follows secret/first-app-secrets/* format so the role id created above should have access to this path.
mail2@sm15 MINGW64 ~ $ vault kv put secret/first-app-secrets/login username=app1username password=app1password =========== Secret Path =========== secret/data/first-app-secrets/login ======= Metadata ======= Key Value --- ----- created_time 2022-12-26T17:38:53.8105288Z custom_metadata <nil> deletion_time n/a destroyed false version 1
The second path here does not follow the format so the role id created above should not have access to this path
mail2@sm15 MINGW64 ~ $ vault kv put secret/second-app-secrets/login username=app2username password=app2password ============ Secret Path ============ secret/data/second-app-secrets/login ======= Metadata ======= Key Value --- ----- created_time 2022-12-26T17:39:15.8181364Z custom_metadata <nil> deletion_time n/a destroyed false version 1
To test, set the value of VAULT_TOKEN environment variable to be token id of the role created above
mail2@sm15 MINGW64 ~ $ export VAULT_TOKEN=hvs.CAESINdxhoNbQ5OKVFE8HFLiyshFiDSFSYqBHZFShr8_ODbPGh4KHGh2cy51ZFZsMUpqV3dyUDVmbG5IWDQ4M3NwaVo
Now if we try to get the secrets from "secret/first-app-secrets/login", command would be successful as the policy provides access
mail2@sm15 MINGW64 ~ $ vault kv get secret/first-app-secrets/login =========== Secret Path =========== secret/data/first-app-secrets/login ======= Metadata ======= Key Value --- ----- created_time 2022-12-26T17:38:53.8105288Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- password app1password username app1username
Command to get the secrets from "secret/second-app-secrets/login" path would fail as the policy does not provide access to this path
mail2@sm15 MINGW64 ~
$ vault kv get secret/second-app-secrets/login
Error reading secret/data/second-app-secrets/login: Error making API request.
URL: GET http://127.0.0.1:8200/v1/secret/data/second-app-secrets/login
Code: 403. Errors:
* 1 error occurred:
* permission deniedLeave a Comment