Deployment Manual / Version 2512.1
Table Of ContentsEncrypting a secret is the easy part. The hard part is protecting, distributing and rotating the key that decrypts it. Evaluate the following options in this order and use the first one that your infrastructure supports.
Application-agnostic secret management (recommended). Tools such as SOPS, Bitnami Sealed Secrets or a cloud key management service handle encryption, key storage, key distribution and key rotation outside of the application. On Kubernetes, the key never has to be visible to the developer or to the application container, because access is governed by the platform's role-based access control. This approach also works for every application in your deployment, regardless of its programming language.
The CoreMedia encryption service. CoreMedia Content Cloud ships its own encryption service for the secrets it manages itself, and its plugin-based variant can delegate to an external key management service. Prefer it over the in-application decryption described below whenever the secret in question is one of the values the encryption service already covers. See Chapter 4, Encryption Service Setup.
In-application decryption with
spring-cloud-context. Use this only if neither of the options above is available to you, for example when you do not run on a platform that offers secret management. It is described in Section 5.2, “Decrypting Property Values with Spring Cloud Context”.
Warning
In-application decryption moves the problem, it does not solve it. Everyone who can read the environment of a running application, for example by inspecting the container or its deployment descriptor, can read the decryption key and therefore every secret encrypted with it. Only use it when the access to that environment is restricted as tightly as the secrets themselves.
Note
Jasypt and its Spring Boot integration are sometimes suggested for this purpose. CoreMedia does not recommend them, because both projects are effectively unmaintained.
