Show List
Creating Vault Access Policies
Vault policies provide the access privileges to the clients. During initialization, Vault creates "root" and "default" policies. With root policy token, user can perform every operation for all paths. Default policy provides some common set of capabilities. List of policies can be viewed using "vault policy list" command.
mail2@sm15 MINGW64 ~ $ vault policy list default root
A policy defines a list of paths, with each path having information of capabilities allowed.
We can view the policy details using read command against the policy:
mail2@sm15 MINGW64 ~ $ vault policy read default # Allow tokens to look up their own properties path "auth/token/lookup-self" { capabilities = ["read"] } # Allow tokens to renew themselves path "auth/token/renew-self" { capabilities = ["update"] } # Allow tokens to revoke themselves path "auth/token/revoke-self" { capabilities = ["update"] } # Allow a token to look up its own capabilities on a path path "sys/capabilities-self" { capabilities = ["update"] } # Allow a token to look up its own entity by id or name path "identity/entity/id/{{identity.entity.id}}" { capabilities = ["read"] } path "identity/entity/name/{{identity.entity.name}}" { capabilities = ["read"] } # Allow a token to look up its resultant ACL from all policies. This is useful # for UIs. It is an internal path because the format may change at any time # based on how the internal ACL features and capabilities change. path "sys/internal/ui/resultant-acl" { capabilities = ["read"] } # Allow a token to renew a lease via lease_id in the request body; old path for # old clients, new path for newer path "sys/renew" { capabilities = ["update"] } path "sys/leases/renew" { capabilities = ["update"] } # Allow looking up lease properties. This requires knowing the lease ID ahead # of time and does not divulge any sensitive information. path "sys/leases/lookup" { capabilities = ["update"] } # Allow a token to manage its own cubbyhole path "cubbyhole/*" { capabilities = ["create", "read", "update", "delete", "list"] } # Allow a token to wrap arbitrary values in a response-wrapping token path "sys/wrapping/wrap" { capabilities = ["update"] } # Allow a token to look up the creation time and TTL of a given # response-wrapping token path "sys/wrapping/lookup" { capabilities = ["update"] } # Allow a token to unwrap a response-wrapping token. This is a convenience to # avoid client token swapping since this is also part of the response wrapping # policy. path "sys/wrapping/unwrap" { capabilities = ["update"] } # Allow general purpose tools path "sys/tools/hash" { capabilities = ["update"] } path "sys/tools/hash/*" { capabilities = ["update"] } # Allow checking the status of a Control Group request if the user has the # accessor path "sys/control-group/request" { capabilities = ["update"] } # Allow a token to make requests to the Authorization Endpoint for OIDC providers. path "identity/oidc/provider/+/authorize" { capabilities = ["read", "update"] }
Creating a Policy
Write command is used to create the policy. In the command we provide path and access capabilities. For example here we are creating a policy with name "first-app-secrets-path-access-policy". The user attached to this policy will have create, update, read, delete, list access on the secret/first-app-secrets/* paths
mail2@sm15 MINGW64 ~ $ vault policy write first-app-secrets-path-access-policy - << EOF
path "secret/*" { capabilities = ["list"] } path "secret/data/first-app-secrets/*" { capabilities = ["create", "update", "read", "delete", "list"] }
EOF
Success! Uploaded policy: first-app-secrets-path-access-policy
Leave a Comment