Connect Amazon Redshift

climpt reaches Redshift through the Data API, which speaks HTTPS to the AWS control plane. That means your cluster or workgroup can stay entirely private — no public endpoint, no security-group rule, no IP allowlist. Authentication is IAM only; no database password is ever stored.

Credentials

AWS region

For example us-east-1. Shown in the Redshift console.

Cluster type

Serverless or Provisioned — whichever you deployed.

Workgroup / cluster name

From Redshift → Serverless, or Redshift → Clusters.

Database

For example dev.

Database user

Provisioned clusters only. Serverless workgroups ignore this field.

AWS access key ID

IAM → Users → Security credentials.

AWS secret access key

Created alongside the access key.

IAM permissions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftDataAPIQuery",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftDiscovery",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters",
        "redshift-serverless:GetWorkgroup",
        "redshift-serverless:GetCredentials"
      ],
      "Resource": "*"
    }
  ]
}

Provisioned clusters only

Serverless workgroups are covered by redshift-serverless:GetCredentials above. A provisioned cluster needs one more statement so the Data API can mint a temporary database password from the IAM principal. Replace REGION, ACCOUNT, CLUSTER and DATABASE with your values.

{
  "Sid": "RedshiftIAMAuth",
  "Effect": "Allow",
  "Action": [
    "redshift:GetClusterCredentialsWithIAM",
    "redshift:GetClusterCredentials"
  ],
  "Resource": [
    "arn:aws:redshift:REGION:ACCOUNT:dbuser:CLUSTER/${aws:username}",
    "arn:aws:redshift:REGION:ACCOUNT:dbname:CLUSTER/DATABASE"
  ]
}

Both actions are included because which one applies varies across regions and SDK versions.

Database permissions

IAM only lets the Data API reach Redshift. The database user that the IAM principal maps to still needs SELECT, or information_schema.tables comes back empty — by far the most common cause of “the scan finished but found no tables”.

-- 1. Find the DB user the IAM principal maps to (e.g. IAM:my-user)
SELECT usename FROM pg_user WHERE usename ILIKE 'IAM%';

-- 2. Grant read-only access per schema.
--    Quote the name — it contains a colon.
GRANT USAGE ON SCHEMA public TO "IAM:my-user";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "IAM:my-user";

-- 3. Cover tables added later
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO "IAM:my-user";

Setup

1. Create or locate your cluster or workgroup in the Redshift console.
2. Go to IAM → Policies → Create policy, switch to the JSON tab and paste the custom policy above.
3. Name it something recognisable, for example RedshiftReadOnlyDataAPI.
4. Go to IAM → Users and create or pick a user for analytics.
5. Use Add permissions → Attach policies directly and attach the policy.
6. Generate access keys for that user and store them securely.
7. Run the database grants above as an admin.
8. Fill in the connection form and test.

Worth knowing

• Redshift uses PostgreSQL syntax, not MySQL, and double quotes for identifiers: "my-table".
• Serverless needs a workgroup name; provisioned needs a cluster identifier.
• The Data API encrypts everything in transit.
• Enable CloudTrail on Data API calls if you want an audit trail.
• Rotate the access keys roughly every 90 days.