I am using spring-boot-starter-oauth2-resource-server, and it would be nice if we could have a property that stores the public key, without needing it to dump it into a file. I store it in a sealed secret and I would like to avoid having to mount it into a file. Especially because when using Spring-Cloud-Config it might be read directly as a property

Current spring.security.oauth2.resourceserver.jwt properties:

  • public-key-location: is for file (and presumably not a properties one, so not mountable from configmap)
  • jwk-set-uri: is for requesting it to a URI
  • issuer-uri: is for requesting the token itself

I miss something like Spring security's security.oauth2.resource.jwt.key-value, so I can use it directly by setting the property as the content string itself

Comment From: nightswimmings

@philwebb if you know any workaround on how to mount the key from a SealedSecret's "embedded .properties" field in the meantime, we would appreciate it a lot

Comment From: nightswimmings

Would this make sense? https://github.com/spring-projects/spring-boot/issues/28714

Comment From: mbhave

@nightswimmings Can you provide more information on why there would be a workaround required for sealed secrets. From what I can tell when sealed secrets are applied to the cluster, they are unsealed and applied as regular secrets. It could then be made available to the container by creating a volume mount with an environment variable for SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_PUBLICKEYLOCATION pointing to that location. However, I am not very familiar with sealed secrets so I might be missing something.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: zhemaituk

Second the request. It's simply convenient to use strings, there is whole specter of features in Spring to work with String content. Examples: 1. My case: Retrieve content from AWS SSM. I.e. it would look like this in properties.yaml: public-key: ${/auth/firebase/public-key}. The property resolves to string. 2. In spirit of 12 factor app: just pass the value via env var. It's oftentimes much easier to supply config value via string env var directly, than to create/mount a file somewhere and still supply env var with path to this file.

I guess current alternative is to write a special property resolver specifically for public-key-location, which reads from SSM (or env var), creates a file, writes public key there, and then returns path to that file, for the framework just to read it back to String.

Comment From: nightswimmings

Sorry for being late. As stated in my original post: I store it in a sealed secret and I would like to avoid having to mount it into a file. Especially because when using Spring-Cloud-Config it might be read directly as a property

I don't remember the context, but it probably refers to this: https://github.com/spring-cloud/spring-cloud-kubernetes/pull/801#issuecomment-846094701

Comment From: nightswimmings

@mbhave Does it make sense to reopen the ticket since I eventually added feedback?

Comment From: wilkinsona

@nightswimmings We're not keen on the idea of tackling this on a property-by-property basis and would prefer a more general purpose solution like the one you proposed in #28714.

@zhemaituk #28714 may be of interest to you as well, particularly the custom PropertyResolver which you could hopefully use now without any changes in Boot or Framework.

Comment From: zhemaituk

Agree, it's consistent with other places of the framework,server.ssl.certificate property and alike (but unlike security.oauth2.resource.jwt.key-value though).

Approach described in #28714 addresses more complex cases, and also gives some further ideas how to add extra "sugar" to config code. E.g. implementing a protocol resolver directly for ssm: or sealed-secret:, so in config it would look like public-key-location: ssm:/auth/firebase/public-key