Secrets Manager | MuleSoft Documentation
# Secrets Manager
Anypoint Security secrets manager uses secure vault technology to store and control access to private keys, passwords, certificates, and other secrets.
If you can’t access the secrets manager or you receive an error saying `Cannot Create Secret Groups`, you must add the correct permissions in Access Management:
  * If you need access only to secrets manager and don’t manage instances of Anypoint Runtime Fabric, add the appropriate user permissions in **Access Management > Permissions > Secrets Manager**.
  * If you manage instances of Runtime Fabric, add only the **Manage Runtime Fabric** permission (you don’t need to add the **Secrets Manager** permission separately).

  
---  
Use secrets manager to write and manage your secrets, keys, and Transport Layer Security (TLS) artifacts. You can read the metadata of the secrets, but the actual secrets can be consumed only by authorized platform services on your behalf.
Secrets manager is designed to store and manage secrets for supported Anypoint Platform services. It’s not a general-purpose storage for secrets. Only trusted services within Anypoint Platform have access to the contents of the secret.
Secrets manager supports the management of TLS context for these services:
  * Runtime Fabric ingress
You can store TLS artifacts in secrets manager and then configure Anypoint Runtime Fabric ingress with the secret reference. Secrets manager supports Runtime Fabric ingress only for Runtime Fabric on VM/Bare Metal (Appliance).
  * API Manager on Anypoint Platform
You can store the TLS artifacts in secrets manager and then configure Anypoint API Manager with the secret reference.
See Building an HTTPS API Proxy.


Secrets manager enables you to store secrets in secrets groups, which are vaults associated with your environment and business group. Each secrets group has unique encryption keys, which are generated and managed only by secrets manager.
You can configure the supported Anypoint Platform services to request secrets stored in secrets manager, and you can control which supported services are authorized to access them. This task is handled by two microservices:
  * Secrets manager
This is a publicly exposed service that handles the uploading and storing of your secrets. Every time you upload a secret to your vault, the secrets manager establishes a reference to it, so it can be shared or read without revealing its contents. You can read the secrets metadata but not the secret itself.
  * Secrets Provider
This is an internal service that handles the secrets for consumption by supported platform services. This is the only service that can read the actual secrets and due to its nature, it’s not accessible from the public network.


## Supported Secret Types
Secrets manager can store and manage these secret types:
  * TLS Context
SSL Security Parameters (ciphers to use, TLS version, and so on).
  * Keystore
A repository of security certificates (either authorization certificates or public key certificates), along with their corresponding private keys.
  * Truststore
A repository of security certificates from either other parties with which you expect to communicate, or Certificate Authorities that you trust to identify other parties.
  * Certificates
Public X.509 certificates, which are electronic documents that bind a public key with an identity (hostname, organization, or individual).
  * Certificate Pin Set
A repository of security certificates from other parties that associate a client or host with their expected X.509 certificate or public key.
  * CRL Distributor
An entity that creates and maintains a list of CA certificates that are no longer trusted because their associated private keys, or a signing CA, were compromised.


### Limitations
  * A maximum of 25 secret groups per environment per business group are allowed.
  * Each secret group can contain a maximum of 350 secrets.
  * Shared secrets are used for symmetric encryption and decryption, where the secret is known by both the message sender and the message recipient. These shared secret types are defined, however, Anypoint Platform services can’t consume them:
    * Passwords
A password used by the sender and recipient to encode and decode the message.
    * Symmetric Keys
A public key cryptography used by the sender and recipient to encode and decode the message.
    * S3 Credentials
A pair of security keys to access AWS S3 buckets.
    * Blob
A free-form and application-specific secret stored through an API call. Blobs are base64-encoded data used by specific applications. For example, a blob can store a base64-encoded JSON object.


## See Also
  * Supported Secret Types Reference
  *   * Secrets Manager Permissions
  * Enable Inbound Traffic on Anypoint Runtime Fabric
  * Building an HTTPS API Proxy