Allow a volumemount certificate reference to be used by JWTAuthenticator

[lknite]

Is your feature request related to a problem? Please describe.

JWTAuthenticator allows a certificate to be specified in line but this misses several use cases which a volumeMount solves.

At the enterprise level there is generally a globally made available onprem cert used by pods. Solutions exist such as trust-manager which auto-generates a secret or configmap with the needed ca-bundle in every namespace, which can then be mounted as needed. In my case the ca.crt is pulled via vault and made available via a secret.

Without a volumeMount or secret reference this configuration item becomes a one-off which must be accounted for when the ca.crt gets replaced, whereas all other references are automatically updated. For example, the method pulling the secret from vault is updated every 15 seconds, granted a pod would need to be restarted to get the updated secret, but the secret itself is automatically maintained. Along with a solution such as reloader the pod could be restarted automatically if desired when the secret is updated. (Imagine a security situation where certs need to be replaced quickly.)

There are use cases for using a configmap, secret, as well as a pvc as relates to the JWTAuthenticator spec.tls.certificateAuthorityData. Sometimes a ca-bundle will be too big for a configmap or a secret requiring the use of a pvc. In this case only the cert is needed that JWTAuthenticator requires, so a secret would be sufficient, but a volumeMount option would take care of all potential use cases.

Describe the solution you'd like

I'd like to be able to specify a volumeMount in the helm chart I use to deploy pinniped, currently using bitnami. The volumeMount would end up being mounted in the pinniped-concierge pod (or agent pod, whichever makes sense). Once available JWTAuthenticator could reference the volumeMount available via the pinniped pod to get access to the certificateAuthorityData. JWTAuthenticator could have a configuration value which indicates it will use the mount on the pinniped pod (and which mount as there could be many in the case of multiple JWTAuthenticators, or could multiple certs all go in the same volumeMount?), or use an inline provided cert.

Describe alternatives you've considered

Alternatively the volume and volumeMounts could be defined in the JWTAuthenticator but that might end up being complex and difficult to maintain.

Are you considering submitting a PR for this feature? no

• How will this project improvement be tested? Whatever testing currently exists with JWTAuthenticator which tests the certificatAuthorityData field, would have an additional similar test which pulls the value from a volumeMount existing on the pinniped pod.
• How does this change the current architecture? It removes an inline value from being a one-off configuration, to a more enterprise-ready style configuration.
• How will this change be backwards compatible? The inline provided cert configuration in the JWTAuthenticator resource could remain in place.
• How will this feature be documented? A comment in the JWTAuthenticator example online docs would be enough. Additionally, folks similar to myself will look at the jwtauthenticator crd and if there is a field there somehow indicating a reference to the mount, that would also communicate what's needed.