When configuring a vault instance with engineVersion set to 2 all transit calls fail. Things work fine when the engineVersion is set to 1. Looking into the issue it appears that the logical read/write calls automatically assume that the path must be adjusted to follow the KV version 2 API requirements. While this is necessary for the KV v2 secrets backend this will corrupt the paths for other backends. The only way i see to influence this is to set a secretsEnginePathMap. This seems like a bit of a hack as the KV version has nothing to do with transit. More importantly, for my personal use case, is that we do not know the paths up front to configure this. The paths aren't known until the actual calls to the transit backend are made. I would need a dynamic way of handling this.
I have created a patch which we are using for the time being. It is a minor patch to the Logical class that adds a transit literal to the LogicalOperations enum and opens up the read/write delegate methods, that accept the LogicalOperations as a parameter, to public visibility. With this I can influence the read write behavior when making transit calls to have the adjustPathForReadOrWrite run as a NOOP. I would be happy to submit this as a pull request or discuss other alternatives. I really don't want to be running on a locally patched version of the library or resort to "hacky" workarounds like creating multiple drivers with different configurations just to work around this. Thanks
When configuring a vault instance with engineVersion set to 2 all transit calls fail. Things work fine when the engineVersion is set to 1. Looking into the issue it appears that the logical read/write calls automatically assume that the path must be adjusted to follow the KV version 2 API requirements. While this is necessary for the KV v2 secrets backend this will corrupt the paths for other backends. The only way i see to influence this is to set a secretsEnginePathMap. This seems like a bit of a hack as the KV version has nothing to do with transit. More importantly, for my personal use case, is that we do not know the paths up front to configure this. The paths aren't known until the actual calls to the transit backend are made. I would need a dynamic way of handling this.
I have created a patch which we are using for the time being. It is a minor patch to the Logical class that adds a transit literal to the LogicalOperations enum and opens up the read/write delegate methods, that accept the LogicalOperations as a parameter, to public visibility. With this I can influence the read write behavior when making transit calls to have the adjustPathForReadOrWrite run as a NOOP. I would be happy to submit this as a pull request or discuss other alternatives. I really don't want to be running on a locally patched version of the library or resort to "hacky" workarounds like creating multiple drivers with different configurations just to work around this. Thanks