Closed Vity01 closed 3 years ago
If you would like us to spend some time helping you to diagnose the problem, please spend some time describing it and, ideally, providing a minimal sample that reproduces the problem.
The whole test env is ready on my comp and it's dependent on the Vault settings. I am not familiar with the Vault set up.. etc. If you find 10 minutes , I can show you there is nothing special in spring-vault usage and the ugly bug is sitting there.
That should be fixed with https://github.com/spring-projects/spring-vault/issues/601. Can you upgrade to Spring Vault 2.2.3.RELEASE and retest?
I am a bit confused about the artifacts and the versioning now. I am using
org.springframework.cloud:spring-cloud-starter-vault-config:2.2.6.RELEASE
which uses spring-vault-core:2.2.2.RELEASE
(max version)
Is spring-cloud-starter-vault-config
supposed to be obsolete?
Which artifact should I try?
Spring Cloud Vault builds on top of Spring Vault that ships the core functionality. You can stick with your Spring Cloud Vault version, just upgrade Spring Vault to 2.2.3.RELEASE
.
I am sorry, but I don't see any spring-vault artifact having 2.2.3.RELEASE version https://search.maven.org/search?q=spring%20vault
EDIT: It appeared there 1 minute ago
Mind the caches. https://repo1.maven.org/maven2/org/springframework/vault/spring-vault-core/ is likely the more reliable source.
Unfortunately, the bug seems to persist. I am still able to reproduce it.
Artifacts used:
I am ready to show it to you, setting whole the project would be too extreme.. I am sure you recognize the problem in a minute (or you find much easier way to reproduce it locally)
We can't always jump onto calls with every individual reporter as we're pretty busy already. Having a reproducer available allows us to investigate the issue once we have some time to look into it.
I agree on reproducible test, but this is pretty complex and it would take me (with my bare Hashicorp Vault knowledge) several days to come with something (believe me , I tried that). With your knowledge it can be just a few minutes. I've already spent days to be able to find it and reproduce it...
We've documented ACL requirements via #561.
It is still a thing? We found exactly the same issue in our PROD environment. The application was working fine, and some of the Vault instances were restarted. Then the application started an endless loop of 403 on the requests to the vault. Only the whole app restart fixed the issue.
We couldn't reproduce it yet
Try to reproduce it this way - try to use some proxy for connections and then kill the proxy for some time
Describe the bug It looks like whenever I start to block the Vault server (or there is any network problem) for a specific time, the vault client always gets a return code 403 from the server, the token is never refreshed and the client is not able to recover from this state. Only the whole app restart fixes the problem. I am not able to find another workaround. I am able to reproduce problem with our specific Vault configuration locally - very short Token timeout and other stuff. It applies for spring-cloud-starter-vault-config:2.2.5. The whole set up is quite complicated, I can demonstrate it on Zoom call with proxying calls