Skip to main content

Allowlists and firewalls

TL;DR

Everything IP- and firewall-related for dbt - dbt Cloud's IP restrictions feature, and storage-side firewalls for dbt Core buckets.

Connect

Everything IP- and firewall-related for dbt, in one place: dbt Cloud's IP restrictions feature, and storage-side firewalls for dbt Core buckets.

Do I need this page?​

SituationApplies?
dbt Cloud with IP restrictions enabled (Account settings → IP restrictions)Yes - allowlist Atlan's NAT IP or every call fails
dbt Cloud, no IP restrictionsNo - Atlan connects with just the token
dbt Core, bucket has a firewall / "selected networks" rule / explicit-deny bucket policyYes - the storage firewall section below
dbt Core, open (IAM-only) bucket accessNo - Phase 2 of the Core guide is all you need

dbt Cloud IP restrictions​

  1. Ask Atlan support for your tenant's static outbound NAT IPs (they're tenant-specific - see Atlan Network Details).
  2. Your dbt Cloud admin adds every one of them to Account settings → IP restrictions → allowlist in dbt Cloud.
  3. Re-run Test Authentication in Atlan.

When IP restrictions block Atlan, the error reads "Access forbidden. Please check your dbt Cloud token permissions."—it says nothing about IPs. If the token has the correct permissions and you still see this error, IP restrictions are almost certainly the cause.

Storage-side firewalls (dbt Core)​

AWS S3​

  • Explicit denies win. A bucket policy with an explicit Deny overrides every Allow - Atlan's role can have perfect permissions and still get AccessDenied ... with an explicit deny in a resource-based policy. Ask your cloud team to check for deny statements scoped by VPC, IP, or organization.
  • KMS counts as a second gate. Encrypted bucket → the role also needs kms:Decrypt on the key.

Azure storage firewall - same-region trap​

If your Atlan tenant and your storage account are in the same Azure region, traffic between them travels Azure's internal network and never presents a public IP - so IP allowlist rules on the storage firewall can never match it, and allowlisting Atlan's NAT IP achieves nothing. Options that do work:

  • A resource-instance exception on the storage firewall for Atlan's managed identity (ask support for the identity's details), or
  • Temporarily relaxing the firewall to confirm the network is the blocker, then choosing a permanent mechanism with support.

Google Cloud Storage​

  • Access is IAM-based: the service account needs roles/storage.objectViewer on the specific bucket. A grant on a different bucket or project produces Error 403 ... does not have storage.objects.list access.
  • If you use VPC Service Controls around the bucket, involve Atlan support - the perimeter must admit Atlan's identity.

When Atlan's IPs change​

Rare and announced in advance by email to tenant admins, with an overlap window (see Atlan Network Details). If dbt Cloud calls start failing right after such a notice, your allowlist is still on the old IPs.