-
Notifications
You must be signed in to change notification settings - Fork 41k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FileWatcher used for SSL reload does not support symlinks #43586
FileWatcher used for SSL reload does not support symlinks #43586
Conversation
This allows using symlinks for SSL certificate hot reloading.
@tmaciejewski Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@tmaciejewski Thank you for signing the Contributor License Agreement! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. This looks good but I am wondering about something and added a question.
private Set<Path> resolveSymlinks(Set<Path> paths) throws IOException { | ||
Set<Path> result = new HashSet<>(); | ||
for (Path path : paths) { | ||
result.add(path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for adding the symlink to the files to watch. Shouldn't we only add the real file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review. Yeah, you're right. I wanted to keep backward compatibility, but since the real file is watched, it would still be there if the link is changed to some other file, which is less intuitive. Changed it to watch only the real file.
This commit allows using symlinks for SSL certificate hot reloading. See gh-43586
@tmaciejewski thank you for making your first contribution to Spring Boot. |
Prior to this commit, a change in gh-43586 unlocked the support for symlinks: instead of watching the link itself which might never change, this would watch the target file which is likely to change. This could break with an `IllegalStateException` in case the symlink is using a path relative to the link itself. This commit ensures that the target is resolved against the current link path to avoid incorrect watch operations. Fixes gh-43966
Hi Everyone! Is this released? I have the same or similar issue. I use kubernetes cert manager in order to manage my certs. It stores those as sym links:
ssl config: spring:
application:
name: "shell"
ssl:
bundle:
jks:
shell:
reload-on-update: false
keystore:
location: ${KEYSTORE:file:/opt/certs/keystore.p12}
password: ${KEYSTORE_PW:changeit}
type: "PKCS12"
truststore:
location: ${TRUSTSTORE:file:/opt/certs/truststore.p12}
password: ${TRUSTSTORE_PW:changeit}
type: "PKCS12" But somehow spring cannot resolve them and I got this exception:
**The problem is in the FileWatcher class witch resolves the file wrong and add the wrong absolute path to the resolved file. I my case int should prepend /opt/certs. The corect path is /opt/certs/..data/keystore.p12 The logs are from my local machine but in a kubernetes cluster I got the same result, just the path prefix is the path where the jar file executed.** Can anyone help? |
@PetarDimitrovZH See #43966 which will be released this week. |
@bclozel Thank you! |
This allows using symlinks for SSL certificate hot reloading.
In my company we have services on k8s with SSL certificates stored on a mounted volumes. Since they are symlinks, we cannot use hot-reloading, because the content is changed in the file under the symlink, not the symlink itself. This change make
FileWatcher
watch not only the symlink, but also the file it resolves to.