Safely Hiding Application Properties

logo cloud active logo hybrid disabled logo server disabled logo pcf disabled

CloudHub supports safely hidden application properties, where the name of a property is visible in the console, but the value is not displayed or retrievable by any user. CloudHub resolves the property at runtime without exposing the sensitive information.

Internally, safely hidden application properties are encrypted and stored in a MuleSoft managed CloudHub properties database, which is encrypted per user organization.

Safely hidden application properties are a feature that is currently only available for setting via the Runtime Manager UI for applications deployed to CloudHub workers. For applications that you deploy through any other deployment strategy, you need to use secure property placeholder files bundled with your application zip file.

Safely hidden application properties are a separate feature and concept from encryted Mule application properties that are stored in secure properties placeholder files, and securely access through a Credentials Vault.


Application Properties are variables that act as placeholders in your Mule application, and which are set in your Mule runtime at runtime. The Mule runtime supplies the values for the property variables using information you configure in the Runtime Manager console’s Properties tab, when you deploy an application or update an existing application in the Runtime Manager console.

Use Case

For example, you can configure a JDBC connector where the username is set to ${dbUsername} and the password is set to ${dbPassword}. In the Runtime Manager console, you can set these two properties as application properties, as shown below.


For sensitive information, you may wish to flag these properties as hidden so that, after they are entered and saved in the Runtime Manager console, their values are neither visible in the console nor passed between the console and the CloudHub server.

Creating Safely Hidden Application Properties

To create safely hidden application properties:

  1. Identify the property names that you wish to safely hide in your file by listing them as In the example below, there are four total properties used in the application (lines 1-4 below), which have been defined in the file with values for local testing (optional). Line 5 flags two of the properties as secure.

1. http.port=8081
2. username=testuser
3. password=testpass123
4. birthdate=01/01/2015
5., birthdate

The entry can only be written inside, but affects all properties no matter where (or if) they are defined. In general, you should store application properties in a separate Properties Placeholder file.

  1. Deploy the Mule application to CloudHub. 

  2. Enter your application properties as you normally would. 


  1. Commit your deployment or update. Once your application is deployed, navigate to the Deployment tab and check the application properties. The values for all properties that you had marked as safely hidden are now no longer visible to you or any other user. In the example below, birthdate and password are safely hidden, but username is not.


Once the values are committed and the application is uploaded, the safely hidden properties are never displayed on the console, nor sent and received between the console and the CloudHub server. There is no way to retrieve the property, once set. It can, however, be overwritten with a new value. So, if you need to update a value, type a new value into the field, as shown below.


Once an application is deployed with safely hidden application properties, CloudHub maintains the security flag for those properties. Even if you edit your application file to remove the definitions from your file and then upload that edited application file to CloudHub, CloudHub maintains the invisibility of the properties previously flagged as safely hidden.

Copying Safely Hidden Application Properties between Sandboxes When moving applications between sandboxes, safely hidden application property values will not be copied to the new environment. For all safely hidden application properties, the name of the property will be copied, but the value will be left blank. 

Encrypted Application Properties vs. Safely Hidden Application Properties

Mule applications can also store properties with encrypted values using secure properties placeholders.

See Credentials Vault for more information on creating and using secure properties placeholders.

With encrypted properties, the Mule application bundles the secure property placeholder files inside the Mule application’s deployable archive .zip file.

A secure property placeholder combines together the file containing the encrypted properties, plus details about the encryption algorithm that is used to encrypt the secure property values. Secure properties are encrypted using a secret key. It is important to never store the secret key inside your Mule applications. Instead, you need to safely (securely) pass in the secret key value at deployment time.

To facilitate safely passing in the secret key into the Mule application, the Mule application can be developed with a property placeholder to represent the secret key value. There are then several options for how an operator can safely pass in the secret key value at deployment time.

For deployments to customer-hosted Mule runtimes, where the operators have access to the file system and the command-line, the secret key can be passed in by setting a system environment variable when the Mule runtime is started up. If the file system is secure, it also might be safe to store the secret key in a special secure folder on the file system, with restricted permission for the Mule application to safely read in the secret key at startup time. Once the secret key is read into memory, it is used by the Mule application to decrypt all the other properties in the secure properties placeholder, and the decrypted values are stored in memory. To secure the Mule application, it is important to lock down access to the Mule runtime’s host, so that no one can read the Mule application’s memory or JVM properties.

Starting a CloudHub Application That Uses Encrypted Properties

Mule applications can also be developed to store encrypted properties in secure properties placeholder files.

For CloudHub deployments, none of the secure deployment approaches discussed for customer-hosted deployments is available in CloudHub, because operators do not have access to the CloudHub worker’s file system, nor can they log in to a command-line to start up the CloudHub worker.

Encrypted properties can also be flagged as safely hidden application properties, by listing the encrypted property’s name in the entry in the Mule application’s file. In particular, the secret key used to decrypt the encrypted properties can be set as a safely hidden property in the file’s variable.

Here is an example:

1. http.port=8081
2. username=testuser
3. password=![r8weir09458riwe0r9484oi]
4. birthdate=01/01/2015

1., password, birthdate

Then, at deployment time, the operator can type in the secure.key value into the Runtime Manager Properties tab for the deployment. Because the secure key is flagged to be hidden in the console, no one can see what the operator is typing.

Once the secret key is passed into the Mule application, encrypted properties are decrypted into memory just like they are with customer-hosted deployments. This is a safe thing to do in CloudHub, because CloudHub workers are highly secure, with no access to the CloudHub worker’s command-line, nor is there any way for an intruder to read the CloudHub worker’s memory or JVM properties.

How to Override Encrypted Properties

Encypted properties that are bundled with a Mule application inside a secure properties placeholder file will not appear in the Runtime Manager Properties tab. In this way, the values are safely locked inside the Mule application.

But a problem arises when an operator needs to update an encrypted value. The Runtime Manager console does not have access to the secret key, so it is impossible to replace an encrypted value with a new encrypted value without opening up the Mule application source files, recoding the new encrypted value with the secret key, then regenerating the Mule application’s deployable archive. In many environments, runtime operators are not allowed to rip and replace the Mule application’s deployable archive file like this, so instead the Mule application would have to be sent back to developers.

But there is a way for a Mule application to be designed to allow operations staff to safely override encrypted properties. If encrypted property names are also listed in the Mule application’s '' entry in '', then once the application is deployed, the value of this encrypted property will also be hidden in the Runtime Manager Properties tab, just like decrypted properties, and just like other properties, the decrypted value is only stored in the Mule worker’s memory and securely stored in the CloudHub database for your user account, and is never stored in any CloudHub worker’s files, nor is it ever passed between any other machines (including the Runtime Manager Console).

So for any encrypted property that is also marked as safely hidden in the Mule application’s entry, you can safely replace any encrypted property with a clear-text value, which will be securely stored in the CloudHub properties database, and securely passed in to the Mule application ever time the Mule application is started.

The new value is also hidden once the application is deployed and can never be viewed again.

This means that when you override a secure property in the CloudHub properties tab for the application, the values never needs to be encrypted. In this scenario, securing the values of sensitive properties is reduced to controlling which operators have access to those values when they deploy or redeploy the secure application.

For example, if a production application needs to update the database user and password stored in two properties named db.user and db.password, then an operator would enter this new db.user and db.password into the CloudHub properties tab for the application and then Start or Restart the application. This allows the new application to upgrade this secure login information with zero downtime. Once all dependant applications are migrated, the old account could be decomissioned.

CloudHub Mule Applications Do Not Need Encrypted Properties

The previous discussion indicates that for Mule applications that will only be deployed into CloudHub workers, you may not need to encrypt properties, but instead just flag those properties as safely hidden propreties in the Mule application’s '' file’s entry.