Why using code to put secrets in is a bad idea.
As you can tell, we got a little more flexibility than with challenge1. However: we still have the password in code!
Though we can now easily overload the variables in a later stage - as you can see in the next challenges, we often see that secrets are stored as part of the Spring Config or Spring Cloud config, without overriding it in a later stage. This means that everybody with the access to the Spring Cloud config can now learn what the secret is.
Using a distributed solution like Spring Cloud Config where you manage your application properties externally can have the same problem if you are not careful. Take a close look at the security section before using Spring Cloud Config.
What to do instead:
- Do not keep plaintext secrets in application properties or configuration repositories. Retrieve them from a secrets manager at deployment or runtime.
- If Spring Cloud Config must handle secrets, try to inject them through safe patterns using secrets managers as their sources (e.g. inject a secret with a vault side-car container). If this is not possible: enable Spring Cloud its supported encryption and authentication, restrict access to authorized workloads and operators, and audit access.