Logical/Auth plugin config should be saned

[jefferai]

When auth plugins were added, rather than add a config map to the API, plugin_name was added as its own parameter, creating a discrepancy with secret mounts. Secret mounts should get a plugin_name, and auth mounts a config map, so that both support the same workflow (but without backwards compatibility).

[calvn]

Should we encourage usage towards one or the other (e.g. mark one of them as deprecated)?

[jefferai]

I think we should look at likely usage patterns. To some extent I'm not sure whether the things that are in the config map now are necessarily easier to have there than pulling up to the top level. I think the original idea was that the config map would hold configuration for the backends but this went away by having config endpoints within the backends that can be ACL'd. So it's possible the right thing is to keep supporting this but change to simply moving these things up a level out of the map, unless we think we're going to be piling on more of these over time.

[calvn]

I see. Looking at it from the api.MountInput perspective, having things at the top level looks more like what the CLI accepts (i.e. you don't provide plugin-name, max-lease-ttl, etc. within a --config param, but directly instead), but less like what vault.MountEntry accepts (since it transposes those fields back into MountConfig).

The way I see it is that api.MountInput acts as the interface between the actual CLI input and MountEntry under core, and it makes perfect sense since that's what the api package is supposed to do. I guess the question is, should we lean towards having it look more like how the CLI behaves, or how it's laid out in core (i.e. MountEntry.Config).

[calvn]

Actually the CLI is more of a thin wrapper around the API, so the key interaction is between the API and the underlying core functionality. In that case I'd say that MountInput should assimilate the structure of MountEntry, but I agree that we should probably keep both for now and observe usage patterns until a further conclusion can be drawn.