Skip to content

Redshift Authentication

Every query Qualytics runs against your Redshift cluster carries a database identity, and Redshift uses that identity to decide which schemas, tables, and columns the connection can see. The privileges attached to that identity also gate metadata discovery, profiling, and scans.

The Authentication section of the connection form is where you choose which identity Qualytics uses. Two options are available.

Password

With Password authentication, you supply a Redshift database User and Password directly in the connection form. Qualytics passes both to the Redshift JDBC driver, which opens a TLS-encrypted session against the cluster and signs in as that user. The database user behind the credentials needs the privileges listed in Redshift Permissions.

This is the simplest setup. It works well when:

  • You are testing Redshift connectivity or running it in a development environment.
  • Your security policy allows storing static database credentials.
  • You do not need cross-account access.

The trade-off is that the credentials are static. You are responsible for changing them when they expire or get leaked, and you must update the new value in both Redshift and Qualytics each time.

Generating a Redshift database user

Run the following SQL as a Redshift superuser (or as any user with CREATE USER privilege and ownership of the target schema):

  1. Create the database user. 
    CREATE USER qualytics_reader PASSWORD '<strong-password>';
  2. Grant access to the schema you want Qualytics to monitor. 
    GRANT USAGE ON SCHEMA <schema_name> TO qualytics_reader;
  3. Grant read access on every existing table in that schema. 
    GRANT SELECT ON ALL TABLES IN SCHEMA <schema_name> TO qualytics_reader;
  4. Grant read access on tables created in that schema in the future, so you do not have to re-grant after each new table. 
    ALTER DEFAULT PRIVILEGES IN SCHEMA <schema_name>
GRANT SELECT ON TABLES TO qualytics_reader;

Use the resulting username and password in the connection form's User and Password fields.

Tip

For enrichment connections, add the additional grants from Enrichment Datastore before connecting.

IAM Role

AWS-only

IAM Role authentication is offered only on AWS-hosted and local Qualytics deployments. On Azure and GCP deployments, only Password authentication is available.

With IAM Role authentication, you do not share any static database credentials with Qualytics. Instead, you create an IAM role in your AWS account and let Qualytics assume it. When Qualytics needs to query Redshift, the dataplane asks AWS STS for temporary credentials for that role, and the Redshift JDBC driver then uses those credentials to fetch short-lived database credentials from redshift:GetClusterCredentials (for provisioned clusters) or redshift-serverless:GetCredentials (for Redshift Serverless). AWS issues fresh credentials on demand and Qualytics requests new ones automatically before the current ones expire, so you do not manage the rotation.

You enter the role's ARN in the connection form's Role ARN field and, if your trust policy requires it, an External ID. The Host field stays as the cluster or workgroup endpoint. Qualytics rewrites the JDBC URL to the IAM variant internally.

This is the recommended option for production. It works well when:

  • Your security policy disallows storing static database credentials.
  • Your cluster lives in a different AWS account from Qualytics.
  • You want every connection logged and auditable in AWS CloudTrail.

How the assume-role flow works

When Qualytics connects to Redshift using IAM Role authentication:

  1. Qualytics's AWS identity (the dataplane's base role) calls sts:AssumeRole against the role ARN you entered in the connection form.
  2. AWS checks the role's trust policy to confirm the calling identity is allowed to assume the role. If you supplied an External ID, AWS also checks that it matches the value in the trust policy.
  3. If the checks pass, AWS STS returns temporary AWS credentials valid for the role's session duration.
  4. The Redshift JDBC driver uses those AWS credentials to call Redshift internally and obtain short-lived database credentials, then opens the SQL session against your cluster (or Serverless workgroup) using them.
  5. Qualytics caches the AWS credentials until shortly before they expire (a refresh threshold of 300 seconds is used by default) and then requests a fresh set automatically.

The base role (the dataplane identity that calls sts:AssumeRole) and the target role (the role you enter in the connection form) are described in detail in IAM Role Authentication, including who provisions each one for Managed vs Self-Hosted deployments.

About the External ID

The External ID is an extra security check on top of the trust policy. When you require an External ID in your role's trust policy, only AssumeRole calls that pass the matching value succeed. Even if Qualytics's own identity were ever misused, an attacker still could not assume your role without also knowing your External ID.

In Qualytics, the External ID is optional. Supply it only if your trust policy requires one. AWS strongly recommends using an External ID whenever you grant a third party (such as Qualytics) the ability to assume a role in your account.