Issues making LIST requests

[orf]

The Vault docs specify that a HTTP request with a LIST method can be used to list secrets (i.e https://developer.hashicorp.com/vault/api-docs/secret/kv/kv-v1#list-secrets).

However, in some setups a custom method like LIST can be blocked for requests originating outside the cluster that Vault is running in. The UI still functions as a ?list=true argument is sent with a GET request (mostly because you cannot trigger a LIST request from JS).

I wonder if it would be acceptible to customize the various List*Request structs to make requests using ?list=true?

[stormshield-gt]

Thanks for opening the issue.

However, in some setups a custom method like LIST can be blocked for requests originating outside the cluster that Vault is running in. The UI still functions as a ?list=true argument is sent with a GET request (mostly because you cannot trigger a LIST request from JS).

Do you have an example of a setup that can't trigger LIST request from JS? I wasn't aware of this problem. Maybe there is some discussion in the vault repo about this?

[orf]

The issue is that LIST is a non-standard HTTP method - I’m pretty sure you can’t make requests with arbitrary, non-standard HTTP methods via JS in the browser.

The specific issue from my side comes when running vault in Kubernetes: if you’re using a service mesh or an ingress such as Istio/Envoy, then custom HTTP methods are not routable (envoyproxy/envoy#18819). This only impacts requests originating outside the cluster.

[orf]

Rather than change the default list methods to use this, would you accept a change that adds a second list method, or a change that falls back to using list=true when a 405 status is returned?

[stormshield-gt]

According to the docs the 2 methods are strictly equivalent, so in theory, it could be a non-breaking change.
I will be open to changing the internal LIST endpoint to use GET + list=true as it will work everywhere. I wonder what other vault clients do 🤔

It is still a mystery to me why Vault chose to use a custom HTTP verb for this. Maybe they weren't aware of the browser problems before.