Difference between sys/policies/acl and sys/policy

During our policy setup we had the following open question:

  • why is there path “sys/policies/acl” and path “sys/policy” and what is the difference
  • similar with path “auth” and path “sys/auth”
  • similar with path “sys/mounts” and “sys/internal/ui/mounts”
  • what is the best way to debug policies (like deny all, look at the logs which are blocked and then incrementally enable them or similar)

Is there some documentation about these?

why is there path “sys/policies/acl” and path “sys/policy” and what is the difference

The /sys/policies endpoints are used to manage ACL, RGP, and EGP policies in Vault. RGP and EGP are Sentinel policies while ACL are classical policies. So this endpoint gives broader access to more capabilities in terms of access restrictions by adding Sentinel capabilities. While sys/policy only allow ACL based policies. Basically you can use any of sys/policies/acl or sys/policy/acl to configure ACLs.

similar with path “auth” and path “sys/auth”

The /sys/auth endpoint is used to list, create, update, and delete auth methods. Auth methods convert user or machine-supplied information into a token which can be used for all future requests. Compared to the auth/ path it allows for example to tune or read current tuning of auth method or list all of them. Other operations, like enable, disable are readily available on auth/ path.

similar with path “sys/mounts” and “sys/internal/ui/mounts”

/sys/internal/ui/mounts doesn’t offer most of what sys/mounts offers like enable/disable secret engine, read mount configuration, tune.

what is the best way to debug policies (like deny all, look at the logs which are blocked and then incrementally enable them or similar)

By default all access is denied, so you just open access to the path you need access too. So yes you can easily incrementally add them one after the other and check everything works as expected while doing so.

– Sebastien Braun