Added support for regional secrets via Google Cloud Secret Manager

[abheda-crest]

Added support for regional secrets via Google Cloud Secret Manager.

Approach:

• We have added a location field in the SecretManagerConfigurationProperties
• We have injected the SecretManagerConfigurationProperties into the SecretManagerFactory using constructor injection. This will be used to create the SecretManagerServiceClient based on the location provided in the configuration.
• We have added DefaultLocationSecretManagerClient class that will be used to fetch regional secrets based on the location provided in the configuration. For this, we have injected SecretManagerConfigurationProperties.
• We have also handled scenario to conditionally generate an implementation of SecretManagerClient based on the availability of location property in the configuration using @Requires annotation. i.e. If location field is present, than a bean of DefaultLocationSecretManagerClient will be created, else a bean of DefaultSecretManagerClient will be created.
• We have also added location field to the wrapper class VersionedSecret.

Alternative Approach and the reason we avoided it:

Rather than developing a separate implementation for the wrapper client DefaultLocationSecretManagerClient, we could have introduced a new field for SecretManagerConfigurationProperties and utilised constructor injection to modify the existing constructor of the DefaultSecretManagerClient. However, we were concerned that some users might have used this constructor to instantiate the wrapper client. As a result, we decided to pursue the approach outlined above.

We've covered the following scenarios for both global as well as regional secrets to test the functionality:

• Positive
  • We were able to inject the bean of type SecretManagerServiceClient and fetch the secrets
  • We were able to inject the bean of wrapper client SecretManagerClient and fetch the secrets
  • We were able to load default config when config-client is enabled
  • We were able to load non default config when config-client is enabled
  • We were able to load key/value pairs into a PropertySource when config-client is enabled
• Negative
  • When config-client is not enabled, the default config is not loaded
  • When config-client is enabled and the default-config property is false, the default config is not loaded
  • When config-client is not enabled, the non default config is not loaded
  • When config-client is not enabled, the key/value pairs is not loaded into a PropertySource
  • When I added gcp.secret-manager.location= to the bootstrap configuration, the SecretManagerServiceClient was created using the global endpoint (https://secretmanager.googleapis.com/). Also, DefaultLocationSecretManagerClient was instantiated, rather than the DefaultSecretManagerClient itself, which depends on the SecretManagerServiceClient. Consequently, when using the methods of this wrapper location client, we cannot retrieve the regional secrets, and we won’t see any errors. This is because the getSecret method manages errors by returning a Mono.empty() object in case of an error.

More information about regional secrets: https://cloud.google.com/secret-manager/regional-secrets/data-residency

[CLAassistant]

All committers have signed the CLA.

[graemerocher]

Nice work! Just a few items to address

[sdelamo]

Thanks for the contribution @abheda-crest.

I have pushed some small changes:

• Decrete the empty constructor of SecretManagerFactory
• Keep a single DefaultSecretManagerClient
• Add a regex pattern for the locations
• Made Groovy code in tests a little bit more idiomatic
• Add some nullability and javadoc info tags.
• Small copy corrections.

I hope you don't mind. Again, thanks for the contribution.