How to Manage Redshift Destination Credentials in Skippr

July 2026

Keep Redshift destination credentials safe by using AWS IAM-backed auth instead of embedding keys, leaving staging and cluster settings visible, and configuring iam_role_arn so Redshift can read staged files cleanly.

Short Answer

Manage Redshift destination credentials in Skippr by using the AWS default credential chain for the API-facing side of the connector and keeping database, schema, cluster_identifier or workgroup_name, region, staging_s3_bucket, staging_s3_prefix, and iam_role_arn visible in config. The destination does not need a checked-in AWS key file.

That is the right secret-handling model because Redshift loading has two identity boundaries. The runtime needs AWS credentials to call the Redshift API resources you reference, and Redshift itself needs the configured iam_role_arn so it can read staged files from S3 during COPY. When CDC is enabled, the same warehouse path supports the documented staging-table plus MERGE final-state flow with order tokens and tombstones.

Why Teams Struggle with This

Redshift destination auth gets brittle when teams treat the whole load path as one credential. It is not. The runner identity, the Redshift database user, and the S3-read role each have a different job and should be scoped that way.

• Embedding raw AWS keys in config is usually weaker than using an IAM role, task role, or AWS SSO.
• A valid API caller still cannot complete loads if Redshift lacks the S3 permissions behind iam_role_arn.
• The destination database user also needs write access to the target schema, which is separate from AWS authentication.
• Hiding staging bucket details makes troubleshooting harder even though those fields are operational, not secret.

How Skippr Handles It

Skippr keeps Redshift readable because the config shows every operational dependency in plain view: cluster or workgroup, target schema, staging bucket, and Redshift role. The secret stays in the AWS identity the environment already manages.

That is especially helpful for CDC workloads. The same controlled load path that stages files for initial loads also supports the documented final-state MERGE behavior, so you can explain both auth and reconciliation without inventing extra connector secrets.

• Uses the AWS default credential chain for the runtime side of destination auth.
• Keeps cluster or workgroup, schema, staging bucket, and iam_role_arn visible in config.
• Relies on Redshift access to the staging S3 bucket through the configured IAM role.
• Supports CDC through staging-table MERGE, _skippr_order_token, and tombstone tables.

What the First Useful Version Looks Like

The first useful version is one Redshift cluster or Serverless workgroup, one target schema, one staging S3 prefix, and one IAM role Redshift can use to read it. That proves the full credential chain without hiding the warehouse shape.

If you separate environments, keep the visible staging and cluster settings environment-specific and let each environment resolve its own AWS identity instead of reusing static keys.