Hashicorp’s Vault 

# 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/" {
  capabilities = ["read"]
}
path "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"]
}

path "sys/health"
{
  capabilities = ["read", "sudo"]
}

path "sys/policies/acl"
{
  capabilities = ["list"]
}

path "sys/policies/acl/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "auth/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/auth/*"
{
  capabilities = ["create", "update", "delete", "sudo"]
}

path "sys/auth"
{
  capabilities = ["read"]
}

path "secret/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/mounts/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/mounts"
{
  capabilities = ["read"]
}

Roles 

Como las políticas han sido definidas, crearemos un rol de acuerdo a lo anterior. Esto se hará a través del terminal habilitado en la aplicación Vault.

Para el usuario común se creará el rol DEMO con el siguiente comando (No olvide rellenar el Client id):

vault write auth/oidc/role/demo \
        bound_audiences="CLIENT_ID" \
        allowed_redirect_uris="http://<your service host>:8200/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<your service host>:8250/oidc/callback" \
        user_claim="sub" \
        policies="default" \
        verbose_oidc_logging="true"

Para el administrador común se creará el rol ADMIN con el siguiente comando (No olvide rellenar el Client id):

vault write auth/oidc/role/admin \
        bound_audiences="CLIENT_ID" \
        allowed_redirect_uris="http://<your service host>:8200/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<your service host>:8250/oidc/callback" \
        user_claim="sub" \
        policies="admin" \
        verbose_oidc_logging="true"

Es importante recordar que el usuario establecido por defecto en la configuración de oidc no necesita ser introducido en el inicio de sesión, pero en este caso para entrar como administrador sería necesario introducir el rol.