Reading Time: 9 minutes

MuleSoft’s Anypoint Controller, a Kubernetes-native interface, gives you additional flexibility to externalize secret management for hybrid Mule applications running on Anypoint Runtime Fabric (RTF). You can now choose a third-party Secret Manager to dynamically access and rotate credentials, API keys, certificates, and other sensitive data without hardcoding them into your application or configuration files, enhancing security and operational agility through centralized secret management. 

Why should you use a centralized secret manager?

Applications need credentials and other sensitive information to function. For example, a web application might need login credentials to connect to a database, API tokens for third-party integrations, or encryption keys to secure user data. Storing such critical information in code repositories or configuration files poses a significant security risk and complicates credential rotation. A centralized secret manager enables you to only provide reference to where the secret data resides and mount them with application pods at runtime, simplifying secret rotation and access management.   

While MuleSoft offers a proprietary Secret Manager service, a feature-rich and secure tool for customers within Anypoint Platform, we wanted to provide you more flexibility in choosing which secret management tool to use with your hybrid deployments, whether on-prem or on a public cloud provider. 

This allows you to assimilate your security and DevOps for Mule applications with your existing organization-wide practices, allowing for central management of sensitive information.   

Anypoint Controller for External Secrets management

Anypoint Controller provides you a new Kubernetes native interface through which you can define your Mule applications and their deployment configuration as a Kubernetes Custom Resource. This interface supports both existing properties such as CPU and Memory allocation, and new properties such as Secret Reference in a single version-controlled file. You use the familiarized mechanism of volume mounting to provide the secrets to your application pods. 

To get started, you need to install or upgrade your Runtime Fabric to 3.0.1 version and enable Anypoint Controller and Mule Application Custom Resource Definition (CRD). This also means that you can now use CI/CD tools to automate Mule application deployment.  

1. Install or upgrade Runtime Fabric using Helm

After you have created RTF through Anypoint Runtime Manager, you install RTF on your Kubernetes cluster using Helm and the values.yaml file you download from the Runtime Manager. For step wise instructions, refer to the RTF documentation. 

Next, in the values.yaml ensure that the following values are set to true to install Anypoint Controller and CRD respectively. 

global.crds.install = true
agent.rtf.anypointController.enabled = true

2. Define Mule application custom resource

Once you’ve installed the CRD, define your Mule application as a custom resource. You create a yaml file to define various deployment related specifications such as CPU and memory resources allocated towards your application, replica count, and all the other properties that RTF supports. Additionally, you can define your Secrets references. 

Depending on the tools you want to use for secret management, there are broadly two options to choose from. You can either use the Kubernetes native Secrets that store the secret data on the Kubernetes cluster or use a third-party tool like AWS Secret Manager, Hashicorp Vault, etc. The following code snippets show how easily you can configure your Mule applications to refer to the secrets separately for these options.

Option 1: Use Kubernetes Secrets

First, you create a Secret in your Kubernetes cluster. You may either specify the key-value pair while creating the Secret or create a secret file. In the following example, we assume you created a Secret with the name my-secret that maps to a secret file. 

Now, to let the application pod to mount this file in its local filesystem, we define the volume and volume mount in the Mule application custom resource. The following snippet is truncated to show the relevant fields only. 

apiVersion: rtf.mulesoft.com/v1
kind: MuleApplication 
metadata:
    name: my-hello-world-app
    namespace: anypoint-controller-app
spec:
.
.
.
    volumes:
        - name: my-secret-as-volume
          secret:
            secretName: my-secret
    volumeMounts:
        - name: my-secret-as-volume
          mountPath: /my-app/secret
          readOnly: true

Option 2: Using an External Secret Manager through CSI driver

If you want to use an external Secret Manager and not store your secret data on the Kubernetes cluster, now you can do that as well for your Mule applications using the Secret Store CSI driver. Refer to the documentation of your external store on how to create a secretProviderClass, a Kubernetes custom resource that maps to the external Secret Manager and the secret data you want to refer to in your application.

We’ll go on the assumption that you’ve created a secretProviderClass: “my-external-secret” that we’ll configure the Mule application with. The configuration is done in a similar manner as the previous option, except that the volume defined is referring to an external secret store. 

apiVersion: rtf.mulesoft.com/v1
kind: MuleApplication 
metadata:
    name: my-hello-world-app
    namespace: anypoint-controller-app
spec:
.
.
.
    volumes:
        - name: my-secret-as-volume
          csi:
              driver: secrets-store.csi.k8s.io
              readOnly: true
              volumeAttributes:
                  secretProviderClass: “my-external-secret”
    volumeMounts:
        - name: my-secret-as-volume
          mountPath: /my-app/secret
          readOnly: true

Elevate RTF security with External Secret Management

This new capability for external secret management with Anypoint Runtime Fabric empowers MuleSoft users with unprecedented flexibility and enhanced security. By integrating seamlessly with your existing Kubernetes and secret management solutions, you can streamline your DevOps practices and ensure sensitive data is handled with the utmost care. This means more secure, agile, and efficient application deployments. To dive deeper and step-wise details to unlock the full potential of this feature, be sure to consult the comprehensive Runtime Fabric user guide.