Allow the remoteJWKS uri to specify a path to a file in the envoy pod.

[sgargan]

Description:

The JWT providers section of SecurityPolicy resources specify a remoteJWKS field with a uri that the key set should be downloaded from.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: policy-for-gateway
spec:
  jwt:
     providers:
         remoteJWKS:
            uri: https://example.com/jwks.json

The majority of use cases will use asymmetric keypairs and so retrieving a keyset with a public key makes sense. However, if the JWT is signed with a symmetric key then retrieving the JWKS from a remote url poses a security concern. For keysets with symmetric keys it would be more secure to load the keyset from a secret mounted into the gateway pods.

As it stands, the uri in the RemoteJWKS type could be used to make this possible. It could examine the scheme of the uri and create a jwtauthnv3.RemoteJwks instance for http/https uris or JwtProvider_LocalJwks instances with a corev3.DataSource for any uris with a file: scheme (or no scheme).

I've put together an MR to support this this, but had an open question about the name of the remoteJWKS field. Ideally this would use a name without the remote prefix (e.g. jwksSource) to futureproof further additions, but at the same time, renaming it introduces versioning/compatibility pain. Alternatively, a localJWKS field could be added to explicitly call out that it is sourced locally

Since this isn't a common use case, I'm not sure renaming remoteJWKS is necessary. The current uri field seems to handle filesystem access just fine and overloading the uri now would not stop something more explicit like localJWKS in the future. That having been said, I'd like to get everyone's opinions before continuing further with the MR.

Relevant Links:
Symmetric keys in JWKS spec

[arkodg]

hey @sgargan closing this issue since its a dup of #2419, its a valid feature, we'd like to get into the project, would be great if you can drive #2419 , suggest starting with an API suggestion first, most existing implementations (envoyproxy and non envoy proxy based) support this, so could use those as inspiration/reference