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
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. |
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. |