add AWS Secrets Manager related libraries for use in application configuration

[esuomi]

• adds spring-cloud-aws-starter-secrets-manager which allows referencing secrets maintained in AWS Secrets Manager as part of normal Spring Boot application configuration as config imports
• adds aws-secretsmanager-jdbc which allows using credentials maintained in Secrets Manager as database connection parameters

Motivation:

In short, our AWS environment configuration relies on these libraries to keep secrets secret without inclusion in plaintext to project metafiles and also allow for keeping the configuration short :-)

Both of these libraries are visible in configuration only. As a pseudo example, these are utilized like so:

# imports '/uttu/database/credentials' secrets (JSON blob) as structured
# properties into current configuration, with prefix key uttudb.
spring.config.import=aws-secretsmanager:/uttu/database/credentials?prefix=uttudb.

# wrap DataSource driver with AWS Secrets Manager aware driver...
spring.datasource.driver-class-name=com.amazonaws.secretsmanager.sql.AWSSecretsManagerPostgreSQLDriver

# ...which is then given a parameterized special JDBC connection URI...
spring.datasource.url=jdbc-secretsmanager:postgresql://${uttudb.host}:${uttudb.port}/${uttudb.dbname}?currentSchema=${uttudb.dbname}

# ...and Secrets Manager key name to look up database's secrets and other
# parameters without ever including direct values into the application configuration itself
spring.datasource.username=/uttu/database/credentials

Both of these libraries utilize AWS' automatic identity management based on where the code is running, meaning the runtime environment itself has automatically access to specific resources without need to carry e.g. secret key as part of the deployment, only the references to where such key would be found.

On more nifty thing is that this also allows for rotating credentials without redeployment, as AWSSecretsManagerPostgreSQLDriver will re-resolve the credentials on authentication errors.

[testower]

Just wondering, we use GCP's secret manager for similar purposes, but have avoided including libraries for this by injecting them as kubernetes secrets in the kubernetes cluster. Would you be able to do something similar in your setup?

[esuomi]

We use AWS ECS Fargate which doesn't quite have the same concepts as k8s pods, although there are similarities and to some extents some similar facilities are available.

Anyway, AWS' vendor lock-in kinda wants people to do things with these libraries and avoid using static locations (k8s secrets are, to my understanding, specially provided small files in container's filesystem?), and while it should be possible to provide the values from environment variables, I do have to ask our infra person how he sees this + he knows better if it would fit with the overall cloud environment development and administration guidelines.

Lets keep this open for now and come back to this early next week. I'll let you know when I have more to share.

[esuomi]

@testower Here's what our infra person had to say:

Fargate supports passing secrets as parameters so that they're not exposed through environment making it an "okay" (his quotes, not mine) solution for running services. However for long running services this binds credential lifecycle to the deployment itself, effectively blocking credential rotation. To quote https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-secrets-management.html

Secrets that are referenced in tasks aren't rotated automatically. If your secret changes, you must force a new deployment or launch a new task to retrieve the latest secret value.

To summarize, AWS recommends one of the these two options for handling credentials:

• access credentials programmatically https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-app-secrets-manager.html (my note, this is what this PR is about)
• access credentials through Fargate secret parametres https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-secrets-manager.html

My recommendation would be to use the programmatic approach because it decouples credential rotation from service lifecycle, and would match with the other infrastructure already built for TIS (=Fintraffic Travel Information Services, our umbrella project) where we already do automatic periodic DB credentials rotation as per customer's security requirements.