Dots&Arrows Mulesoft

How to manage your company’s credentials with HashiCorp’s Vault

A Mule 4 implementation tutorial

You can’t seem to go a few weeks without reading about another data breach. A portion of these data breaches are caused by insiders, employees. Someone with bad intentions or someone that holds a grudge. These individuals could either have gained access to certain systems, always had access or were trusted with access in order to exercise their job. Of course, some of the breaches were the result of laxness or ignorance, but it remains a huge risk for every company.

Property hell

Every developer has to work with secrets, an integration developer even more so. These may be database credentials, sensitive environment variables or API keys. As an integration developer/consultant, I’ve worked in an environment where secrets were stored as encrypted values within one large (private) repository on Git. We’re talking about one developer managing hundreds of secrets.

These secrets are generally stored in files within the project it belongs to. Sometimes they’re stored in a separate repository. In a lot of cases, especially when a company is using private code repositories, these are stored unencrypted. On top of this, secrets are often duplicated which makes managing them a job on its own.

These properties files may contain information that is directly related to sensitive data (especially those database credentials) or they may indirectly help anyone with bad intentions to get to the information they seek.

About Vault

HashiCorp’s open source Vault aims to reduce the risk by managing this sensitive information. Some of the key features include:

  • Secure Secret Storage
  • Data encryption/decryption
  • Secret revocation

The idea is to limit the exposure developers have to secrets. If developers have access to encrypted secrets, he/she might be tempted to look for a decryption key. We’ll be looking at how we can use Vault to manage these secrets centrally, ensuring that access to these isn’t handed out as if it were a flyer on some street corner.

Authenticating with Vault

Vault has a large set of authentication mechanisms, including one that’s aimed towards machines and services called AppRole. AppRole requires any application that requires access to the secrets storage to provide a static role ID and a dynamically generated secret ID. The authenticating machine or service will then be given a set of policies, allowing access to retrieve the secrets required to function correctly.

This secret ID doesn’t last forever, though. It will have a certain TTL (Time to live) before it expires. This ensures that services often have to renew their secret in order to be able to read from Vault.

Leasing, renewing revoking, auditing

Having to renew the secret ID grants Vault (and its operators) a clear view of how these secrets are used through auditing. On top of this, dynamic secrets enable access to certain systems with a built-in lease whilst at the same time not disclosing the actual credentials to the client. Both the authentication and dynamic secrets can be revoked at any time. The combination of the two above features gives you an unparalleled control over who’s able to access what and gives you insights into the usage of the secrets

Integrating with Vault Requirements

Vault CLI
My Vault properties provider

Setting up Vault

As a proof of concept, we can set up Vault using Docker:

docker run -p 8200:8200 –cap- add=IPC_LOCK -d –name=dev-vault vault

Authenticating and enabling AppRole

We can now get the root token from the container logs.

In order to work with the Vault CLI, we need to add VAULT_ADDR to our environment variables:

export VAULT_ADDR='

Once that’s in place, we can authenticate with Vault:

Next up, we can enable AppRole:

$ vault auth enable approle
Success! Enabled approle auth method at: approle/

Adding a role

Once AppRole is enabled, we can create a role for our application:

$ vault write auth/approle/role/mulesoft secret_id_ttl=120m token_ttl=30m
Success! Data written to: auth/approle/role/mulesoft

Getting the role ID and secret ID

We can now find out the role ID and secret that we’ll have to use to authenticate:

$ vault read auth/approle/role/mulesoft/role-id
Key        Value
---        -----
role_id    19cbe533-b9d1-ed8d-17db-ea51aa5b5db9
$ vault write -f auth/approle/role/mulesoft/secret-id
Key                   Value
---                   -----
secret_id             ef4a4d85-4d2a-e422-ec7b-23cb0fbdc1de
secret_id_accessor    bca6aa3f-4574-0825-f601-76de653cc9e4

Adding a secret

Now we have our role ID and secret ID. Let’s add a secret to our vault so that we can use it:

$ vault kv put secret/mulesoft hello="Hello world"
Key              Value
---              -----
created_time     2019-07-20T10:55:55.1036263Z
deletion_time    n/a
destroyed        false
version          1

Setting up a Mule project

Project creation
Use Anypoint Studio 7 to create a new Mule 4 project. I’ll name it ‘vault-test’:

Adding the Vault extension

Open the pom.xml file and add the Vault properties provider that you installed into your local maven repository as a dependency:


Creating the global element

Open the XML file in src/main/mule, switch to the ‘Global elements’ view and create the Vault Properties Provider config:

Configure the element to point to your local instance, using the role ID and secret ID. Set the path to secret/mulesoft:

Adding a flow that gets the secret

Add a simple flow with a scheduler that logs the property that we added before. The property has to be referenced using a custom prefix vault.

<flow name="vault-testFlow" >
  <scheduler doc:name="Scheduler" >
    <scheduling-strategy >
      <fixed-frequency frequency="10" timeUnit="SECONDS"/>
  <logger level="INFO" doc:name="Logger" message="#[p('vault::hello')]"/>

Run it!

Run your application! Your application should connect to your local Vault instance and get the property value:


Vault helps your business to keep its sensitive information private. With a standardized approach to interact with Vault, you can benefit from its features with only a minimal impact on development, making you and your business happier and safer. During this blogpost, we merely scratched the surface of what’s possible and I suggest you read up on the documentation if this tickled your fancy.


The provided Mule extension is a PoC and should not be used in production. It is by no means complete and does not support renewals and dynamic secrets. There’s no support for changing properties as it reads them in at startup only.

Ontmoet Dots & Arrows


Dots&Arrows maakt de brug tussen uw omgevingen en applicaties. Werk samen met een officiële Mulesoft partner die uw architectuur volledig doorlicht, bouwt en optimaliseert.