Introducing Agent Safe Governance for the AI Era

Authenticate Liquibase to MongoDB with AWS IAM

Last updated: July 9, 2026

Liquibase Secure supports the MONGODB-AWS authentication mechanism, which lets you authenticate to MongoDB Atlas and Amazon DocumentDB using AWS IAM credentials instead of a username and password.

This eliminates the need to manage database passwords separately. Liquibase uses your existing AWS identity, so access is controlled through IAM policies you already maintain, and credentials rotate automatically when using instance roles.

MongoDB Atlas is a managed cloud database service from MongoDB Inc.; Amazon DocumentDB is a separate AWS-managed database service that is compatible with the MongoDB API. Both support MONGODB-AWS authentication, but DocumentDB has additional requirements covered in this article.

Known limitations: - Elastic clusters are not supported. - IAM authentication is not supported for the primary or master database user.

Before you begin

  • Liquibase Secure with the MongoDB extension installed

  • A MongoDB or DocumentDB cluster with an $external user registered for your IAM principal, with the required database roles (for example, readWriteAnyDatabase)

  • Valid AWS credentials available to Liquibase, to use in step 2 below

  • DocumentDB runs in a private VPC and cannot be reached from the public internet. If Liquibase runs in the same VPC as your cluster, no additional network setup is needed. For local testing, complete Step 5 to open an SSM tunnel.

Note: MONGODB-AWS authentication requires DocumentDB 5.0 or later on instance-based clusters.

Procedure

1

Install required tools

Install the following tools before you begin. You will need the AWS CLI to manage credentials, the Session Manager Plugin to open the network tunnel in Step 5, and mongosh to verify your connection.

brew install awscli mongosh
brew install --cask session-manager-plugin
  • mongosh must be 2.4 or later. Older versions fail with a misleading SignatureDoesNotMatch error.

  • If mongosh is not recognized after installing, open a new terminal window to pick up the updated PATH.

winget install Amazon.AWSCLI
winget install MongoDB.Shell
  • AWS distributes the Session Manager Plugin for Windows as an MSI installer only. It is not available through winget. Download the installer from the AWS Session Manager Plugin documentation.

  • If mongosh is not recognized after installing, open a new terminal window to pick up the updated PATH.

2

Configure your AWS credentials

Liquibase uses the MongoDB driver's default AWS credential chain to resolve your base credentials, checking environment variables, the shared credentials/config file, web identity token (IRSA), container credentials, and the EC2 instance profile, in that order. Choose the method that matches your environment below.

Liquibase never logs AWS credential values, tokens, or SigV4 signatures, even at debug level. Connection strings are redacted before being written to logs.

Note: If Liquibase needs to assume a different IAM role to access the cluster, complete this step first, then see Step 3 (Assume a different IAM role).

Sign in to AWS and choose your credential method

If Liquibase runs on an AWS compute resource (EC2, ECS, EKS, or Lambda), credentials are available automatically through the instance metadata service. No additional configuration is needed. Liquibase detects and uses the role assigned to the instance or task.

Obtain temporary credentials from your AWS access portal, then export them in the same terminal session where you run Liquibase:

export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
export AWS_SESSION_TOKEN=your_session_token

Be sure to:

  • Replace your_access_key_id, your_secret_access_key, and your_session_token with temporary credentials from your AWS access portal

Note: If your AWS profile uses AWS IAM Identity Center (SSO), setting AWS_PROFILE to that profile is not enough. This credential method does not perform the SSO login flow. Export short-lived credentials from the profile instead:

eval "$(aws configure export-credentials --profile your_profile_name --format env)"

Be sure to:

  • Replace your_profile_name with your AWS SSO profile name

Then run Liquibase in the same terminal session.

Note: If you previously exported static AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_SESSION_TOKEN values in this terminal session, unset them first. Stale exported credentials take precedence over ~/.aws/credentials even after they expire, causing authentication failures that look unrelated to SSO.

Verify your credentials are working:

aws sts get-caller-identity
3

Optional: Assume a different IAM role

If Liquibase runs under one IAM identity but needs to assume a different role to access the cluster, configure AssumeRole.

Note: If you don't need to assume a different role, skip this step.

AssumeRole builds on the base credentials from Step 2. It does not provide credentials on its own. Complete Step 2 (Instance role or Environment variables) first, then add the following to your liquibase.properties file:

liquibase.mongodb.aws.region=your_aws_region
liquibase.mongodb.aws.roleArn=your_role_arn
liquibase.mongodb.aws.sessionName=your_session_name

Be sure to:

  • Replace your_aws_region with the AWS region of your cluster. Required when using AssumeRole. For example, us-east-1

  • Replace your_role_arn with the ARN of the role to assume. For example, arn:aws:iam::123456789012:role/your_role_name

  • Replace your_session_name with a name to identify the session. Optional. If omitted, Liquibase generates one automatically. For example, liquibase-session

Note: liquibase.mongodb.aws.* properties can only be set in your liquibase.properties file, environment variables, or a defaults file. They are not accepted as -D command-line arguments.

4

Optional: Run changesets with the mongosh native executor

Some changesets need to run raw mongosh commands or scripts that can't be expressed as a standard MongoDB change type. Liquibase supports this using the mongosh native executor (runWith="mongosh"). For details on configuring native executors, see Use native executors with MongoDB Secure.

Note: If you don't run changesets with runWith="mongosh", you can skip this step.

When a changeset runs through the mongosh executor, Liquibase automatically passes your resolved AWS credentials to the mongosh subprocess as environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN when present). If you configured AssumeRole in Step 3, the temporary credentials from the assumed role are passed instead of your base credentials. No additional configuration is needed.

5

DocumentDB only: Open a network tunnel

Important: Open a dedicated terminal window for this step. The tunnel must stay running in its own terminal for the rest of the procedure. Do not use this terminal for anything else.

Use this step when running Liquibase on a local machine outside the DocumentDB cluster's VPC. If Liquibase runs on EC2, ECS, or another compute resource inside the same VPC as your cluster, skip this step.

aws ssm start-session opens an encrypted tunnel from your local machine to the DocumentDB cluster through a bastion instance in the VPC. Once the tunnel is running, Liquibase connects to localhost:27017, which forwards traffic to your cluster. For more information, see the AWS Systems Manager Session Manager documentation.

loading

Be sure to:

  • Replace your_instance_id with your bastion instance ID. For example, i-0123456789abcdef0

  • Replace your_cluster_endpoint with your DocumentDB cluster endpoint. For example, mydb.cluster-abc123.us-east-1.docdb.amazonaws.com

  • Replace your_aws_region with your AWS region. For example, us-east-1

Note: If a local MongoDB instance is already using port 27017, change localPortNumber to an available port (for example, 27020), and update the port in your connection string in Step 8 to match.

Leave this terminal running. Open a new terminal window and complete the remaining steps there.

6

DocumentDB only: Download the TLS certificate bundle

DocumentDB requires TLS for all connections and uses AWS's own private Certificate Authority (CA), which is not trusted by default on most systems. The global certificate bundle contains the CA certificates your client needs to verify it is connecting to a legitimate DocumentDB cluster. Without it, the TLS handshake fails.

Download the bundle and store global-bundle.pem in a location accessible to Liquibase. You will reference this path in Step 8.

Choose your operating system

curl -sO https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Invoke-WebRequest -Uri https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem -OutFile global-bundle.pem
7

DocumentDB only: Import the CA certificate bundle into a Java trust store

Java does not read tlsCAFile from the connection string. Instead, it uses its own certificate trust store. Run the script below to create a JKS trust store from global-bundle.pem using keytool, then set JAVA_TOOL_OPTIONS to point Liquibase to it.

Choose your operating system

First, confirm JAVA_HOME is set. If Liquibase is installed using the standard installer it is set automatically, but if the command returns nothing, set it before continuing:

loading

Then run the following script from the same directory as global-bundle.pem to create the trust store:

loading

Note: Do not replace this loop with a single keytool -importcert -file global-bundle.pem call. That only imports the first certificate in the bundle, which can cause PKIX path building failed errors when connecting to clusters in other AWS regions.

Then set JAVA_TOOL_OPTIONS in the same terminal session where you will run Liquibase:

export JAVA_TOOL_OPTIONS="-Djavax.net.ssl.trustStore=$HOME/docdb-truststore.jks -Djavax.net.ssl.trustStorePassword=liquibase"

First, confirm JAVA_HOME is set. If Liquibase is installed using the standard installer it is set automatically, but if the command returns nothing, set it before continuing:

loading

Then run the following script from the same directory as global-bundle.pem to create the trust store:

loading

Note: Do not replace this loop with a single keytool -importcert -file global-bundle.pem call. That only imports the first certificate in the bundle, which can cause PKIX path building failed errors when connecting to clusters in other AWS regions.

Then set JAVA_TOOL_OPTIONS in the same terminal session where you will run Liquibase:

$env:JAVA_TOOL_OPTIONS = "-Djavax.net.ssl.trustStore=$env:USERPROFILE\docdb-truststore.jks -Djavax.net.ssl.trustStorePassword=liquibase"
8

Configure the Liquibase connection string to authenticate to the database cluster

Set the url property in your liquibase.properties file. If you do not already have one, create it in the directory where you will run Liquibase.

Note: authSource=$external is required for MONGODB-AWS authentication. The Liquibase MongoDB extension sets this automatically. You do not need to include it in the connection string.

Choose your database connection method

url=mongodb://your_cluster_endpoint:27017/?authMechanism=MONGODB-AWS&tls=true&tlsCAFile=your_ca_bundle_path&retryWrites=false

Be sure to:

  • Replace your_cluster_endpoint with your DocumentDB cluster endpoint. For example, mydb.cluster-abc123.us-east-1.docdb.amazonaws.com

  • Replace your_ca_bundle_path with the path to global-bundle.pem from Step 6. For example, /path/to/global-bundle.pem

Note:

  • retryWrites=false is required for DocumentDB. DocumentDB does not support retryable writes, and omitting this parameter will cause connection errors.

  • The Java driver gets TLS trust from the trust store created in Step 7, not from tlsCAFile. Keep tlsCAFile in the URL anyway. It's used by the mongosh native executor (see Step 4).

url=mongodb://localhost:27017/?authMechanism=MONGODB-AWS&tls=true&tlsCAFile=your_ca_bundle_path&tlsAllowInvalidHostnames=true&directConnection=true&retryWrites=false

Be sure to:

  • Replace your_ca_bundle_path with the path to global-bundle.pem from Step 6. For example, /path/to/global-bundle.pem

Note:

  • retryWrites=false is required for DocumentDB. DocumentDB does not support retryable writes, and omitting this parameter will cause connection errors.

  • tlsAllowInvalidHostnames=true and directConnection=true are required when connecting through the SSM tunnel because the TLS certificate is issued for the cluster hostname, not localhost.

  • The Java driver gets TLS trust from the trust store created in Step 7, not from tlsCAFile. Keep tlsCAFile in the URL anyway. It's used by the mongosh native executor (see Step 4).

url=mongodb+srv://your_atlas_cluster/?authMechanism=MONGODB-AWS

Be sure to:

  • Replace your_atlas_cluster with your Atlas cluster hostname. For example, cluster0.abc123.mongodb.net

9

Confirm the connection is successful

Run the liquibase status command against your cluster. For example:

liquibase --search-path=your_changelog_dir status --changelog-file=your_changelog_file

Be sure to:

  • Replace your_changelog_dir with the directory containing your changelog file. For example, C:\Users\your_username\my-project

  • Replace your_changelog_file with the name of your changelog file. For example, changelog.xml

Results

This output confirms that Liquibase successfully authenticated to your cluster using AWS IAM credentials. Each line tells you something specific:

  • Picked up JAVA_TOOL_OPTIONS: The JVM read your trust store configuration. This confirms the setting was picked up, not that the TLS handshake itself succeeded.

  • 1 changeset has not been applied to @mongodb://... : Liquibase connected to the cluster and read your changelog. This is the actual proof that MONGODB-AWS authentication and TLS both succeeded.

  • Liquibase command 'status' was executed successfully: The command completed without errors.

If authentication had failed at any point, you would see an error before reaching this output.

Example of successful output
loading