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.

[lknite]

Would resolve a similar use case presented here: #1570

[cfryanr]

Thanks for creating this issue and carefully explaining your need, @lknite.

Without a volumeMount or secret reference this configuration item becomes a one-off

If the JWTAuthenticator optionally allowed you to specify the CA bundle as a secretRef which is a pointer to a Secret in the same namespace which contains the CA bundle, and if the JWTAuthenticator also automatically reads the CA bundle again within a few seconds whenever that Secret changes (without needing any pod restarts), then would that solve your use case?

[lknite]

Yes

[cfryanr]

Note that a Secret can hold about 1 MiB of data. See https://kubernetes.io/docs/concepts/configuration/secret/#restriction-data-size.

[lknite]

I know about the secret size limitation, which is why I initially spoke of a volume mount, which has no such limitation. In anycase a secret would work as well. I'm ready to implement this now in our environment, was this feature request implemented?

Status update?

[cfryanr]

Hi @lknite, we haven't implemented it yet, but @joshuatcasey is working on writing a feature proposal. We would be interested in your feedback. See #1984 for the proposal document.

[ashish-amarnath]

I am going to assign this to myself as I am working on completing #1984