Skippr Docs

Appearance

How S3 Source Authentication Works in Skippr ​

June 2026

S3 source authentication follows normal AWS credential patterns, which is good news as long as the IAM policy really covers both listing the bucket and reading the objects you want.

Short Answer ​

S3 source authentication in Skippr uses standard AWS credentials. The source does not need a connector-specific token. It relies on the same AWS identity patterns the SDK already understands, such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, an IAM role on AWS infrastructure, or an SSO-backed profile.

The docs make the useful detail explicit: the authenticated principal needs to list the bucket and read the objects it will ingest. If your source points at bucket my-data-bucket with prefix raw/, the identity has to cover both s3:ListBucket on the bucket and s3:GetObject on the matching keys, otherwise authentication may succeed while ingestion still cannot enumerate or open the files.

Why Teams Struggle with This ​

S3 auth problems usually come from treating object storage like a single yes-or-no permission check. The docs spell out a more practical model: one identity, one bucket, one prefix, and the specific rights to list and read what the connector is supposed to process.

  • Standard AWS credentials work, including keys, IAM roles, and SSO-backed profiles.
  • The IAM policy needs both s3:ListBucket and s3:GetObject to support a normal source read.
  • If the region is not obvious from the bucket context, AWS_DEFAULT_REGION may still matter to the runtime environment.
  • A source with the right credentials can still look broken if the configured prefix does not match the objects the identity is allowed to read.

How Skippr Handles It ​

Skippr does the sensible thing here by staying close to AWS norms. You authenticate with the same identity your platform already trusts and keep the source config focused on s3_bucket, optional s3_prefix, and namespacing choices.

That makes first-run reviews concrete. Instead of asking whether S3 "works," you can ask whether the pipeline identity can list my-data-bucket and read the objects under raw/. That is exactly the right level of detail for an operational source contract.

  • Authentication through standard AWS credentials and IAM roles.
  • A documented minimum IAM model of s3:ListBucket plus s3:GetObject.
  • Support for environment-based keys when a role is not available.
  • A simple source definition that keeps bucket and prefix scope explicit.

What the First Useful Version Looks Like ​

The first useful version is one bucket, one prefix, and one AWS identity with only the permissions required to list and read that slice. That proves the auth model without hiding mistakes behind wide IAM grants.

If you later expand the prefix or bucket scope, review the IAM policy at the same time. In S3, source authentication and source scope stay tightly coupled.