Compare commits
	
		
			2 Commits
		
	
	
		
			6402ad542e
			...
			43745f6a99
		
	
	| Author | SHA1 | Date | |
|---|---|---|---|
| 43745f6a99 | |||
| 69e8d644dd | 
@@ -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.
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
@@ -1,8 +1,8 @@
 | 
			
		||||
# Allow listing secret parent-child connections (as in UI hierarchy). Subdir
 | 
			
		||||
# underneath 'kv' secrets engine will remain hidden though, user has to
 | 
			
		||||
# manually open up
 | 
			
		||||
# ${VAULT_ADDR}/ui/vault/secrets/kv/list/for_{{identity.groups.ids.83754fb4-ee24-fa6a-52dd-50ef8f1d6665.name}}
 | 
			
		||||
path "kv/metadata/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.GROUPID.name}}/*" {
 | 
			
		||||
    capabilities = ["list"]
 | 
			
		||||
}
 | 
			
		||||
 | 
			
		||||
@@ -12,7 +12,7 @@ path "kv/metadata/for_rbacgroup_remco/*" {
 | 
			
		||||
}
 | 
			
		||||
 | 
			
		||||
# 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"]
 | 
			
		||||
}
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
		Reference in New Issue
	
	Block a user