Hardening Mule Runtime on Runtime Fabric

By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default.

The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric.

Hardening Checklist

Table 1. Mule Hardening Procedure
Hardening Step	Action Required
Run Mule as a non-privileged User.	Runtime Fabric provides this functionality.
Install Mule as a Service	Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.
Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.	Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.
In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.	Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.
Manage certificates in a keystore file.	This is supported on Runtime Fabric, but you must import the certificates into the keystore. In addition, Runtime Fabric includes a load balancer, which can handle SSL termination for all Mule runtime engines deployed within it.
Use a separate property file to store usernames and passwords and secure it using file system permissions.	Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.