Almost any application needs to use some sort of secret at some point. This can be API token, password, certificate or secret magic with which we can verify our application’s users or authenticate our application to some external service: 3rd party API, database or service.
The question arises how one should store those secrets, since we should not store them securly and have them freely exposed. There are numerous examples of applications that have secrets of all kinds in plain text inside application’s source code. This should be avoided at all costs for two reasons:
- Secrets are not code but configuration and should be treated this way. In perfect world when we are rotating secrets we should not have to change our code and/or redeploy our application.
- Secrets should stay secret and be safely stored and versioned.
One way of securly storing our secrets is to have them stored in some managed service that takes care of managing, versioning and accessing secrets. All big cloud providers have one and on Google Cloud Platform this is Secret Manager. With Secret Manager we are able to securely store and change our secrets without the need to redeploy the code.
Reader should probably ask themselve how can we access Secret Manager if we are storing all of our secrets there? Answer is Google’s Identity and Access Management integration. If our app is deployed on Google Cloud Platform we can just add appropriate IAM binding to the application’s service account. If application only needs to access secrets (in theory this should be enough for most of applications) we then need to add Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) to the list of permissions of application’s service account. This can be done using Google Cloud console or through some IaaC provider such as Terraform (if you have this set up for your cloud infrastructure).
The only thing left is to add logic in our application that will retrieve secrets from Secret Manager. Google provides APIs and client library, that enable us to this efficiently. But in ideal world we would like to have all this logic abstracted away and only bother with actually using the secrets in our application’s business logic. Here Quarkus and more specifically Quarkiverse Google Cloud Services extension comes in play. Extension contains all needed logic for retrieval of secrets from Secret Manager and enables us to load references to secrets in application.properties file:
my-top-secret=${sm//projects/<project-id>/secrets/<secret-id>}
And then use them in our code:
@ConfigProperty(name = "my-top-secret")
String secret;
More detailed documentation can be found on extension’s official documentation page. Reader can also see this used in practice in this simple working example.
This makes secret management in Quarkus application really simple and concise. Developers are then able to focus on actual business logic and can let Quarkus do the heavy-lifting.