Connect with cross-account IAM role

✦TL;DR

The recommended way to connect Atlan to AWS Glue - Atlan assumes a role you create, so no long-lived secret ever leaves your account.

||

|Connect

The recommended method: Atlan assumes a role you create, so no long-lived secret ever leaves your account. Five phases - including the two-ticket handshake with Atlan support that most failed setups skipped.

Prerequisites

• Someone who can create IAM roles and edit trust policies in the AWS account holding the Glue catalog.
• If a security/cyber team must approve trust-policy changes (common in regulated industries), loop them in before Phase 2 - they'll ask about the External ID.
• Your Atlan tenant URLs. Connecting dev and prod tenants? Each has a different node instance role - plan one role (or one trust-policy entry) per tenant.

Five phases at glance

Phase	What happens	Owner	Typical time
1. Ask	Ticket #1: get your tenant's node instance role ARN	Atlan User + Atlan support	Same business day
2. Build	Create the IAM role: permissions policy + trust policy	AWS admin	30 min (+ security review)
3. Allowlist	Ticket #2: Atlan allowlists your role on its side - the critical handshake	Atlan support	1–2 business days
4. Connect	Enter Role ARN + region in Atlan and test	Atlan User	15 minutes
5. Verify	Preflight + first crawl + column sanity check	Atlan User	30 minutes

Phase 1 - Get Atlan's node instance role ARN

Owner: Atlan User

Raise a support request from within Atlan: "Setting up AWS Glue with role delegation—please share the node instance role ARN for tenant example-corp.atlan.com." List every tenant if you have several environments - the ARN differs per tenant. See Atlan identity & network details for the full request template.

Save a round-trip

If you already know the role name and AWS account ID you'll create in Phase 2, include them in this same ticket and ask support to pre-approve the allowlisting (Phase 3). This collapses the two-ticket handshake into one.

Phase 2—create role

Owner: AWS admin + Security/IAM team

1. Create the read-only IAM policy - same JSON as Phase 1 of the access-keys guide (or see Catalog permissions & Lake Formation).
2. Create a new IAM role (suggested name: atlan-glue-read), attach that policy.
3. Set the role's trust policy so Atlan's node instance role may assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "<atlan_nodeinstance_role_arn>" },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

About external ID

An External ID is an optional shared passphrase your security team may require inside the trust policy's Condition block. The rules that keep it from causing failures:

• If your security process doesn't demand one, leave it out entirely - trust policy and Atlan connection field both blank.
• If it does: for the standard (direct) flow, agree the value with Atlan support on your ticket before adding it to the trust policy. For the agent-based flow, the connection form has an optional External ID field - the value there and in the trust policy must match exactly.
• A value present on one side but not the other fails with an access-denied error that looks identical to a missing allowlist.

Phase 3 - Atlan allowlists your role

Owner: Atlan support

Reply on your ticket (or raise ticket #2) with two values: the name of the role you created and the 12-digit AWS account ID where it lives. Atlan support then permits your tenant's node instance role to assume your role. The lifecycle:

1. Role created - your side is done (Phase 2)
2. Awaiting allowlist - Test Authentication fails with "Access denied when assuming role" in this state, even though your setup is correct
3. Allowlisted - both keys of the door turn; assumption succeeds
4. Usable - proceed to Phase 4

Don't test before support confirms

This handshake is the most-missed step in the whole setup. A perfect trust policy still fails until Atlan's side is done. Wait for explicit confirmation on the ticket, then test. If the error persists after confirmation, check the role name for typos - support allowlists the exact ARN you sent, and two similarly named roles are easy to mix up.

Phase 4 - connect

Owner: Atlan User

1. Open New workflow → AWS Glue Assets, Direct extraction.
2. Enter the AWS Role ARN of the role from Phase 2 (full ARN, for example, arn:aws:iam::111122223333:role/atlan-glue-read - illustrative) and the Region of the catalog. Leave the access-key fields empty for this method; leave External ID blank unless agreed in Phase 2.
3. Click Test Authentication.

Phase 5 - verify

Owner: Atlan User

• Test Authentication passes
• All three preflight checks pass (authentication, GetDatabases, GetTables)
• First crawl completes and columns are populated - tables arriving with 0 columns means Lake Formation grants are missing, even though everything "passed"
• If you connected multiple tenants: repeat Phases 1–4 per tenant with that tenant's own node instance role ARN

Next steps

Crawl AWS Glue: Configure and run the crawler to extract metadata from AWS Glue