Amazon Redshift

1. AWS-level authentication — how 4MINDS discovers which Redshift clusters and Serverless workgroups exist in your account. Uses IAM Role Federation (recommended) or Amazon Cognito, both shared with the rest of 4MINDS’s AWS integrations.
2. Database-level authentication — uses temporary Redshift credentials minted from the same AWS credentials used for discovery. Provisioned clusters use redshift:GetClusterCredentials; Serverless workgroups use redshift-serverless:GetCredentials. No long-lived database password is stored.

​

Provisioned vs. Serverless

​

Redshift IAM Permissions Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftProvisionedDiscovery",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftProvisionedCredentials",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:*:*:dbuser:*/*",
        "arn:aws:redshift:*:*:dbname:*/*"
      ]
    },
    {
      "Sid": "RedshiftServerlessDiscovery",
      "Effect": "Allow",
      "Action": [
        "redshift-serverless:ListWorkgroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftServerlessCredentials",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "*"
    }
  ]
}

Note: GetClusterCredentials is authorized against both the dbuser: and dbname: resource ARNs. The wildcards above allow all clusters, DB users, and databases. To restrict, narrow the ARNs (e.g., arn:aws:redshift:us-east-1:123456789012:dbuser:my-cluster/fourminds_iam_user).

​

Least-Privilege: Restricting to Specific Resources

{
  "Effect": "Allow",
  "Action": "redshift:GetClusterCredentials",
  "Resource": [
    "arn:aws:redshift:us-east-1:123456789012:dbuser:prod-analytics/fourminds_iam_user",
    "arn:aws:redshift:us-east-1:123456789012:dbname:prod-analytics/dev"
  ]
},
{
  "Effect": "Allow",
  "Action": "redshift-serverless:GetCredentials",
  "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:workgroup/*"
}

​

Database Access & Grants

​

Provisioned clusters — the DB user

-- run in the target database on your Redshift cluster
CREATE USER fourminds_iam_user PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO fourminds_iam_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO fourminds_iam_user;
-- so future tables are readable too
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO fourminds_iam_user;

​

Serverless workgroups — IAM-derived user

-- <role-name> is the IAM role 4MINDS assumes (Role Federation) or the
-- Cognito authenticated role. Redshift prefixes assumed roles with "IAMR:".
CREATE USER "IAMR:4MINDS-integration-role" PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO "IAMR:4MINDS-integration-role";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "IAMR:4MINDS-integration-role";
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO "IAMR:4MINDS-integration-role";

Tip: If you’re unsure of the exact derived username, run a browse in 4MINDS and check the error message — a permission denied failure will name the DB user Redshift resolved, which you can then GRANT to.

Note: For Serverless, GetCredentials auto-creates the IAMR:<role> database user on first use, so the explicit CREATE USER above is optional — granting SELECT to PUBLIC (or to the resolved user after a first browse) is sufficient. Pre-creating the user is only needed if you want to grant privileges before the first connection.

​

Connection Method 1: IAM Role Federation (Recommended)

1. Complete the one-time AWS setup in AWS Integrations → IAM Role Federation (OIDC provider + IAM role with trust policy).
2. Attach the Redshift IAM policy above to the role (Role Federation and Cognito can share the same role — just attach both service policies to it if you use multiple AWS integrations).
3. In 4MINDS, open Integrations → Amazon Redshift → click Configure (or Settings if already connected).
4. Keep the IAM Role tab selected.
5. Paste your IAM Role ARN (e.g., arn:aws:iam::123456789012:role/4MINDS-integration-role).
6. Leave the External ID field blank — it is not supported for IAM Role Federation (see AWS Integrations → Verify the Trust Policy).
7. Enter your AWS Region (e.g., us-east-1) — this must match the region of the Redshift resources you want to browse.
8. (Provisioned only) Enter a Database user — see Database User. Leave blank to use the default fourminds_iam_user.
9. Click Test Connection — success shows “Connection successful. Found N Redshift cluster(s).”
10. Click Save Credentials.

​

Connection Method 2: Amazon Cognito

1. Complete the one-time Cognito setup in AWS Integrations → Amazon Cognito (User Pool, App Client, Identity Pool, authenticated role).
2. Attach the Redshift IAM policy above to the Cognito authenticated role.
3. In 4MINDS, open Integrations → Amazon Redshift → click Configure.
4. Switch to the Cognito tab.
5. Fill in User Pool ID, App Client ID, App Client Secret (if configured), Identity Pool ID, Username, and Password.
6. Enter your AWS Region.
7. (Provisioned only) Enter a Database user if you’re not using the default.
8. Click Test Connection, then Save Credentials.

​

Database User

• Defaults to fourminds_iam_user if left blank.
• The user must already exist in the cluster with SELECT on the tables you want to import (see Database Access & Grants).
• The value is stored once with your connection metadata and reused for every browse and import — you don’t re-enter it per request.
• Ignored for Serverless — Serverless derives the user from the IAM identity, so this field has no effect on workgroups.

​

4MINDS Fields

​

Importing Data from Redshift

​

Step 1 — Pick a Cluster or Workgroup

If the Serverless permissions are missing, workgroups are simply omitted — provisioned clusters still list normally.

​

Step 2 — Browse Databases

​

Step 3 — Select Tables

• Schema-qualified name (e.g., public.customers)
• Column count
• On-disk size (when available)

​

During Import

• Up to 50,000 rows per table (hard cap — larger tables are truncated and flagged).
• Binary columns (BYTEA, VARBINARY, BINARY) are dropped from the export rather than base64-encoded.
• Complex types (arrays, structured values) are serialized with json.dumps into a single cell.
• Timeout is 120 seconds per table.

​

Dataset Sync

​

Overview

​

How to Set Up Sync

1. Import one or more Redshift tables into a 4MINDS dataset (using the import wizard above).
2. On the dataset, toggle Dataset Sync on.
3. Select a sync frequency (see table below).
4. From that point on, 4MINDS re-exports each configured table at the chosen interval.

​

Sync Frequencies

Because every Redshift sync is a full-table re-export, prefer less frequent intervals for large tables to control export cost and RPU/credit usage. Daily or weekly is a good default for warehouse tables.

​

How It Works Internally

​

Authentication for Automated Sync

1. The stored auth method (IAM Role Federation or Cognito) is resolved into fresh temporary AWS credentials for the run (STS AssumeRoleWithWebIdentity, or Cognito GetCredentialsForIdentity).
2. Those credentials mint a fresh temporary Redshift credential per table (GetClusterCredentials / GetCredentials).

​

Networking Requirements

• Allow the 4MINDS backend egress IP on the Redshift port (default 5439):

  Environment	Backend hostname	Egress IP to allowlist
  Production	api.4minds.ai	20.7.240.218/32

  Add it as an inbound rule on the security group attached to your cluster or Serverless workgroup. AWS CLI:
  aws ec2 authorize-security-group-ingress \
    --group-id <your-redshift-security-group-id> \
    --protocol tcp --port 5439 \
    --cidr 20.7.240.218/32
  
  Or in the console: EC2 → Security Groups → your Redshift SG → Inbound rules → Edit inbound rules → Add rule, then set Type = Custom TCP, Port range = 5439, Source = 20.7.240.218/32.
• Publicly accessible = Yes is the simplest path for temporary testing; for production, prefer a VPC peering / PrivateLink setup with 4MINDS support.
• SSL — All connections use SSL (sslmode=require), as required for temporary-credential auth.

Note: If a connection still times out after allowlisting the IP above, the backend egress IP may have changed — contact 4MINDS support to confirm the current address before widening your rules.

“Connection timed out. The backend may not be able to reach the Redshift endpoint — check VPC / security group rules (inbound port open from the backend’s network).”

​

Security Model

​

Testing Your Connection

1. Resolves your auth method → AWS credentials (via STS AssumeRoleWithWebIdentity for Role Federation, or Cognito GetCredentialsForIdentity for Cognito).
2. Calls redshift:DescribeClusters with a 15-second timeout.
3. Returns “Connection successful. Found N Redshift cluster(s).” on success.

​

Troubleshooting

​

Disconnecting

1. Open Integrations → Amazon Redshift → click Settings.
2. Click Disconnect.