Skippr Docs

Appearance

How to Manage Redshift Source Credentials in Skippr ​

July 2026

Keep Redshift source credentials safe by using AWS IAM-backed auth for the Data API, avoiding static keys in config, and pairing that AWS identity with a database user that only needs read access.

Short Answer ​

Manage Redshift source credentials in Skippr by relying on the AWS default credential chain instead of inventing a connector-specific secret. The docs show cluster_identifier or workgroup_name, database, optional db_user, and region in config, while authentication comes from the AWS principal the runtime already has.

That is the documented model because the source reads Redshift through the Data API. The secret-handling job is usually IAM, not a password field in skippr.yaml. The practical boundary is to keep the Redshift identifiers visible, let the runner authenticate with AWS, and pair that identity with a Redshift database user that only needs the tables Skippr will read.

Why Teams Struggle with This ​

Redshift source auth gets muddled when teams treat AWS access and Redshift database access as one secret blob. They are separate. The AWS principal has to use the Data API resources, and the Redshift user still has to be allowed to read the chosen tables.

  • Creating long-lived AWS keys just for one pipeline is usually weaker than using an IAM role, task role, or AWS SSO.
  • A valid AWS principal still fails if the Redshift database user cannot read the selected tables.
  • Confusing cluster mode and Serverless workgroup mode leads to auth checks against the wrong Redshift resource.
  • If the runner cannot reach the correct regional Redshift API endpoint, the credential can be valid and the source will still fail.

How Skippr Handles It ​

Skippr keeps the Redshift source contract clear because the connector config describes which Redshift resource to query, not how to stash another password. That makes it easier to align with normal AWS identity practices and reduce static secret sprawl.

It also forces a better least-privilege story. One IAM principal governs Data API access, and one Redshift user governs table reads. Those responsibilities can be reviewed separately.

  • Uses the AWS default credential chain for Data API authentication.
  • Keeps cluster_identifier or workgroup_name, database, db_user, and region visible in config.
  • Fits IAM roles, task roles, instance profiles, or AWS SSO instead of checked-in keys.
  • Works best when the Redshift database user is scoped to the tables the source actually reads.

What the First Useful Version Looks Like ​

The first useful version is one Redshift cluster or workgroup, one AWS principal, and one database user reading one table. That proves both layers of access without hiding which Redshift resource is involved.

If you support multiple environments, keep the resource identifiers readable and swap IAM identities by environment instead of copying static keys into per-environment config files.