Secrets Manager Config Module 3.0.x - Continued Support for Loading a Default Set of Named Secrets Based on App Name & Active Bean Profiles

[neiljbrown]

In 2.x, the Secrets Manager Config module supports importing a default set of named Secrets into app config based on spring.application.name property value and active profile, by setting the spring.config.import property to a value of "aws-secretsmanager:” (i.e. when you don’t explicitly specify the names of any Secrets to import). This feature is described in the ref guide (2.3.0-RC2) section 3.4. Integrating your Spring Cloud application with the AWS Secrets Manager. Relevant extract -

Is this feature useful in practice? If not, should it be removed in 3.x, with support then only provided for importing specifically named Secrets?

(This discussion has been created to allow the point to be discussed independently from other issues, such as comments in issue #79. And to decide whether any change is required before creating an Issue).

[neiljbrown]

The intended spirit of the feature is a good one from the perspective of convenience (convention over configuration) for importing secrets. However, in practice I think it may only be of use to a limited no. of users.

Currently the feature includes the import of Secrets specific to an application’s active Spring bean profile (as well as some others). However, users may use profiles to activate beans for things other than environments, and these profiles may not need / have corresponding secrets. As a result, such users that still want to use the feature, have to resort to making the import of all of the other (shared system and non-conditional, application-specific) secrets that the feature supports optional (by adding the ‘optional:’ prefix to spring.config.import), even if those other secrets would be best be considered mandatory.

Currently the feature only imports the default set of Secrets if you don’t specify any named Secrets. However, I think many users will need to do that. For example, users who want to use Secrets Manager’s specific types of secrets, in particular RDS, to take advantage of built-in support for secret rotation, will need to create/store those Secrets separately (from an imported Secret that holds a collection of application specific secrets) to respect their different rotation policy and logic.

In summary, the feature doesn’t do any harm, but in its current form I think many users will opt-out of it and resort to explicitly specifying the name of Secrets to import. Whether that means it should be removed for 3.x as suggested, or just left in, depends on an assessment of just how many people don’t have the above requirements, and the complexity / maintenance overhead it adds to code & tests.

Neil.