Securing Properties

Application configuration almost always contains something that must not be committed in the clear — database passwords, API keys, signing keys, certificates. There are two approaches, and they trade off differently.

Fetch the secret at runtime from a secret store. The repository holds only a path; the value is retrieved at startup from a service that authenticates the caller, authorises the path and records the access. HashiCorp Vault is the example covered here, and the managed equivalents are AWS Secrets Manager and Parameter Store. The value can be rotated without touching the application, and every read is audited. The cost is an extra dependency in the startup path and a credential the application needs in order to authenticate to the store at all.

Commit the secret encrypted and decrypt it on the way in. Spring Cloud Config supports this directly: a property whose value is prefixed with {cipher} is decrypted by the config server before the client ever sees it — see Encryption and Decryption. There is nothing extra to run and the value travels with the configuration, but rotating a secret means a commit and a redeploy, and the encryption key itself still has to be kept somewhere.

The two combine well: encrypted properties for configuration that rarely changes, a secret store for credentials that are rotated on a schedule or issued dynamically per application instance. Whichever is used, the goal is the same — no plaintext secret in version control, and no secret whose holder cannot be identified from an audit trail.