Redshift Permissions

Qualytics calls Amazon Redshift through the Redshift JDBC driver (PostgreSQL-compatible) in one of two modes: Password (JDBC with a database user and password) or IAM Role (JDBC plus AWS STS AssumeRole, where the driver obtains short-lived database credentials from AWS). The identity behind the connection must hold permissions at two layers: database-level grants inside Redshift, and (for the IAM Role mode only) AWS IAM permissions on the target role.

Which identity carries those permissions depends on the authentication mode:

Database-Level Permissions

These grants live inside Redshift and are required in both authentication modes. With Password, you grant them to the database user. With IAM Role on a provisioned cluster, you grant them to the database user Qualytics requests temporary credentials for: spark, unless you set Database User on the connection. Create it with CREATE USER spark PASSWORD DISABLE; (AWS issues a temporary password for every session) and grant it the privileges below; the session logs in as IAMA:spark and inherits them. On Redshift Serverless the session maps to the role itself, so grant the privileges to the user "IAMR:<role-name>" instead.

Source Datastore (Read-Only)

A read-only user lets Qualytics discover, profile, and scan tables in the schema. It cannot write anywhere.

Example: create a dedicated read-only user. Replace <schema_name> and <password> with your actual values.

-- Create a dedicated read-only user
CREATE USER qualytics_read PASSWORD '<password>';

-- Grant schema access and read permissions
GRANT USAGE ON SCHEMA <schema_name> TO qualytics_read;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema_name> TO qualytics_read;

-- Grant read access to future tables automatically
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema_name>
    GRANT SELECT ON TABLES TO qualytics_read;

The ALTER DEFAULT PRIVILEGES line ensures the user keeps SELECT on tables that are created in the schema after the initial grant. Without it, you would have to re-grant after every new table.

Enrichment Datastore (Read-Write)

When you also use Redshift as an enrichment datastore, the enrichment user needs the source grants above plus write and lifecycle permissions, because Qualytics creates, updates, and replaces the outputs it writes there.

Example: create a dedicated read-write user.

-- Create a dedicated read-write user
CREATE USER qualytics_readwrite PASSWORD '<password>';

-- Grant schema access, table creation, and data manipulation
GRANT USAGE, CREATE ON SCHEMA <schema_name> TO qualytics_readwrite;
GRANT SELECT, INSERT, UPDATE, DELETE
    ON ALL TABLES IN SCHEMA <schema_name>
    TO qualytics_readwrite;

-- Grant full access to future tables automatically
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema_name>
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES
    TO qualytics_readwrite;

AWS IAM Permissions (IAM Role mode only)

These permissions are required only when the connection's authentication type is IAM Role. They are attached to the target role (the role ARN you enter in the connection form), and they let the JDBC driver call AWS to exchange the assumed-role session for short-lived Redshift database credentials.

If your connection uses Password authentication, skip this section. Database-level grants are all you need.

Provisioned Redshift

The target role needs the three AWS actions below.

Example AWS IAM policy. Replace <region>, <account>, <cluster-id>, and <db-name> with your actual values; spark is the user Qualytics connects as unless you set Database User on the connection, in which case use that name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftGetCredentials",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:<region>:<account>:dbuser:<cluster-id>/spark",
        "arn:aws:redshift:<region>:<account>:dbname:<cluster-id>/<db-name>"
      ]
    },
    {
      "Sid": "RedshiftCreateClusterUser",
      "Effect": "Allow",
      "Action": "redshift:CreateClusterUser",
      "Resource": "arn:aws:redshift:<region>:<account>:dbuser:<cluster-id>/spark"
    },
    {
      "Sid": "RedshiftDescribeCluster",
      "Effect": "Allow",
      "Action": "redshift:DescribeClusters",
      "Resource": "arn:aws:redshift:<region>:<account>:cluster:<cluster-id>"
    }
  ]
}

Create the database user before you test the connection and grant it the database-level permissions above. It needs no password of its own; AWS issues a temporary one for every session.

CREATE USER spark PASSWORD DISABLE;

Redshift Serverless

For Redshift Serverless workgroups, the target role needs a single action against the workgroup ARN.

Example AWS IAM policy. Replace <region>, <account>, and <workgroup-id> with your actual values.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftServerlessGetCredentials",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:<region>:<account>:workgroup/<workgroup-id>"
    }
  ]
}

Where to find the cluster endpoint

The Host field in the connection form takes the canonical Redshift endpoint, in one of two formats depending on whether you are connecting to a provisioned cluster or a Serverless workgroup. The same value goes into connection.host when you create the datastore via API.

• Provisioned Redshift: <cluster-id>.<account-id>.<region>.redshift.amazonaws.com
• Redshift Serverless: <workgroup-id>.<account-id>.<region>.redshift-serverless.amazonaws.com

To copy the endpoint from the AWS console:

1. Open the Amazon Redshift console and select your cluster or workgroup.
2. On the cluster (or workgroup) details page, find the General information panel.
3. Copy the Endpoint value, dropping the trailing :<port>/<database> suffix if present. The Host field takes only the hostname; the Port and Database fields are separate.