Functional Monitoring - Mask authentication headers for Endpoints

The steps below are derived with a more detailed information based on the MuleSoft documentation for Using Secrets to Mask Sensitive Information in Monitors. It is recommended to read through this documentation before following the detailed illustration below.

The process consists of the below 4 steps.

1. Create shared secrets in Secrets Manager containing the information you want to mask
2. Creating a Monitor and modifying it to get the information from Secrets Manager
3. Granting the Monitor permission to access the secrets and creating aliases for the secrets
4. Upload the Monitor in Functional Monitoring UI

The following illustration uses masking ClientId and ClientSecret fields.

Step 1: Creating Shared Secrets

• Create a Secret Group in Secret Managers.
  
  
• Under Shared Secrets, create 2 entries for the clientId and clientSecret. Functional Monitoring only supports symmetric key format with the value encoded in Base64. You may encode the clientId and clientSecret values to base64 using this third-party website.
  
• Finish the setting up of the Secret Group.

Step 2: Create a Monitor and Modify it

• Create a new Monitor or use your already created Monitor. For this example, a new Monitor is created to hit a simple CloudHub application and send the credentials.
  
  
• After creating the Monitor download it. You will get a .ZIP file with all the information inside.

• The unzipped folder contains the files below.
  
  ▸ bat.yaml: Contains configuration information. We will modify it later on
  ▸ exchange.json: Here is the versioning information. This will be important when uploading the Monitor again
  ▸ main.dwl: The test code. Here we will modify the code to take the information from Secrets Manager
  
  
• Modify the main.dwl file las below.

import * from bat::BDD
import * from bat::Assertions

var cliId = secret('clientId-alias') default 'Client Not Found'
var cliSecret = secret('clientSecret-alias') default 'Secret Not Found'
---
suite("HTTP Monitor") in [
  it should "Assert endpoint: http://status-coder.ir-e1.cloudhub.io/status?code=200&reason=Ok" in [
    GET `http://status-coder.ir-e1.cloudhub.io/status?code=200&reason=Ok` with {
      "headers": {
        "client_id": cliId,
        "client_secret": cliSecret
      }
    } assert [
        $.response.status mustEqual 200
    ]
  ]
] 

The values highlighted in orange are aliases for the secretes stored in Secrets Manager. 

Step 3: Granting Permissions and Creating Aliases

This step requires installation of BAT CLI command-line tool. Refer to the docuemntation for Installing BAT. Additionally, refer to the API Functional Monitoring with the Blackbox Automated Testing (BAT) CLI documentation for understanding all the relevant BAT CLI commands.

Using API Functional Monitoring UI setup only requires executing bat login and bat grant commands as explained below.

• Configure or use a Connected App with Client Credentials grant type that has the sufficient permission to access the environment and Secret Managers. Refer to the documentation for Configuring Connected Apps.
• Execute bat login command as below using the Connected App's ClientId and ClientSecret.

bat login --client-id=<client_id> --client-secret=<client_secret>

• In the Terminal/Command Prompt tool, point to the unzipped Functional Monitor folder.
• Use bat grant command below to add the access to Secrets Manager in the Functional Monitor code.

bat grant -g=NewSecretGroup -s=clientId-alias:clientId-service0001,clientSecret-alias:clientSecret-service0001

• Below is the output after the command is successful.

Grants successfully generated.

• Additionally, the bat.yaml will be modified with new entries as below.
  
  

Now, the Monitor has access to the shared secrets through the aliases defined. 

Step 4: Upload Monitor

• Go to Functional Monitoring UI and click on Upload Monitor button.

• Select the Functional Monitor folder path from previous step that contains the modifications related to secrets manager. This method automatically identifies the existing monitor and updates it.
• Select the correct Private Location for monitor to run and Upload monitor.

Alternative method to upload using BAT CLI tool: (This method can be ignored if following the UI approach)

• Using BAT CLI run the following command in your terminal. (Always from the Monitor Folder)

bat location ls

This will return a list of the locations available for Monitor running.

IMPORTANT: The Monitor can only run in a Private Location and these locations consume vCores from your pool.

• From the list pick the id of the private location you want to use. If you do not have a private location, just create one from the UI and re-run the command. [ https://docs.mulesoft.com/api-functional-monitoring/afm-create-private-location ]
• Using the id run the following command to deploy the Monitor:

bat schedule create --target=<id>

• You should get an output like this:

BAT Version: 1.0.175
#  File: main.dwl
*** Setting script timeout (3599997 ms) ***
  
  HTTP Monitor
      
      Assert endpoint: http://<app-name>.cloudhub.io/status?code=200&reason=Ok
        ✓ GET http://<app-name>.cloudhub.io/status?code=200&reason=Ok (874.49ms)
          ✓ 200 must equal 200
#  Reporter: bat/Reporters/JSON.dwl >> /var/folders/5s/vcnnv4g14c3gg6sn4vzzb04h0000gp/T/bat_report_20210118174115.json
#  Reporter: bat/Reporters/HTML.dwl >> /var/folders/5s/vcnnv4g14c3gg6sn4vzzb04h0000gp/T/bat_report_20210118174115.html
#Creating artifact...
  + exchange.json
  + main.dwl
  + bat.yaml
  + .idea/.gitignore
  + .idea/workspace.xml
  + .idea/modules.xml
  + .idea/http-monitor_1.0.11.iml
  + .idea/misc.xml
# Creating artifact...OK
# Uploading <id>:http-monitor:1.0.11
# Version 1.0.12 published
scheduleId: a17ffa68-3adf-4284-9ea1-7266e38ea626

If you get an error saying the Monitor could not be uploaded, you will need to change the version in the exchange.json file.

After this, you will see the Monitor in your Functional Monitoring UI



Hit the play button and run it in the Private Location. Then in the History section, you will see the details of the call where the headers are masked



While in the logs of the application we can see the information reaching in the correct format