Connect to Amazon Redshift

Before you start

You'll need three things:

• A Redshift data warehouse the Data API supports. Any Amazon Redshift Serverless workgroup, or a provisioned cluster on RA3, DC2, or RG node types. Older DS2 and DC1 clusters don't support the Data API.
• Someone who can create an IAM policy and IAM user in the AWS account that owns the cluster or workgroup. Golden's IAM user must live in that same account.
• Someone who can grant privileges in the Redshift database — a superuser or the owner of the schemas you want to analyze.

Set aside about 15 minutes. Steps 1–4 happen in the AWS console, Step 5 in Golden, and Step 6 back in Redshift.

Two layers of access

If you've connected other tools to Redshift with a hostname, user name, and password, expect that single login to split in two here:

The AWS layer is the same for everyone. The database layer has three variants, and the Database sign-in setting in Golden is where you pick one.

Choose how Golden signs in to the database

The Database sign-in setting decides which database user your queries run as — and therefore which tables Golden can see. Pick one now; it changes what you do in Steps 2, 4, and 6.

Step 1 — Find your endpoint

Open the Amazon Redshift console.

Provisioned cluster: choose Clusters in the left navigation, click your cluster, and copy the Endpoint from the General information panel. It looks like this:

my-cluster.abc123xyz789.us-east-1.redshift.amazonaws.com:5439/dev

Serverless workgroup: choose Redshift Serverless, then Workgroup configuration, click your workgroup, and copy the Endpoint from General information. It looks like this:

default.123456789012.us-east-1.redshift-serverless.amazonaws.com:5439/dev

You'll paste the whole thing into Golden later — the trailing :5439/dev is fine, Golden trims it.

While you're here, note four values you'll need for the policy in Step 2:

• Region — the label just before redshift or redshift-serverless in the hostname (us-east-1 above).
• Cluster identifier or workgroup name — the first label of the hostname (my-cluster or default above).
• Database name — the part after the slash (dev is Redshift's default).
• AWS account ID — the 12-digit number in the account menu at the top right of the console.

Step 2 — Create the permissions policy

Rather than attaching AWS's managed AmazonRedshiftDataFullAccess policy, create a small custom one. It is narrower, and for two of the three sign-in methods it is the only one that works (see the note at the end of this step).

1. 1Open the IAM console, choose Policies, then Create policy.
2. 2Switch to the JSON tab, delete the placeholder, and paste the policy below.
3. 3Keep the first two statements as-is. Of the four sign-in statements that follow, keep only the one for your method and delete the other three.
4. 4Replace the UPPERCASE placeholders using the table under the policy.
5. 5Click Next, name the policy GoldenAnalyticsRedshiftAccess, and click Create policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GoldenRedshiftDataApi",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:BatchExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement",
        "redshift-data:ListSchemas",
        "redshift-data:ListTables"
      ],
      "Resource": "*"
    },
    {
      "Sid": "GoldenServiceLinkedRole",
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "arn:aws:iam::ACCOUNT_ID:role/aws-service-role/redshift-data.amazonaws.com/AWSServiceRoleForRedshift",
      "Condition": {
        "StringLike": { "iam:AWSServiceName": "redshift-data.amazonaws.com" }
      }
    },

    {
      "Sid": "SignInIamIdentityProvisionedCluster",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentialsWithIAM",
      "Resource": "arn:aws:redshift:REGION:ACCOUNT_ID:dbname:CLUSTER_ID/*"
    },
    {
      "Sid": "SignInIamIdentityServerlessWorkgroup",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:REGION:ACCOUNT_ID:workgroup/*"
    },
    {
      "Sid": "SignInDatabaseUserProvisionedCluster",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:REGION:ACCOUNT_ID:dbuser:CLUSTER_ID/DB_USER",
        "arn:aws:redshift:REGION:ACCOUNT_ID:dbname:CLUSTER_ID/*"
      ]
    },
    {
      "Sid": "SignInSecretsManager",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:golden-analytics/redshift-*"
    }
  ]
}

The policy doesn't name a database. A connection in Golden targets exactly one database (its Database field), and this one policy covers every connection you make to the cluster or workgroup.

Three optional tightenings: for a provisioned cluster, replace the asterisk in dbname:CLUSTER_ID/* with a single database name to limit the key to that database; for Serverless, replace the asterisk in workgroup/* by pasting the workgroup's full ARN from its configuration page; for Secrets Manager, the resource already matches only a secret named golden-analytics/redshift, which is the name you'll give it in Step 4.

Step 3 — Create an IAM user for Golden and an access key

1. 1In the IAM console choose Users, then Create user.
2. 2For User name enter golden-analytics. Leave Provide user access to the AWS Management Console unchecked and click Next.
3. 3Under Permissions options choose Attach policies directly, search for GoldenAnalyticsRedshiftAccess, tick it, click Next, then Create user.
4. 4Open the new user, go to the Security credentials tab, scroll to Access keys, and click Create access key.
5. 5For the use case choose Third-party service. AWS will suggest alternatives; tick the confirmation box, click Next, then Create access key.
6. 6Copy both the Access key and the Secret access key, or click Download .csv file. The secret is shown only once — if you lose it, delete the key and create a new one.

Step 4 — Prepare the database sign-in

Do only the part for the method you chose.

IAM identity

Nothing to do yet. Redshift creates the database user IAM:golden-analytics automatically the first time Golden connects (Step 5). You'll grant it read access in Step 6.

Database user (provisioned clusters only)

Sign in to the database — with query editor v2 in the Redshift console, or any SQL client — as a superuser or schema owner. Either reuse an existing read-only user, or create one. PASSWORD DISABLE means the user can only be reached through AWS temporary credentials, never with a password:

CREATE USER golden_reader PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO golden_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO golden_reader;

Repeat the two GRANT lines for every schema you want to analyze in Golden, connected to the database that holds each schema. The user itself is cluster-wide, so create it only once. Its name must match the DB_USER you put in the policy in Step 2.

Secrets Manager secret

First create a database user with a password and grant it read access (in query editor v2 or any SQL client, as a superuser or schema owner):

CREATE USER golden_reader PASSWORD 'Choose-a-strong-password-1';
GRANT USAGE ON SCHEMA public TO golden_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO golden_reader;

Repeat the two GRANT lines for every schema you want to analyze, connected to the database that holds each schema (the user itself is cluster-wide). Then store those credentials in Secrets Manager:

1. 1Open the AWS Secrets Manager console and click Store a new secret.
2. 2Provisioned cluster: choose Credentials for Amazon Redshift data warehouse, enter the User name and Password, and select your cluster. Serverless workgroup: choose Other type of secret and add two key/value rows — key username with the user name, and key password with the password.
3. 3Click Next. For Secret name enter golden-analytics/redshift (this is the name the policy in Step 2 matches). Under Tags, add a tag with the key RedshiftDataFullAccess and any value.
4. 4Click Next past the rotation page (leave automatic rotation off), then Store.
5. 5Open the secret and copy its Secret ARN — you'll paste it into Golden in Step 5.

Step 5 — Create the connection in Golden

1. 1On the Golden home page click Create Connection (inside a Space, use Create, then Saved connection). In the Add a Connection panel choose Amazon Redshift.
2. 2Fill in the form:

Then click Test Connection. Golden runs a one-line query (SELECT 1) through the Data API. When the button reads Connected, your AWS setup is correct.

Finally, click Save Connection.

Step 6 — Grant read access (IAM identity method)

Skip this step if you chose Database user or Secrets Manager secret — you granted access in Step 4.

With IAM identity, the Test Connection in Step 5 made Redshift create the database user IAM:golden-analytics. It starts with no privileges beyond Redshift's PUBLIC defaults, so until you grant access Golden can connect but will see "permission denied" as soon as it reads a table.

As a superuser or schema owner, run the following. The double quotes are required because of the colon in the user name:

GRANT USAGE ON SCHEMA public TO "IAM:golden-analytics";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "IAM:golden-analytics";

Repeat for each schema you want available in Golden, connected to the database that holds it. The user is cluster-wide, so other databases need only the grants, not a new user. To have tables you create later picked up automatically, also run:

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO "IAM:golden-analytics";

Then, back in Golden, open the connection and browse its tables to confirm they load.

Troubleshooting

When AWS rejects a request, Golden shows the AWS error code and message, so the left column is what you'll actually see.

Good to know

• Queries run live. Golden doesn't copy your data. Every chart, filter, and AI question compiles to SQL that runs on your cluster or workgroup at that moment, so Redshift compute (or Serverless RPU-hours) is used as people work.
• Limits. Golden waits about two minutes for an interactive query, and the Data API returns at most 500 MB per result. Golden aggregates in the warehouse, so real dashboards stay far below both.
• What AWS logs. Every request Golden makes appears in CloudTrail as a redshift-data call by the golden-analytics user, and every query appears in Redshift's system tables under the database user from your sign-in method.
• Rotating the key. Create a second access key for golden-analytics in IAM, edit the connection in Golden and paste the new pair, click Test Connection, then deactivate and delete the old key. Two active keys per user is what makes this a no-downtime swap.
• Revoking access. Deactivate the access key (or delete the user) in IAM and Golden loses access on its next query. Removing the database grants works too, but the key is faster.
• Same account only. Golden signs requests with the user's own key and doesn't assume roles, so the IAM user must live in the AWS account that owns the cluster or workgroup.
• Private clusters are fine. The Data API is an AWS endpoint, so your cluster's "Publicly accessible" setting and its security groups don't affect Golden.
• Customer-managed KMS keys. If the cluster or workgroup is encrypted with your own KMS key, the Data API uses that same key for query text and results and creates a KMS grant on the first query. The key policy must allow kms:CreateGrant via redshift.amazonaws.com; the default AWS-owned key needs nothing.

AWS documentation referenced

• Using the Amazon Redshift Data API
• Configuring IAM permissions for the Data API
• Storing database credentials in AWS Secrets Manager
• Connecting to Amazon Redshift Serverless
• Creating temporary IAM credentials
• Manage access keys for IAM users
• AmazonRedshiftDataFullAccess managed policy
• Using AWS KMS with the Amazon Redshift Data API