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


  • captcha text