Skippr Docs

Appearance

How to Manage DynamoDB Source Credentials in Skippr ​

July 2026

Keep DynamoDB source credentials safe by using the AWS default credential chain instead of embedding keys in config, while scoping IAM access to one table, one region, and optional Streams permissions for CDC.

Short Answer ​

Manage DynamoDB source credentials in Skippr by not creating a custom secret field at all. The documented connector uses the AWS default credential chain, so the safe pattern is to keep table_name, region, and any endpoint_url in config while the runner gets credentials from IAM roles, instance profiles, task roles, AWS SSO, or standard AWS environment variables.

That is the real auth model the source expects. If the pipeline runs on ECS, EC2, or another AWS-managed environment, the cleanest setup is often no static key in skippr.yaml and no secret in the repo. Skippr simply uses the principal the AWS SDK resolves, then calls DynamoDB with that identity.

Why Teams Struggle with This ​

DynamoDB credential issues usually come from forcing a static-key pattern onto a connector that already has a documented AWS identity model. Teams often rotate keys, forget the region, or miss basic table permissions and then blame the pipeline config even though the config was never meant to hold the secret.

  • Hard-coding AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY into local files creates unnecessary long-lived secrets.
  • Batch extraction needs dynamodb:DescribeTable and dynamodb:Scan, and missing either one can look like a vague auth failure.
  • CDC requires DynamoDB Streams permissions in addition to normal table read access.
  • A custom endpoint such as LocalStack changes connectivity details but does not change the underlying AWS credential model you need in production.

How Skippr Handles It ​

Skippr makes DynamoDB straightforward because the connector keeps auth separate from source shape. You configure the table and region, and the runtime supplies credentials through the AWS chain the team already trusts.

That is also the safest way to scale. A role can be scoped to one table for scan reads today, then extended with Streams permissions later when you want CDC into a supported warehouse destination.

  • Uses the AWS default credential chain instead of a connector-specific password field.
  • Keeps table_name, region, and endpoint_url visible in config for review.
  • Supports a staged move from scan-based reads to Streams-based CDC with the same identity model.
  • Works well with IAM roles, task roles, instance profiles, or AWS SSO to reduce static secret sprawl.

What the First Useful Version Looks Like ​

The first useful version is one AWS principal, one table, and one region. Confirm DescribeTable and Scan work before you add CDC permissions or more tables.

When you later enable cdc_enabled: true, extend the same principal for Streams access instead of creating a second unrelated credential path.