Skip to main content

Set up S3 access with IAM access keys

TL;DR

The fully self-serve way to connect Atlan to Amazon S3 - create an IAM user, attach the permission policy, and paste its keys into Atlan.

Connect

The fully self-serve method: create an IAM user, attach the same permission policy, and paste its keys into Atlan. Faster than the role, weaker security posture - best for POCs.

When to use this​

  • You need to be crawling today and can't wait for the role handshake.
  • Your organization prohibits cross-account role trust.
  • Otherwise, prefer the IAM role - it's the recommended path for production.

Steps​

  1. Your AWS admin - Create the permission policy exactly as in Phase 2 of the role guide (same actions, same ListAllMyBuckets-on-* rule).
  2. Your AWS admin - In the IAM console, create a user (suggested name: atlan-s3-crawler) with no console access, attach the policy, and generate an access key (type: third-party service).
  3. Atlan User - New workflow → Amazon S3 Assets, choose IAM User authentication, and enter the Access Key ID, Secret Access Key, and your buckets' region directly in the credential form.
  4. Click Test Authentication, then configure filters and run.
Keys are secrets - handle accordingly

Enter keys only in the Atlan credential form (they're stored encrypted). Never paste them into a support ticket, email, or chat. If a key is ever exposed, deactivate it in the IAM console immediately and generate a new one - Atlan only needs the new pair entered in the connection's credential settings.

Set a rotation reminder now

Access keys don't expire on their own. Follow your organization's rotation policy (90 days is a common default): generate a second key for the user, update the Atlan credential, confirm a crawl succeeds, then deactivate the old key - zero downtime.

Everything else is identical to the role path​

Bucket policies, KMS key policies, prefix scoping, region, and inventory ingestion behave exactly the same for a user as for a role - a KMS key policy that only names the role will still block the user. Continue with Bucket policies, KMS keys, and prefix scoping, and use the same success checklist.

Known platform quirk - Azure-hosted Atlan tenants

A past Azure-hosted-tenant bug forced role assumption even when IAM user auth was chosen, failing with an AssumeRole error that made no sense for key-based auth (since fixed). If you see AssumeRole errors while using access keys, it's not your configuration - raise a ticket citing that symptom.

Next steps​

Crawl S3: Configure and run the crawler to extract metadata from Amazon S3