Skippr Docs

Appearance

How Redshift Source Authentication Works in Skippr ​

June 2026

Redshift source authentication is a two-layer model: AWS credentials authorize the Data API call, and the Redshift database context still decides which tables the source can actually read.

Short Answer ​

Redshift source authentication in Skippr starts with the AWS default credential chain because the connector reads Redshift through the Redshift Data API. That means access keys, IAM roles, instance profiles, task roles, AWS SSO, or shared config profiles can all be valid ways to authenticate the caller.

The second layer is the Redshift database context itself. In cluster mode you usually provide db_user, and in both cluster and serverless setups you still name the target database. A source pointed at cluster analytics-prod, database analytics, and table public.orders is only usable when the AWS principal can call the API resources for that environment and the database context can read the requested tables.

Why Teams Struggle with This ​

This is one of the connectors where "authentication worked" can be misleading. The docs distinguish between AWS-level authorization to call Redshift and database-level access to read data. If either layer is wrong, the source is not truly authenticated for the job you want it to do.

  • The connector authenticates to Redshift through the AWS default credential chain because it uses the Data API.
  • The configured cluster identifier or workgroup name determines which Redshift environment those AWS credentials are trying to access.
  • The database context, and often db_user, still controls whether the selected tables are readable once the API call succeeds.
  • The runner must reach the regional Redshift API endpoint, so network and region settings are part of the source auth story.

How Skippr Handles It ​

Skippr handles this well because it does not blur the two identity layers. The source block tells you which AWS identity model is in play and which Redshift database context the source expects, so review is more like checking an integration contract than guessing at a hidden driver state.

That also makes first-run debugging cleaner. If the API call fails, look at the AWS principal, region, and cluster or workgroup identifiers. If the query returns nothing or errors on access, inspect the Redshift database user and table permissions.

  • Authentication through the AWS default credential chain for Redshift Data API access.
  • Explicit Redshift targeting through cluster_identifier or workgroup_name, plus database and optional db_user.
  • A documented requirement that the database user can read the selected tables.
  • A clean split between AWS authorization issues and Redshift SQL-permission issues.

What the First Useful Version Looks Like ​

The first useful version is one Redshift environment, one database, and one or two readable tables under a caller that can use the Data API. That proves both identity layers without extra moving parts.

After that, keep the database context explicit. Redshift source auth stays understandable when AWS access and SQL access are treated as related but separate checks.