Skippr Docs

Appearance

How to Manage S3 Source Credentials in Skippr ​

July 2026

Keep S3 source credentials safe by treating bucket and prefix as visible config, using AWS IAM-backed auth whenever possible, and narrowing permissions to the exact bucket and key space Skippr reads.

Short Answer ​

Manage S3 source credentials in Skippr by letting AWS handle the secret and letting config describe the data location. The docs keep s3_bucket, s3_prefix, and any namespace settings in skippr.yaml, while authentication comes from standard AWS credentials or an IAM role that the runner already has.

That is the right model because an S3 bucket name is not the secret. The secret is the AWS identity that can list objects and read them. On EC2, ECS, or an SSO-backed workstation, the cleanest setup often means no static key in the file at all and no separate Skippr-specific password to manage.

Why Teams Struggle with This ​

S3 credential problems usually start when teams keep long-lived access keys around even though the runtime already supports IAM roles or SSO. Then they still need to review bucket permissions, prefix scope, and region issues on top of a secret they did not need.

  • Hard-coding AWS keys into pipeline config creates a secret leak and a rotation burden.
  • Broad bucket-wide access is often unnecessary when the connector only needs one prefix and two actions: s3:ListBucket and s3:GetObject.
  • The bucket and prefix should stay visible because they define what files the source will ingest.
  • Using the wrong region or the wrong bucket name looks like an auth problem until you check the actual S3 target.

How Skippr Handles It ​

Skippr keeps the S3 source straightforward because the connector describes object location and file-shape behavior, not a custom credential scheme. That means you can review the bucket, prefix, and namespace settings openly and keep the AWS secret lifecycle in the platform that already owns it.

This is also the safer path for shared infrastructure. A role can be scoped to one bucket and prefix, then reused by every scheduled run without spreading raw keys across config files.

  • Uses the standard AWS credential chain rather than a connector-specific password.
  • Keeps s3_bucket, s3_prefix, and namespace settings visible in config.
  • Fits IAM roles, task roles, and AWS SSO to reduce static key storage.
  • Works with a narrow IAM policy that grants only s3:ListBucket and s3:GetObject on the target path.

What the First Useful Version Looks Like ​

The first useful version is one bucket, one prefix, and one IAM principal that can list and read only that path. That proves both access and file discovery without widening the credential unnecessarily.

If the source later expands to more prefixes or buckets, add those permissions deliberately instead of replacing the role with a broad admin credential.