Compare commits

...

2 Commits

2 changed files with 4 additions and 4 deletions

View File

@@ -205,7 +205,7 @@ The first few prep steps will sound familiar from the Zabbix paragraph above. Fo
Create a group named `rbacgroup_remco`. Add the `remco` entity to it and make it use the policy `remco`. At this point the policy does not yet exist which is fine, you can set a policy name and Vault will simply link your group to the policy `remco` which does not exist. You'll get to that in a minute. Create a group named `rbacgroup_remco`. Add the `remco` entity to it and make it use the policy `remco`. At this point the policy does not yet exist which is fine, you can set a policy name and Vault will simply link your group to the policy `remco` which does not exist. You'll get to that in a minute.
Next up we'll be working with [policies/remco/remco.hcl](policies/remco/remco.hcl). In that file replace `GROUPID` with the actual group ID of `rbacgroup_remco`, refer to paragraph [Group ID replacement](#group-id-replacement) for a how-to guide. Continue reading there until you reach the point talking about logging in to Vault as the newly created user then return here. Next up we'll be working with [policies/remco/remco.hcl](policies/remco/remco.hcl). Notice that contrary to the policy file we used for [Zabbix credentials storage](#zabbix-credentials-storage) this one is not completely templated. An orphan token has no parent `entity_id` so it does not inherit its parent's group membership. As a result dynamically granting access based on group ID doesn't work for an orphan token. We specify the hard-coded path as a concession to the orphan token. The templated part of the policy file still needs to be adjusted: replace `GROUPID` with the actual group ID of `rbacgroup_remco`, refer to paragraph [Group ID replacement](#group-id-replacement) for a how-to guide. Continue reading there until you reach the point talking about logging in to Vault as the newly created user then return here.
For our `remco` example application we want a periodic orphan token. For our `remco` example application we want a periodic orphan token.

View File

@@ -1,8 +1,8 @@
# Allow listing secret parent-child connections (as in UI hierarchy). Subdir # Allow listing secret parent-child connections (as in UI hierarchy). Subdir
# underneath 'kv' secrets engine will remain hidden though, user has to # underneath 'kv' secrets engine will remain hidden though, user has to
# manually open up # manually open up
# ${VAULT_ADDR}/ui/vault/secrets/kv/list/for_{{identity.groups.ids.83754fb4-ee24-fa6a-52dd-50ef8f1d6665.name}} # ${VAULT_ADDR}/ui/vault/secrets/kv/list/for_{{identity.groups.ids.GROUPID.name}}
path "kv/metadata/for_{{identity.groups.ids.83754fb4-ee24-fa6a-52dd-50ef8f1d6665.name}}/*" { path "kv/metadata/for_{{identity.groups.ids.GROUPID.name}}/*" {
capabilities = ["list"] capabilities = ["list"]
} }
@@ -12,7 +12,7 @@ path "kv/metadata/for_rbacgroup_remco/*" {
} }
# Grant read-only access to secrets # Grant read-only access to secrets
path "kv/data/for_{{identity.groups.ids.83754fb4-ee24-fa6a-52dd-50ef8f1d6665.name}}/*" { path "kv/data/for_{{identity.groups.ids.GROUPID.name}}/*" {
capabilities = ["read"] capabilities = ["read"]
} }