Micronaut is a hugely popular framework in the Java world and it continues to grow in features and adoption. Recently, version 2.0.0.M3 was released which included a number of features, but of note to readers of this blog and users of Oracle Cloud is a feature that I recently contributed which adds support for using Oracle Cloud Vaults as encrypted distributed config stores for your Micronaut applications. This means that you can safely and securely store your configuration variables in your vault and with just a bit of configuration those values are made available in your microservice or serverless application.
Hey There! If you're new to working with secrets and vaults in the Oracle Cloud, here's a perfect guide to getting started: Protect Your Sensitive Data With Secrets In The Oracle Cloud. Don't worry, I know the author of that guide. He's pretty cool!
To get started with this feature, add a few dependencies to your project:
Next, you'll need to configure your application. For distributed configurations, you'll need to create a
bootstrap.yaml file in
You're able to supply as many vault IDs as you'd like to your configuration. Each vault will be retrieved and all of the secrets in the vault will be set to a configuration variable in your application using the same name as the vault key. This means that if you have a secret named
FOO in vault "A" then a config var will be created named
FOO in your application. Keep in mind, that if you have another secret named
FOO in vault "B" then the variable created from vault "A" will be overwritten.
Here's an example configuration file:
Refer to the docs for details about each configuration property, but note that this feature supports either config file-based authentication or instance principal auth. Instance principal authentication is a really easy method to use when deploying your application to the Oracle Cloud.
You're now ready to go! You can access the config vars in a few different ways. If you create a secret with the name of
SECRET_ONE in your Oracle Cloud Vault, then it will be available to use in your application like any standard configuration variable:
You can also use
Another option is to inject your variables in
Vault retrieved values are always
String, but you can use
@ConfigurationProperties on a bean in conjunction with your
application.yml file to provide properly typed configuration variables.
So if you were to create secrets in your Oracle Cloud Vault like so:
And then added the following to your
You could add a config bean, like so:
You could then inject and use this bean in your application with properly typed values.
/hello/secret endpoint would return:
Another option is to inject your variables into your configuration files which gives you the ability to store things like database passwords and API keys in your vault:
This feature is fully documented in the official framework docs, so give it a shot today. Remember, you can create up to 5000 secrets in a vault absolutely free in your tenancy. This kind of data security is priceless, but when it costs you nothing you literally have no excuse not to keep your passwords, credentials, and API keys completely secure.
If you'd like to see a demo application that utilizes this feature, check out this project on GitHub: recursivecodes/vault-test.
I talk to a lot of developers in my job as a Developer Advocate. Sometimes they've been using the products in the Oracle Cloud for a long time, and sometimes...
A while back, I blogged about using Oracle Advanced Queuing (AQ) for messaging within your applications. It's a great option for durable and reliable...
I’ve written about messaging many, many times on this blog. And for good reason, too. It’s a popular subject that developers can’t seem to get enough of...