MuleSoft Secrets Manager
Secrets Manager is MuleSoft's cloud-based vault for storing sensitive configuration values — passwords, API keys, certificates, TLS keystores, and tokens. Instead of hardcoding credentials in configuration files, you store them securely in Secrets Manager and reference them by name in your Mule applications.
Why Secrets Manager
Storing passwords in plain-text configuration files creates serious security risks. Anyone with access to the source code or deployment artifacts can read credentials. Secrets Manager solves this by storing secrets encrypted, applying access controls, tracking who accessed what, and enabling rotation without redeploying applications.
Secret Storage Comparison
WITHOUT Secrets Manager (risky):
config.yaml:
db.password: "SuperSecret123" ← visible to all developers
sf.token: "abc123xyz" ← stored in git history forever
api.key: "prod-key-9999" ← anyone with repo access sees it
WITH Secrets Manager (secure):
config.yaml:
db.password: ${secret::db-password} ← references vault, no actual value
sf.token: ${secret::sf-api-token}
api.key: ${secret::prod-api-key}
Actual values stored encrypted in Anypoint Secrets Manager:
Only the Mule runtime and authorized users can retrieve them.
Types of Secrets
Anypoint Secrets Manager supports several secret types:
- Shared Secret: Any text value — passwords, API keys, connection strings, tokens.
- Certificate: PEM or DER format X.509 certificate for TLS.
- Certificate with Private Key: A TLS keypair (certificate + private key).
- TLS Context: A complete TLS configuration bundle — keystore, truststore, and cipher settings.
- Keystore: A JKS or PKCS12 keystore file.
- Truststore: A truststore file for validating certificates of external services.
Creating a Secret in Anypoint Secrets Manager
Navigate to Anypoint Platform > Secrets Manager. Select your environment (Development, Staging, or Production). Secrets are environment-scoped — a secret in Production is separate from the same-named secret in Development.
- Click Create Secret Group (a group organizes related secrets for one application or team)
- Name the group:
orders-api-secrets - Inside the group, click Add a Secret
- Select type: Shared Secret
- Enter:
- Name:
db-password - Value: the actual database password
- Name:
- Click Save
Secret Group Structure
Anypoint Secrets Manager
│
├── Environment: Production
│ └── Secret Group: orders-api-secrets
│ ├── Shared Secret: db-password
│ ├── Shared Secret: sf-api-token
│ ├── Certificate: api-server-cert (TLS certificate)
│ └── Keystore: api-keystore (JKS file)
│
└── Environment: Development
└── Secret Group: orders-api-secrets
├── Shared Secret: db-password (different dev value)
├── Shared Secret: sf-api-token (sandbox token)
└── Keystore: api-keystore (self-signed cert)
Referencing Secrets in Mule Applications
Reference secrets from Secrets Manager using the secrets:: prefix in your configuration properties or directly in connector configurations.
Referencing in config.yaml
# config.yaml
database:
host: prod-db.mycompany.com
port: 5432
name: orders_db
username: mule_user
password: ${secrets::db-password}
salesforce:
username: integration@mycompany.com
token: ${secrets::sf-api-token}
email:
smtpPassword: ${secrets::smtp-password}
Referencing TLS Context from Secrets Manager
HTTP Listener TLS Configuration: TLS Context Source: Secrets Manager Secret Group: orders-api-secrets TLS Context Name: api-tls-context (MuleSoft retrieves the keystore, truststore, and cipher settings directly from Secrets Manager at startup — no local files needed)
Secure Properties Tool (Local Encryption)
For properties that must be stored locally (not in Secrets Manager), use MuleSoft's Secure Properties Tool. This tool encrypts individual property values so they appear as encrypted strings in configuration files. Even if someone accesses the file, they cannot read the actual value without the encryption key.
Encrypting a Property Value
Download the Secure Properties Tool JAR from Anypoint Exchange.
Encrypt a value:
java -jar secure-properties-tool.jar string encrypt AES CBC myEncryptionKey "SuperSecret123"
Output: W/Jkh4e9ZzKkk8OmPqO5VA==
Store in config.yaml:
db.password: "![W/Jkh4e9ZzKkk8OmPqO5VA==]"
(the "!" prefix tells MuleSoft this value is encrypted)
Reference in application:
${secure::db.password}
At runtime, MuleSoft decrypts using the key set as:
-Dmule.key=myEncryptionKey (system property on startup)
Access Control for Secrets
Not every developer should access production secrets. Secrets Manager integrates with Anypoint Platform's role-based access control.
Secret Access Roles
Role │ Can View │ Can Create │ Can Delete │ Runtime Access ----------------------|----------|------------|------------|--------------- Secrets Manager Admin │ YES │ YES │ YES │ YES Developer │ NO │ NO │ NO │ YES (via app) Operations │ YES │ YES │ NO │ YES Read Only │ YES │ NO │ NO │ NO
Secret Versioning and Rotation
Secrets Manager maintains versions of each secret. When you rotate a credential (change a database password), create a new version of the secret. The Mule application picks up the new value on the next restart or when you trigger a secret refresh. Old versions remain accessible for rollback if needed.
Rotation Workflow: 1. DBA creates new database password 2. Admin creates new version of "db-password" secret in Secrets Manager 3. Redeploy Mule application (or trigger hot refresh if supported) 4. Application uses new password 5. DBA revokes old password from the database 6. Old secret version remains in Secrets Manager for 30 days then purged
Audit Logging for Secrets
Every access to Anypoint Secrets Manager — create, read, update, delete — is logged in Anypoint Platform's audit log. Security teams use these logs to detect unauthorized access attempts and comply with regulatory requirements like SOC 2, PCI-DSS, and HIPAA.