search

SteeltoeOSS / Steeltoe

.NET Components for Externalized Configuration, Database Connectors, Service Discovery, Logging and Distributed Tracing, Application Management, Security, and more.
https://steeltoe.io
Apache License 2.0
1k stars 164 forks source link

404 errors on requests to /vault/v1/auth/token/renew-self #33

Closed Byzas19 closed 5 years ago

Byzas19 commented 5 years ago

Greetings,

I have a .NET Core 2.2 application that is connected - using Steeltoe (release 2.2.0) - to a Spring Cloud Config Server (open source, release 2.1.0) using HashiCorp Vault 1.0.1 as the backend. My app runs in Cloud Foundry. In my app's configuration, I have uri, token, tokenTtl, and tokenRenewRate set.

The application keeps trying to renew the Vault token by posting to /vault/v1/auth/token/renew-self and it gets a 404 every time. I don't see anything in the Spring Cloud Config Server source code that would allow it to handle such a request.

After finding this issue and emailing Craig Walls , I have learned that it is Spring Cloud Services - not the Spring Cloud Config Server - that has a controller that would handle that request.

I'm not sure why Steeltoe thinks my app is connected to Spring Cloud Services. I was under the assumption that Steeltoe was the library to use if I was using a config server and Pivotal.Extensions.Configuration.ConfigServerCore would be the library to use if I was using SCS. Or do both products assume you are using SCS if your app is running in cloud foundry? Is there a way to configure Steeltoe to automatically renew a Vault token if using Spring Cloud Config Server?

Any guidance or suggestions would be greatly appreciated!

cf-gitbot commented 5 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/166155388

The labels on this github issue will be updated when the story is started.

hananiel commented 5 years ago

Hey @Byzas19 -I'm looking at this. The first thing I tried is this sample locally : https://steeltoe.io/docs/steeltoe-configuration/#2-0-config-server-provider, running vault locally with configserver and setting the uri, token, tokenTtl, and tokenRenewRate set. And everything seems to be working fine. Can you confirm that is the case for you? One thing to clarify - ivotal.Extensions.Configuration.ConfigServerCore have just been moved to Steeltoe.Extensions.Configuration.ConfigServer* - its not the intention for one to work with SCS and other without. Can you point me to a sample repo that reproduces your issue (including spring cloud config server configuration) and see if I can reproduce it. In the mean time I will run this on cloud foundry and make sure it is still working.

hananiel commented 5 years ago

@Byzas19 I was incorrect about everything working fine- the renew request was failing. On further research it appears that although open source config server supports hashiCorp Vault, it doesn't not support the renewal as you mentioned. On Cloudfoundry when you install SCS Config server, it then supports it. It appears like you want to run open source config server on cloud foundry - is that correct? If so you might be able to open an issue on the OSS config server and get help with that. Please let me know what your expectations of Steeltoe Config Client should be. Is it fine as is or would you like an option to turn off renewal?

Byzas19 commented 5 years ago

@hananiel thanks so much for looking into this. I really appreciate it.

It would be nice to have an option to turn it off since it's a little strange to keep reaching out to a hard coded server path that may not exist. But the ideal solution for me would be to get OSS changed to handle renewal requests. Opening a request on their end is probably the path I'm going to take.

hananiel commented 5 years ago

For now I added a setting that allows one to turn this off. Looking at options to automatically infer what is on the server side of config client.