Skip to main content
Feedback

Boomi Secrets Management Service

Boomi's Secrets Management service allows customers to store their secrets in a remote secrets manager that they alone have access to. Boomi will never have access to this manager, since only references to secrets are entered in the Boomi Enterprise Platform.

note

You must have the SECRETS_MANAGEMENT feature on the chosen account to utilize Secrets Management. If you want to utilize Secrets Management on cloud runtimes, you will also need the RUNTIME_MANAGEMENT feature. Reach out to your Boomi account representative to activate these features.

Service Structure

  • Platform: In the Platform interface, you can configure environment extensions to point to specific secrets in your remote secrets manager.

  • Runtime: In the Boomi runtime, you can use the secrets management plug-in to retrieve secrets from a previously configured third-party secrets manager and invalidate the secret cache on the runtime to prepare the runtime for a rotated secret.

To learn more about how you can use the Secrets Management service on private and public clouds, or through Managed Cloud Services, refer to Enabling Secrets Management on cloud runtimes.

  • AWS Secrets Manager: You can store secrets you want to reference in AWS's secrets manager.

  • Azure Secrets Manager: You can store secrets you want to reference in Azure's secrets manager.

  • Google Cloud Platform (GCP): You can store secrets you want to reference in GCP's secrets manager.

Execution errors are stored in Process Reporting container logs.

Enabling Secrets Manager on local runtimes

In the Platform, navigate to Integration > Runtime Management. Then, select an environment and click Environment extensions. Select the Use Secrets references checkbox to expose additional fields.

Setting up AWS

  1. In the Advanced Properties tab, set Enable AWS Secrets Manager to true, and enter the region you want to use with secrets management into AWS Secrets Manager Region field.

  2. Configure the AWS credentials for the runtime instance by following any of the methods defined in the Amazon Default provider chain documentation

  3. Configure plaintext secrets in the AWS secrets manager with the account and region you allowed the runtime instance to access.

Setting up Azure Key Vault

  1. In the Advanced Properties tab, set Enable Azure Secrets Manager to true.

  2. Configure the Azure credentials for the runtime instance by following any of the methods defined in the Default AzureCredential documentation

  3. Configure plaintext secrets in the AzureKeyVault you allowed the runtime instance to access.

Setting up GCP

  1. In the Advanced Properties tab, set Enable Google Cloud Platform Manager to true.

  2. Configure the Azure credentials for the runtime instance by following any of the methods defined in the GCP Application Default Credentials documentation

  3. Configure plaintext secrets in the GCP secrets manager you allowed the runtime instance to access.

Refer to Secrets Management for Cloud Runtimes to set up secrets management on cloud runtimes.

Enabling Secrets Management on cloud runtimes

note

Before beginning, ensure you and/or your users have the RUNTIME_MANAGEMENT feature enabled. You can reach out to your Boomi account representative to activate this feature.

You can use Boomi Secrets Management Service on a cloud runtime attachment by following the steps below. You can push AWS or Azure credentials to individual runtime cloud attachments; you can not push GCP credentials currently.

If you are the cloud owner:

In the Advanced Properties tab, set the following enablement properties for your runtime cloud at the cloud owner level:

  • Set the Advanced Property Enable AWS Secrets Manager or Enable Azure Secrets Manager to true
  • Set the Custom Property: com.boomi.container.cloud.forker.security.v2 to true

If you are a user with a cloud runtime attachment:

Ensure you have the AWS or Azure credentials for a user, role, application, or entity with access to the desired secrets manager.

AWS users will need to specify an AccessKeyID, SecretAccessKey, and AWS Region that points to a user with access to the desired secrets manager secret(s). Azure users will need to specify the ClientID, TenantID and Client Secret for a user or an authorized application with access to the desired Key Vault secret(s).

Send your secrets manager credentials to your runtime to connect your cloud runtime attachment to a secrets manager with the API call below.

Send a POST request to the following platform endpoint: <platform_url>/api/rest/v1/<AccountID>/cloudAttachmentSecretsConfiguration/<runtimeID>

AWS Request Body


{
  "containerId": "<runtimeId>",
  "secretsManagerProvider": {
    "AWS": {
      "awsAccessKeyId": "<Enter Access Key ID>",
      "awsSecretAccessKey": "<Enter Secret Access Key>",
      "awsRegion": "<Enter AWS Region of Secrets Manager>"
    }
  }
}

Azure Request Body


{
  "containerId": "<runtimeID>",
  "secretsManagerProvider": {
    "AZURE": {
      "azureClientId": "<Enter Client ID>",
      "azureTenantId": "<Enter Tenant ID>",
      "azureClientSecret": "<Enter Client Secret>"
    }
  }
}

Now that the Secrets Management service is configured, you can create secrets either using the Environment Extensions page in Platform, or with the Environment Extensions API. Refer to Using Secrets Management to learn more.

Secrets caching

Your secrets are never stored in the file system; they are contained in an individual Java classloader. These cached secrets are only stored for one hour, and do not persist between restarts, the creation of a new execution worker, or the creation of a new forked process execution.

To coordinate the caching of secrets with your secret rotation practices, the provided refreshSecretsManager API allows you to reset the secret cache on all runtimes in an account. This ensures that the runtimes in your account directly retrieve secrets from the external secrets manager the next time the secret is referenced.

On this Page