## Atlan identity details

URL: https://docs.atlan.com/apps/connectors/storage/amazon-s3/references/atlan-identity-details

> The Atlan-side values an Amazon S3 role setup needs, what each is for, and how to get them in a single support ticket.

The Atlan-side values an S3 role setup needs, what each is for, and how to get them. For S3 there are no IPs or endpoints to allowlist - Atlan's "network identity" is an IAM role. For how tenant-specific values work across all connectors, see [Atlan Network Details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt).

## Two values you need from Atlan

| Value | What it's for | Where to get it |
|---|---|---|
| **Node Instance Role ARN** of your Atlan tenant | Goes in your IAM role's **trust policy** as the trusted principal ("who may borrow the badge"). Looks like `arn:aws:iam::<atlan-account-id>:role/<tenant>-nodeinstance-role` (illustrative shape). | Support ticket - per tenant |
| **Atlan's AWS account ID** for your tenant | Some security teams require the 12-digit account number as well as the ARN for their approval workflows. | Support ticket - per tenant |

:::tip Ask for everything in one ticket

Raise **one** [support request](https://docs.atlan.com/support/submit-request) from within Atlan with your tenant URL and this exact ask: *"Please share (1) the Node Instance Role ARN and (2) the AWS account ID for my tenant, and (3) confirm you'll allowlist my role ARN for AssumeRole once I send it."* That third item matters: after you create your role, Atlan support must also configure **Atlan's side** to assume it - a second step many setups don't know exists. Bundling all three turns a week of round-trips into one exchange.

:::

## Which side needs which value

| Your setup | You give Atlan | Atlan gives you |
|---|---|---|
| IAM role (recommended) | Your role ARN + External ID (via ticket, then in the crawler form) | Node Instance Role ARN + account ID; confirmation your role is allowlisted |
| IAM user (access keys) | Access Key ID + Secret in the crawler form only - **never paste keys into a ticket** | Nothing - fully self-serve |
| Atlan-hosted bucket flows (query mining, exports - see [Special cases](https://docs.atlan.com/llms/connectors/amazon-s3/special-cases/llms.txt)) | Your role ARN (the *role*, not an instance-profile ARN) | The Atlan bucket name + a bucket-policy grant on Atlan's side |

## Permissions Atlan needs

The required S3 actions, by ingestion scope (see [Set up Amazon S3](https://docs.atlan.com/llms/connectors/amazon-s3/set-up-s3/llms.txt)):

| Scope | Actions |
|---|---|
| Buckets only | `s3:GetBucketLocation`, `s3:GetBucketTagging`, `s3:GetEncryptionConfiguration`, `s3:GetBucketVersioning`, `s3:ListAllMyBuckets` |
| + Folders | adds `s3:ListBucket` |
| + Objects | adds `s3:GetObject`, `s3:GetObjectTagging`, `s3:GetObjectRetention`, `s3:GetObjectLegalHold` |
| Inventory-based ingestion | `s3:ListBucket`, `s3:GetObject`, `s3:SelectObjectContent` on the inventory destination bucket |

:::danger Two facts the permission table doesn't tell you

**1.** `s3:ListAllMyBuckets` only works with `"Resource": "*"` - AWS ignores it when scoped to a bucket ARN, and the **Test connection** button fails with a 403.

**2.** Test connection validates *less* than a crawl uses. A test that passes with only list permissions will still fail mid-crawl on `GetObject*` actions. Run the full checklist on the [setup page](https://docs.atlan.com/llms/connectors/amazon-s3/set-up-s3-access-with-a-cross-account-iam-role/llms.txt) before calling it done.

:::

## Change management

- The Node Instance Role ARN is stable for the life of your tenant; it can change during major platform migrations - Atlan notifies tenant admins ahead of any such change.
- If a long-working connection suddenly fails at Door 1 (`AssumeRole` errors) and you changed nothing, ask support to re-verify the Atlan-side allowlist before rebuilding anything on your side - platform migrations have regressed role/External-ID settings before.

---