DMS endpoints for MongoDB should have an authentication mechanism enabled
A DMS endpoint connecting to MongoDB without authentication lets any network-reachable client read and write data during migration, exposing source or target databases to unauthorized access, exfiltration, or corruption. MongoDB historically defaulted to no authentication, so this is a well-known attack vector.
Setting auth_type = "password" in the endpoint's mongodb_settings block requires credentials for the replication connection, limiting exposure even if network controls are misconfigured or overly permissive.
Retrofit consideration
Changing auth_type from "no" to "password" on an active endpoint requires valid credentials in the mongodb_settings block. If the credentials are wrong, the replication task fails immediately. Verify credentials against the MongoDB instance before modifying any running task.
Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_dms_endpoint.
resource "aws_dms_endpoint" "this" {
database_name = "pofix"
endpoint_id = "pofix-abc123"
endpoint_type = "source"
engine_name = "mongodb"
password = "ChangeMe123!"
port = 27017
server_name = "mongo.example.com"
ssl_mode = "none"
username = "admin"
mongodb_settings {
auth_mechanism = "scram-sha-1"
auth_type = "password"
}
}
What this control checks
The aws_dms_endpoint resource with engine_name = "mongodb" must include a mongodb_settings block with auth_type = "password". Setting auth_type = "no" or omitting the mongodb_settings block entirely fails the control. When auth_type is "password", auth_source should identify the authentication database (typically "admin") and auth_mechanism should be "default", "mongodb_cr", "scram_sha_1", or "scram_sha_256". The top-level username and password arguments on the aws_dms_endpoint resource must also be populated. A passing configuration requires both top-level credentials and auth_type = "password" in mongodb_settings.
Common pitfalls
Do not rely on implicit MongoDB auth settings
Omitting
mongodb_settingsentirely for a MongoDB endpoint doesn't mean authentication defaults to on. The behavior is undefined from a security standpoint. Always declare themongodb_settingsblock explicitly withauth_type = "password".auth_mechanism mismatch with MongoDB version
Mismatching
auth_mechanismto your MongoDB version causes connection failures."scram_sha_1"won't work against old deployments that only support MONGODB-CR, and"mongodb_cr"fails on MongoDB 4.0+ where MONGODB-CR was removed. Use"default"to let DMS negotiate when possible, or pin the mechanism to your actual MongoDB version.Credentials stored in plain text in state
Encrypt and restrict access to your Terraform state backend. The
passwordargument onaws_dms_endpointis stored in state as plain text. Reference credentials viaaws_secretsmanager_secret_versiondata sources or sensitive variable declarations rather than hardcoding them in configuration.
Audit evidence
An auditor expects Config rule evaluations showing all DMS MongoDB endpoints as COMPLIANT. Supporting evidence includes the output of aws dms describe-endpoints filtered to MongoDB endpoints, confirming MongoDbSettings.AuthType returns "password" for each. DMS console screenshots showing authentication type set to Password are also acceptable.
CloudTrail events for CreateEndpoint and ModifyEndpoint calls confirm endpoints were not created or modified to allow unauthenticated access.
Framework-specific interpretation
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
Compliance.tf Control:
dms_endpoint_mongo_db_authentication_enabledAWS Config Managed Rule:
DMS_MONGO_DB_AUTHENTICATION_ENABLEDPowerpipe Control:
aws_compliance.control.dms_endpoint_mongo_db_authentication_enabledProwler Check:
dms_endpoint_mongodb_authentication_enabledAWS Security Hub Control:
DMS.11
Last reviewed: 2026-03-09