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
$externaluser 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
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-pluginmongoshmust be 2.4 or later. Older versions fail with a misleadingSignatureDoesNotMatcherror.If
mongoshis not recognized after installing, open a new terminal window to pick up the updated PATH.
winget install Amazon.AWSCLI
winget install MongoDB.ShellAWS 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
mongoshis not recognized after installing, open a new terminal window to pick up the updated PATH.
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_tokenBe sure to:
Replace
your_access_key_id,your_secret_access_key, andyour_session_tokenwith 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_namewith 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-identityOptional: 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_nameBe sure to:
Replace
your_aws_regionwith the AWS region of your cluster. Required when using AssumeRole. For example,us-east-1Replace
your_role_arnwith the ARN of the role to assume. For example,arn:aws:iam::123456789012:role/your_role_nameReplace
your_session_namewith 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.
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.
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.
Be sure to:
Replace
your_instance_idwith your bastion instance ID. For example,i-0123456789abcdef0Replace
your_cluster_endpointwith your DocumentDB cluster endpoint. For example,mydb.cluster-abc123.us-east-1.docdb.amazonaws.comReplace
your_aws_regionwith 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.
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.pemInvoke-WebRequest -Uri https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem -OutFile global-bundle.pemDocumentDB 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:
Then run the following script from the same directory as global-bundle.pem to create the trust store:
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:
Then run the following script from the same directory as global-bundle.pem to create the trust store:
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"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=falseBe sure to:
Replace
your_cluster_endpointwith your DocumentDB cluster endpoint. For example,mydb.cluster-abc123.us-east-1.docdb.amazonaws.comReplace
your_ca_bundle_pathwith the path toglobal-bundle.pemfrom Step 6. For example,/path/to/global-bundle.pem
Note:
retryWrites=falseis 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. KeeptlsCAFilein 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=falseBe sure to:
Replace
your_ca_bundle_pathwith the path toglobal-bundle.pemfrom Step 6. For example,/path/to/global-bundle.pem
Note:
retryWrites=falseis required for DocumentDB. DocumentDB does not support retryable writes, and omitting this parameter will cause connection errors.tlsAllowInvalidHostnames=trueanddirectConnection=trueare required when connecting through the SSM tunnel because the TLS certificate is issued for the cluster hostname, notlocalhost.The Java driver gets TLS trust from the trust store created in Step 7, not from
tlsCAFile. KeeptlsCAFilein the URL anyway. It's used by the mongosh native executor (see Step 4).
url=mongodb+srv://your_atlas_cluster/?authMechanism=MONGODB-AWSBe sure to:
Replace
your_atlas_clusterwith your Atlas cluster hostname. For example,cluster0.abc123.mongodb.net
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_fileBe sure to:
Replace
your_changelog_dirwith the directory containing your changelog file. For example,C:\Users\your_username\my-projectReplace
your_changelog_filewith 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.