-output-policy CLI flag is broken in multiple ways

[maxb]

I've noticed the recently added -output-policy CLI flag. Unfortunately, the implementation suffers from multiple problems causing it to produce incorrect answers.

Does not work for vault kv ... commands

$ vault kv get -output-policy kv/foobar
This output flag requires the success of a preflight request 
to determine the version of a KV secrets engine. Please 
re-run this command with a token with read access to kv/foobar
Unable to generate policy from command

(Contrary to the message, a token was supplied to this operation.)

Incorrect answers for vault list commands

$ vault list -output-policy something
path "something" {
  capabilities = ["read"]
}

It should be recommending list, not read.

Failure to recommend sudo for auth/token/accessors/

$ vault list -output-policy auth/token/accessors/
path "auth/token/accessors" {
  capabilities = ["read"]
}

Because the operation is a ListOperation and therefore defined with a trailing slash, but the slash has been stripped.

Hardcoded assumptions about PKI secrets engines

It suggests sudo for paths in the PKI secrets engine that need it, but only if the secrets engine is mounted at pki/ exactly - if mounted at any other path, it does not.

Failure to recommend sudo for paths in namespaces

$ vault read -output-policy ns1/sys/auth
path "ns1/sys/auth" {
  capabilities = ["read"]
}

In summary

• The current approach of using adhoc regexps hardcoded into the api package is too fragile - a successful implementation of -output-policy needs to be able to query the server to find out if a path is sudo-protected - probably via a new sys/ API. This could also enable it to give a clear indication of which endpoints actually support the create capability.

• The code needs to understand the difference between a ReadOperation and a ListOperation.

• Special handling around KV preflight requests is needed.

[lursu]

I have merged a pr with some mitigations to the first three issues that you called out. However for the later two, after some digging, I agree with your assessment that the policy needs to be derived in the long term from the server side. This is a bit of a larger lift than the time we have for now. So I have created a backlog item for us to convert this flags processing to a server side call this is realistically the only way we could properly handle the more dynamic and context dependent use cases as PKI, namespaces, and mount paths more generally.