DataMasque Portal

Database connections

Connections define the databases that are available for DataMasque to run masking jobs against.

This page covers the parts of a connection that are the same for every database. The details that differ by database - the masking process, limitations, supported data types, unsupported key columns, connection parameters, encrypted connections, and required privileges - are on the page for each database.

Supported data sources

DataMasque supports Amazon DocumentDB, Amazon DynamoDB, Amazon Redshift, Azure Cosmos DB, Databricks Lakebase, Databricks SQL Warehouse, IBM Db2 for i, IBM Db2 LUW, IBM Informix, MariaDB, Microsoft SQL Server, MongoDB, MySQL, Oracle, PostgreSQL, SAP HANA, and Snowflake databases.

Databases Supported versions
Amazon Aurora -
Amazon DocumentDB -
Amazon DynamoDB -
Amazon RDS -
Amazon Redshift -
Azure Cosmos DB -
Databricks Lakebase -
Databricks SQL Warehouse -
IBM Db2 for i 7.4, 7.5
IBM Db2 LUW 11.5
IBM Informix 15
MariaDB 10.11, 11, 12
Microsoft SQL Server 2012, 2014, 2016, 2017, 2019, 2022, 2025
MongoDB 5, 6, 7, 8
MySQL 5.7, 8.0, 8.4
Oracle 11gR2, 12gR1, 12gR2, 18c, 19c, 21c, 23ai, 26ai
PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17, 18
SAP HANA 2.0
Snowflake -

Microsoft SQL Server (Linked Server) was removed in DataMasque 3.26.18. Existing connections of that type are archived when you upgrade, and can no longer be used for masking runs. Mask the target database through a connection of its own type instead.

Each database has its own page. The page holds the masking process, limitations, supported data types, unsupported key columns, connection parameters, encrypted connections, and required privileges for that database.

Database Page
Amazon DocumentDB Amazon DocumentDB connections
Amazon DynamoDB Amazon DynamoDB connections
Amazon RDS and Amazon Aurora Amazon RDS connections
Amazon Redshift Amazon Redshift connections
Azure Cosmos DB Azure Cosmos DB connections
Databricks Lakebase Databricks Lakebase connections
Databricks SQL Warehouse Databricks SQL Warehouse connections
IBM Db2 for i IBM Db2 for i connections
IBM Db2 LUW IBM Db2 LUW connections
IBM Informix IBM Informix connections
MariaDB MariaDB connections
Microsoft SQL Server Microsoft SQL Server connections
MongoDB MongoDB connections
MySQL MySQL connections
Oracle Oracle connections
PostgreSQL PostgreSQL connections
SAP HANA SAP HANA connections
Snowflake Snowflake connections

Add a new connection

To add a connection, click the  Add button  button from the Connections panel of the Database Masking Dashboard.

Use the form to configure the connection parameters for your database. You may validate that the connection parameters are correct using the Test Connection button. This will attempt a database connection using the provided parameters. If the connection fails, an error will be shown with the failure details. The Test button is also available from the dashboard.

You can also use utility buttons inside the dropdown next to the Save and exit button. These buttons combine multiple actions in a single click:

  • Test, Save, and Exit: This option allows you to test the connection, save it, and exit the page in one step.
  • Save & Go To Ruleset Generator: This option allows you to test the connection, save it, and then navigate to the Ruleset Generator page with the newly created connection.

Add connection

Connection parameters

Standard parameters
Connection name A unique name for the connection across the DataMasque instance. May only contain alphanumeric characters and underscores.
Database type The type/engine of the database. Available options: Amazon DocumentDB, Amazon DynamoDB, Amazon Redshift, Azure Cosmos DB, Databricks Lakebase, Databricks SQL Warehouse, IBM Db2 for i, IBM Db2 LUW, IBM Informix, MariaDB, Microsoft SQL Server, MongoDB, MySQL, Oracle, PostgreSQL, SAP HANA, Snowflake.
Username The username DataMasque will use to authenticate with the database server.
Password The password DataMasque will use to authenticate with the database server.
Database / SID The database name (or SID for Oracle databases).
Hostname / IP The hostname or IP address of the database server.
Port The port of the database server.

Note: For AWS Aurora databases, use cluster endpoint for the Database / SID Field.

Cross account resource tagging parameters

Databases hosted on AWS can carry an IAM role for DataMasque to assume when it tags the resource after a run. This applies to Amazon Redshift, IBM Db2 LUW, MariaDB, Microsoft SQL Server, MySQL, Oracle and PostgreSQL connections, and only takes effect when the Hostname / IP is an Amazon RDS instance endpoint, an Amazon Aurora cluster endpoint, or a provisioned Amazon Redshift cluster endpoint. On a self-managed database, or on an endpoint type that cannot be tagged (Aurora custom, global and Limitless endpoints, RDS Proxy, and Redshift Serverless), the field is accepted but unused.

Ticking Cross account access reveals the following parameter:
IAM Role ARN The IAM Role ARN with permission to tag the resource, in the account that hosts it.

The role is only used to tag the resource. DataMasque still connects to the database over its own port using the username and password on the connection, so this field is only needed when the database is in a different AWS account from DataMasque.

An Amazon Redshift connection therefore involves three separate identities, and it is worth knowing which is which when a permission error appears:
Checking the S3 bucket DataMasque's own instance role. Neither field on the connection changes this.
UNLOAD and COPY through S3 The Amazon Redshift IAM Role, used by the cluster itself.
Tagging the cluster after a run The IAM Role ARN, assumed by DataMasque.

Because the bucket check runs as DataMasque's own instance role, a staging bucket in another AWS account must grant access to that role directly. Neither role field on the connection affects it.

Leave Cross account access unticked when the database is in the same account as DataMasque: tagging then uses DataMasque's own instance role.

For more information please refer to the AWS resource tagging documentation and the cross-account documentation.

Database specific parameters and advanced settings

Some databases need extra connection parameters or have extra advanced settings. See the Connection parameters section on the page for the database.

Storing credentials in AWS Secrets Manager

Introduction to AWS Secrets Manager

DataMasque supports retrieving database connection credentials from AWS Secrets Manager (ASM).

ASM secrets are identified by their Amazon Resource Name (ARN), which has the following format:

arn:aws:secretsmanager:<Region>:<AccountId>:secret:<SecretName>-<6RandomCharacters>

For example:

arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc123

If an ASM ARN is input as the username or password when configuring a database connection, then DataMasque will attempt to retrieve the secret from ASM to use as that credential. This applies to the connection form in the UI and connections created using the API.

How secrets are stored in AWS Secrets Manager

Secrets in ASM can be stored in different ways:

  • Key-Value Pairs: Commonly used for database connections, especially for Amazon RDS databases. Multiple credentials (e.g. username and password) are stored within the same secret.
  • Plain Text: The entire secret is a single credential, such as a password.

It is important to know how your secret is stored, as DataMasque requires additional information to retrieve data from a key-value store.

IAM Permissions to read an AWS Secret

To read a secret from AWS Secrets Manager, an EC2 instance must have the correct IAM role. The role's policy must include the secretsmanager:GetSecretValue permission for the specified ASM ARN.

Here is an example policy allowing read access to a specific secret:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSecretRead",
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc1236"
        }
    ]
}

Replace the example ARN with the ARN of the secret you want to access.

Specifying the secret ARN in DataMasque

The secret ARN may be specified in the Add Connection dialogue, or as part of the Connection object in an API request.

The following screenshot shows an example of an ARN being specified as the Username and Password in the database connection form. Note that the password ARN is not visible as the Password field obscures the entered data.

ASM ARN in Database Connection Form

Retrieving credentials from a Key-Value Pair secret

This screenshot shows a secret in AWS Secrets Manager stored as key-value pairs.

ASM Key Value Pairs

Internally the secret is stored as a JSON document:

{
  "username":"postgres",
  "password":"securepassword",
  "engine":"postgres",
  "host":"postgres-rds.a1iiijjjzzz00.us-east-1.rds.amazonaws.com",
  "port":"5432",
  "dbname":"postgres"
}

DataMasque uses a JSON path to retrieve the particular key that stores the credential. Therefore, the JSON path to the credential should be appended to the ARN. For example, to retrieve the username, append [username] to the ARN.

Example for the Username field:

arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc123[username]

Similarly, to fetch the password, append [password] to the ARN.

Example for the Password field:

arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc123[password]

When managing connections using the API, include the ARN(s) in the connection object when making POST or PUT requests to /api/connections/.

Example API body:

{
   "version": "1.0",
   "name": "PGConnection",
   "user": "arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc123[username]",
   "db_type": "postgresql",
   "password": "arn:aws:secretsmanager:us-east-1:012345678901:secret:my-db-secret-abc123[password]",
   "mask_type": "database",
   # … other fields omitted for brevity
 }

Retrieving credentials from a Plain Text secret

This screenshot shows a secret stored in ASM as plain text.

ASM Plain Text Secret

In this case, the secret itself is the password, so use the entire ARN as the credential.

Example for the Password field:

arn:aws:secretsmanager:us-east-1:012345678901:secret:simple-password-def456

For API connections, include the ARN(s) in the connection object.

Example API body:

{
   "version": "1.0",
   "name": "PGConnection",
   "user": "postgres",
   "db_type": "postgresql",
   "password": "arn:aws:secretsmanager:us-east-1:012345678901:secret:simple-password-def456",
   "mask_type": "database",
   # … other fields omitted for brevity
 }

View and edit connection

To edit a connection, click the edit (Edit button) button for the connection you wish to edit in the Connections panel of the Database masking dashboard.

A full list of connection parameters can be found under Connection Parameters.

Connections panel

Under a license type with a connection limit (Foundation), a padlock icon appears next to a connection in the Connections panel once it has counted towards that limit, and its protected fields (host, port, database, user, and similar) are greyed out on the edit form for 90 days. Password and IAM-role changes are allowed throughout. See Target freeze for the full list of fields this affects and when the restriction lifts.

This padlock icon is distinct from the pencil-with-a-slash icon shown for a read-only connection: the padlock names a temporary license restriction with an unlock date, while the pencil-with-a-slash names a connection that is always read-only. A connection can show both icons at once if both apply. An uncapped license type never shows the padlock; the read-only icon is unaffected by license type.

Delete connection

To delete a connection, open the connection for editing (see View and edit connection) and click the Delete button. You will be prompted for confirmation before the connection is deleted. A connection can also be deleted from the dashboard by clicking the trashcan icon.Delete button

The delete button is disabled during the same 90-day period described above, unless the account is over its connection limit — in which case deletion stays available so the count can be brought back under the limit. See Target freeze.

Connection actions

Clone a connection

To clone a connection, click on the  Clone button  button for the connection you wish to clone in the Connections panel of the Database Masking Dashboard or File Masking Dashboard.

Read-only database connections

Some databases can be masked through a read-only connection. See Read-only database connections.

Connection limits

Some license types set a maximum number of connections you can use, shown as Connections in use on the My Account page. See Connection limits on the Licensing page for the full detail.

The masking process

For relational databases listed below, DataMasque masks in place, that is, it directly replaces data in the target database with masked data.

  • Amazon DocumentDB
  • Azure Cosmos DB
  • Databricks Lakebase
  • Databricks SQL Warehouse
  • IBM Db2 for i
  • IBM Db2 LUW
  • IBM Informix
  • MariaDB
  • Microsoft SQL Server
  • MongoDB
  • MySQL
  • Oracle
  • PostgreSQL
  • SAP HANA

This diagram shows the high level reference deployment process.

DataMasque reference deployment

DataMasque is expected to run in the secure production zone, and mask a clone of production data. Once masking is complete, the masked clone can itself be cloned into non-production environments.

For some databases, the process is different. The Masking process section on the page for the database describes the difference.

Required privileges

DataMasque connections require database privileges to perform masking tasks. The privileges differ by database.

Note: Run SQL tasks may require additional privileges, make sure you have granted the right privileges for the connection user to run the scripts.

See the Required privileges section on the page for the database.

Encrypted connections

DataMasque supports encrypted connections to most databases. The settings differ by database. See the Encrypted connections section on the page for the database.

Database limitations and unsupported features

Not all databases that DataMasque can connect to support all DataMasque's features. The Limitations section on the page for the database lists the limitations.

Unsupported key columns by database

Key column type checks are necessary to ensure data can be correctly masked, to avoid violating database constraints, and to maintain data integrity.

Unsupported key column types vary by database, and not all database connections have such restrictions (e.g. Oracle). The Unsupported key columns section on the page for the database lists the restricted types.