We are currently utilizing Spring Boot for our projects in conjunction with WebSphere Liberty. At present, credentials are directly stored within the server.xml configuration file using the element.
We are seeking to extract these credentials and securely store them in a vault. Since we rely on Spring Boot’s autoconfiguration and need to interact with the IBM Cloud Secrets Manager API, we would like to inquire if there is a way to delay the autoconfiguration process. This delay would allow us to retrieve the necessary credentials from the API and subsequently use them for the proper autoconfiguration of our application.
We are currently in the process of exploring potential solutions, and as such, no attempts have been made on our end thus far. It is possible that someone else may have already encountered and addressed this issue as SpringBoot is quite popular.
We are seeking to extract these credentials and securely store them in a vault. Since we rely on Spring Boot’s autoconfiguration and need to interact with the IBM Cloud Secrets Manager API, we would like to inquire if there is a way to delay the autoconfiguration process. This delay would allow us to retrieve the necessary credentials from the API and subsequently use them for the proper autoconfiguration of our application.
We are currently in the process of exploring potential solutions, and as such, no attempts have been made on our end thus far. It is possible that someone else may have already encountered and addressed this issue as SpringBoot is quite popular.
If you were to make your Cloud Secrets Manager client a Spring Bean, you could inject it in whichever components require these credentials. From there Spring would take care of the rest since the other components could not be instanciated without your client.
So it's not just any credentials- it's the database password that you want to source to be used for the DataSource.
In such case something like this ought to work:
of course you don't have to make the secret manager a bean if you don't want to, but if you have other secrets to lookup it could come in handy
So it's not just any credentials- it's the database password that you want to source to be used for the DataSource.
In such case something like this ought to work:
@Bean
DataSource dataSource(DataSourceProperties props,
TheIbmSecretManager sm) {
props.setPassword(sm.getTheDatabasePassword()) ;
return props.initializeDataSourceBuilder().build();
}
of course you don't have to make the secret manager a bean if you don't want to, but if you have other secrets to lookup it could come in handy
If you were to make your Cloud Secrets Manager client a Spring Bean, you could inject it in whichever components require these credentials. From there Spring would take care of the rest since the other components could not be instanciated without your client.
So it's not just any credentials- it's the database password that you want to source to be used for the DataSource.
In such case something like this ought to work:
of course you don't have to make the secret manager a bean if you don't want to, but if you have other secrets to lookup it could come in handy
So it's not just any credentials- it's the database password that you want to source to be used for the DataSource.
In such case something like this ought to work:
@Bean
DataSource dataSource(DataSourceProperties props,
TheIbmSecretManager sm) {
props.setPassword(sm.getTheDatabasePassword()) ;
return props.initializeDataSourceBuilder().build();
}
of course you don't have to make the secret manager a bean if you don't want to, but if you have other secrets to lookup it could come in handy
I know, but then I would need to define the DataSource bean in a @Configuration file, along with ConnectionFactory and everything else. Spring offers autoconfiguration with some properties in application.properties. This way, I wouldn't be able to use this. We are trying to write only "necessary" code. If Spring helps us with autoconfiguration and removes configuration code, we would like to use it.
- Page :
- 1
There are no replies made for this post yet.