I'm using spring cloud AWS secrets manager support to load in configuration defined by terraform which creates the application secret defaults.
Once adding a policy statement to the services accessing the secret I run into spring not starting as it's attempting to read all kinds of secrets for profiles that do not exist in secrets manager.
How can I restrict the spring cloud secrets manager support to only read secrets I have explicitly granted access without needing to create empty secrets for every profile?
This is not possible yet unfortunately. We have pull request that enables skipping loading profiles that will likely be merged in 2.3 and we are re-thinking Secrets Manager integration for 3.0.
Related
I'd like my app to use the default application credential chain but to be able to customise the access scopes available to the role. Is there a way to do it?
Turns out Spring Cloud GCP provides an option to set scopes for the credentials. To do that you need to specify, eg: spring.cloud.gcp.credentials.scopes=DEFAULT_SCOPES,https://www.googleapis.com/auth/cloud-vision in your application.ini/yaml file or as per usual in Spring you can use environmental variables to do it as well, eg: export SPRING_CLOUD_GCP_CREDENTIALS_SCOPES=DEFAULT_SCOPES,https://www.googleapis.com/auth/drive
For more details check:
https://docs.spring.io/spring-cloud-gcp/docs/current/reference/html/#scopes
I have been using the Spring cloud Service connectors for Pivotal cloud foundry for a long time which gets the connection details from the VCAP_SERVICES env variable. Now we have a requirement to read these credentials from Vault . I am just curious , Can I still continue to use the Service binding approach with spring cloud connector ? I would assume we don't want to expose these credentials from vault to an VCAP_SERVICES variable which defeat the purpose of the vault. Has there been any enhancements in Spring cloud connectors to read the credentials directly from Vault rather than depending the VCAP_SERVICES env variable or should I resort back to the Spring boot's default Application Properties based approach instead of the service binding approach using cloud connectors ?
The Spring Cloud Connectors project is now in maintenance mode, in favor of the newer Java CFEnv project. However, Java CFEnv is also very specific to Cloud Foundry's VCAP_SERVICES model of exposing service bindings and won't help you if the service connection info is in Vault.
I would suggest that you fall back to the Spring Boot properties-based approach using Spring Cloud Vault or Spring Cloud Config Server's Vault integration to automate fetching the properties from Vault and making them available as Spring Boot properties.
I am setting up the Spring-boot microservices with the cluster bi-direction Pivotal cloud cache.
I have set up the bi-directional cluster in Pivotal Cloud, I have a list of locators with ports.
I have already some online docs.
https://github.com/pivotal-cf/PCC-Sample-App-PizzaStore
But couldn't understand the on which configuration the spring boot app will know to connect.
I am looking for some tutorial or some reference where I can have spring boot app linked up with the PCC(gemfire)
The way you configure a app running in PCF (Pivotal Cloud Foundry) to talk to a PCC (Pivotal Cloud Cache) service instance is by binding the app to that service instance. You can bind it either by running the cf bind command or by adding the service name in the app`s manifest.yml, something like the below
path: build/libs/cloudcache-pizza-store-1.0.0-SNAPSHOT.jar
services:
- dev-service-instance
I hope you are using Spring Boot for Apache Geode & Pivotal GemFire (SBDG) in your app, if not I recommend you to use it as it makes connecting to PCC service instance extremely easy. SBDG has the logic to extract credentials, hostname:ports needed to connect to a service instance.
You as a app developer just need to
Create the service instance.
Bind your app to the service instance.
The boilerplate code for configuring credentials, hostnames, ips are handled by SBDG.
When you deploy an application in Cloud Foundry, (or Pivotal Cloud), you need to bind it to one or more services. Service details are then automatically exposed to the app via the VCAP_SERVICES environment variable. In the case of PCC this will include the name and port of the locator. By adding the spring-geode-starter (or spring-gemfire-starter) jar to the application it will automatically process the VCAP_SERVICES value and extract the necessary endpoint information in order to connect to the cluster.
Furthermore, if security is enabled on your PCC instance, you will also need to have created a service key. As with the locator details, the necessary credentials will be exposed via VCAP_SERVICES and the starter jar will automatically process and configure them.
I'm trying to create a Spring Boot application that regularly fetch data from AWS S3.
The AWS S3 credentials are fetched from Vault using Spring Cloud Vault when the application start.
My issue is that AWS S3 credentials have a limited lifespan due to Vault policy so I have to restart my application from time to time to obtain new credentials from Vault
Is there a way to automatically restart bean using those credentials?
TL;DR
No, there is no automatism, but you can do this yourself.
The longer read
Spring Boot and Spring Cloud aren't really intended for applying continuous updates to the configuration without interruption. Spring Cloud Config ships with Refresh Scope support that allows to annotate beans with #RefreshScope and trigger a refresh of the beans that get re-initialized. This approach requires either integration with a message bus or triggering the refresh endpoint.
The other alternative, which is limited to AWS functionality, is providing an own AWSCredentialsProvider implementation that is backed by a Vault PropertySource that applies rotation to your credential. This requires you to provide a bit of code that integrates with VaultConfigurer or even directly via SecretLeaseContainer to get secret lifecycle event callbacks. See here for an integration example.
There is a ticket asking for the same question that contains background why this pattern isn't widely applicable.
we am trying to use vault to keep database credentials and using token in by spring boot application to fetch secrets. Credentials are kept at secret back-end at vault. Connection with application and vault is secure to TLS. This kind of secret distribution is still vulnerable and depends on the developers maturity. Once application has the access to secrets it can be logged in the files. Unlike traditional JEE application, data source is looked up in resource jndi and application never now the database credential. resource setup was done by operations team and access to credentials were limited. Application never has the credential visibility.
Is my understanding correct, if that so how we can make secrets more secure in spring boot application or is this the trade off we have to compromise with.
Very Good Question.
As I think secrets can be logged in the files. As we are getting from vault.
We have to compromise on this. Its same as any secure information (eg. customer data) regarding application can also be logged in the files.
It should be taken care by developer and reviewer.