Changes the vault issuer Kubernetes auth path to require the full *mount* path

[JoshVanL]

ACTION REQUIRED
Users who have previously set the Kubernetes Auth Mount Path will need to update their manifests to include the entire mount path. The `/login` endpoint is added for you.

Changes the Vault Kubernetes Auth Path to require the entire mount path. `/login` is added to all mount paths when authenticating.
The default auth path has now changed from `kubernetes` to `/v1/auth/kubernetes`

fixes #2205

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoshVanL

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JoshVanL]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JoshVanL]

/assign @munnerz

[munnerz]

Do we want to hardcode the login part of this? From what I understand, the /v1/auth/kubernetes path is the mount point of the kubernetes auth backend - I don't know if we ever need (or even want) users to override the suffix. cc @mam8270 have you got any thoughts on this?

[mam8270]

Login can be a bit more nuanced now with the vault enterprise "namespaces" feature, which essentially allows vault inside vault for the different namespaces (including auth endpoints), so i think you would want at least some mechanism for overriding of the login url. I agree you would lose some safety though.
https://learn.hashicorp.com/vault/operations/namespaces#policy-with-namespaces

[JoshVanL]

What's the conclusion here? If the path is wrong, a user can always override the path completely which is the point of this PR.

[munnerz]

Thanks for the link @mam8270 - I'm still a bit unclear on this though, the link you reference looks like it refers to prefixes on the Vault path, not the endpoint within the Kubernetes auth backend that is used to actually authenticate (i.e. /login).

Does this enterprise 'namespacing' feature allow this endpoint to be changed? If so, we will keep this line as is.

If not, we can make this field refer to the mount point of the auth backend instead of the particular endpoint used to authenticate (i.e. /v1/auth/kubernetes vs /v1/auth/kubernetes/login).

We want to allow people as much flexibility as possible, but if it isn't possible to specify a value other than login, we can gain a bit of 'safety' and save users making configuration errors.

[munnerz]

To note, mountPath is the name of the field here.. which IMO implies /v1/auth/kubernetes should be a valid value, and /v1/auth/kubernetes/login isn't (as it is not hte mount path)

[munnerz]

We're going to go with /v1/auth/kubernetes for now due to the field being named mountPath. If we need more flexibility in future, we can introduce a path field instead.

[munnerz]

Could you also add ACTION REQUIRED at the start of your release note to note that users of the kubernetes auth backend will need to update their issuer resources?

[JoshVanL]

/retest

[munnerz]

/lgtm