Skippr Docs

Appearance

What Access Skippr Needs to Read from S3 ​

June 2026

S3 access is simple when the bucket and prefix are explicit, but it still depends on the exact IAM actions the source run will perform.

Short Answer ​

Skippr needs standard AWS credentials and, at minimum, s3:GetObject plus s3:ListBucket on the target bucket and its objects. The source docs even show the IAM pattern directly, which is useful because reading S3 is always a two-part permission question: can the runner list the bucket prefix and can it read the matching objects.

For example, if the source is s3_bucket: my-data-bucket with s3_prefix: raw/, the IAM policy has to cover arn:aws:s3:::my-data-bucket and arn:aws:s3:::my-data-bucket/*. Without ListBucket, Skippr may never discover the keys under raw/; without GetObject, it can list files but still fail to ingest them.

Why Teams Struggle with This ​

S3 access problems are often disguised as missing files. The bucket exists and the AWS identity looks valid, but the policy is incomplete or the prefix is wrong, so the run looks empty even though the real issue is authorization.

  • You need s3:ListBucket on the bucket and s3:GetObject on the objects Skippr should read.
  • The IAM policy should match the actual bucket and prefix instead of a broad guess copied from another environment.
  • If the bucket region is not inferred cleanly, the runner may also need AWS_DEFAULT_REGION.
  • Using a role, instance profile, or SSO profile works well, but the effective permissions still have to cover both listing and reading.

How Skippr Handles It ​

Skippr keeps S3 access review grounded in the AWS model teams already use. The source config only needs bucket, optional prefix, and optional namespace fields, while the authentication story stays on the standard AWS credential chain rather than inventing a second secret format.

That makes the first success easy to interpret. If Skippr can enumerate the keys under the intended prefix and open the files it finds, the IAM policy is good enough for the current boundary and you can move on to file-shape concerns.

  • Uses normal AWS credentials rather than inline cloud secrets.
  • Needs the exact S3 actions documented in the source guide: ListBucket and GetObject.
  • Can scope extraction by bucket and prefix so IAM stays narrow.
  • Auto-detects supported file formats after the access layer is correct.

What the First Useful Version Looks Like ​

The first useful version is one bucket, one prefix, and one role whose IAM policy names those resources explicitly instead of relying on wildcard storage access.

Once listing and reads work, you can widen the prefix or add namespace fields, but access review should stay tied to the actual objects the pipeline intends to scan.