Securing Mule 4 config properties

In this article we’ll demonstrate how to secure your MuleSoft properties and prevent their leakage into Github source code repositories.

Use Case

• Secure your passwords to prevent break-ins and other misuse.

There’s probably not much more that needs to be said about securing passwords, other than you need to do it. It’s likely that your organization audits source repositories regularly and you should get out ahead of Best Practices. If you’d like some additional backgrounder in password strength or passwords which are easily cracked, the prior OWASP links are a great start.

MuleSoft versions this is known to work with: 4.2

Link to MuleSoft reference documentation

For those of you that have configured Mule Vault to secure your properties in the 3.x version, there’s a few differences you’ll find in 4.x. The first thing you’re going to need to do is download and install the Mule Secure Configuration Properties Extension from Anypoint Exchange. The picture below shows you what you’re looking for.

With the Secure Configuration Property Extension installed you ‘ll next set the configuration properties to identify the secret key and property file. The secret key will be used by Mule to decode the encrypted property.

In the General section above we’re using the ${env} property as a prefix to our property file. The reason for this is to make our approach extensible to the environments we’ll deploy into. Our approach will work well with the environments and property files shown below.

Example environments and property files

local-config.yaml
Dev-config.yaml
Test-config.yaml
Prod-config.yaml

For our secret, we pass the property when running in Anypoint Studio like this:

The env and secret are passed as VM args using -D when the JVM runs our application. When running in the Mule runtime engine you’ll need to inject the environment and property in the same way, but by adding them to the next available -D option in the wrapper.conf file. While this approach is mostly secure, and gets plain text passwords out of git repositories, it still has minor weaknesses that may not satisfy financial institutions or the ultra-paranoid. In high value environments there is still the risk of secret key being compromised in a file or the processes in memory instance. Weigh these considerations and risks carefully.

With your secret key added and the property file naming conventions properly established, you are ready to start encoding the properties that you wish to keep secret. In the prior version Mule 3 Vault application, the encode/decode process was somewhat simplified by using the secure property config editor. I imagine at some point this capability will return to 4.x as the product suite continues to mature, until the we’ll need to roll-up our sleeves and obscure our secrets the old fashioned way.

Lets start by downloading the encode/decode Jar file.

Encode and decode secure properties

# To encode your properties, our secret below is: keep-me-secret
# For AES CBC you will need a 16 byte key like this one: mulesofttfoselum
# See the Mule reference documentation for field descriptions
$ java -jar secure-properties-tool.jar \
    string encrypt AES CBC \
    mulesofttfoselum "keep-me-secret"

# Here's the encoded secret we produced
VAKvdYl7bgfYPVYjvLSXqA==

# If you forget your original password, you  
# can use reverse the process decode the secret
$ java -jar secure-properties-tool.jar \
    string decrypt AES CBC \
    mulesofttfoselum \
   "VAKvdYl7bgfYPVYjvLSXqA=="

# Here's the decoded secret we produced
keep-me-secret 

We’re almost done! When you’ve encoded your secrets, you can now add them to our yaml property file. If your properties are in yaml files they’ll need to be quoted. For the properties stored in legacy property files that end with .properties don’t use quotes.

Example snippet of yaml file secure property configutration

...
mySecret:
  dontTell: "![VAKvdYl7bgfYPVYjvLSXqA==]"

The yaml encoding needs to be quoted as you see above, if you’re using a legacy .properties it will look like this:

Example snippet of a legacy .properties file

mySecret.dontTell=![VAKvdYl7bgfYPVYjvLSXqA==]

When the mule engine is starting, either in AnyPoint or the standalone Mule application, it will detect that you’re configured to use secure properties. During startup it will decode the secure properties using the secret key you’ve injected and your connectors and resources will be able to use them just like normal.

If you were to print one of your secure properties in a Logger, it would display it’s decoded value. This is a handy way to test whether you’ve properly configured your settings. Just remember to remove the log message when you’re confident the solution is working properly.

Note: property prefix secure:: must be included in the string interpolation.

#[Enter with ${secure::mySecret.dontTell}]

That’s all there is to it, with these simple changes in place your application will be much more secure and compliant with a devsecops best practice.