Open yafanasiev opened 3 months ago
Thanks for this report!
This is interesting, we currently solve the mount inference in a new way - the first segment up until the first /
is the mount. What you present is a mount that includes a /
as part of the name of the mount.
I'd be happy to get an idea for how to change the mount inference logic that can accommodate for that but also be easy and transparent to users, that you think might work
Meanwhile I can also suggest a format like:
foo/bar://data/test
foo/bar:data/test
foo/bar//data/test
of course, first attempt would be at one agreed structured format, and if not found, fallback to taking the first segment like today.
any feedback / ideas?
Would you be open to roll back to old behaviour where we had to specify the full KV2 path to secret (including data
in path)?
Im open to ideas Could you give a few examples? Specifically I’m worried about how the mount will be specified
Hey @jondot! Sorry for the delay. How about your suggestion with foo/bar://data/test
? Seems nice to me
I have provided an implementation for foo/bar://data/test
with ://
delimiter.
OS: macOS 14.4.1 (23E224) (Intel) Teller version: 2.0.5
Description: Given the following sample configuration
where
foo/bar
is a secret mount name (including forward slash), andtest
is a secret path, Teller fails with the following error:Judging from request, Teller treats part of the path up to the first slash as a secret mount name and builds the Vault request accordingly, which is incorrect in our case.
I already tried URLencoding the slash character, escaping, double escaping etc.
With Teller v1, the following configuration was working for us: