## Connect over the internet with IP allowlisting

URL: https://docs.atlan.com/apps/connectors/database/postgresql/how-tos/connect-over-the-internet-with-ip-allowlisting

> The fastest path to connect Atlan to PostgreSQL - Atlan connects to your database's public endpoint over TLS, and you allowlist Atlan's fixed egress IPs. Five phases, each labeled with who performs it.

The fastest path: Atlan connects to your database's public endpoint over TLS, and you allowlist Atlan's fixed egress IPs. Five phases, each labeled with who performs it.

:::note New to this?

Read [How database connectivity works](https://docs.atlan.com/llms/connectors/postgresql/how-database-connectivity-works/llms.txt) first (5 minutes). It explains the three gates - firewall, `pg_hba.conf`, authentication - that this guide configures one by one.

:::

## Prerequisites

- Your database has a public endpoint (RDS "publicly accessible", a public listener, or a routable address) on port 5432 or another port you know.
- Someone who can create database users and grants (your Postgres admin).
- Someone who can edit the firewall/security group (your cloud/network team) - may be the same person.

## Five phases at glance

| Phase | What happens | Owner | Typical time |
|---|---|---|---|
| 1. Create the user | Service user + read grants in PostgreSQL | Postgres admin | 15 minutes |
| 2. Get Atlan's IPs | Request your tenant's egress IPs | Atlan User + Atlan support | 1 business day |
| 3. Open the firewall | Inbound rule for Atlan's IPs on your port | Your cloud/network team | 15 minutes |
| 4. Configure pg_hba and SSL | Make sure PostgreSQL itself accepts the connection | Postgres admin | 15 minutes |
| 5. Connect and verify | Create the connection in Atlan and test | Atlan User | 15 minutes |

## Phase 1 - Create service user and grants

**Owner:** Postgres admin

From [Set up PostgreSQL](https://docs.atlan.com/llms/connectors/postgresql/set-up-postgresql/llms.txt) - create a dedicated user and grant it read access to the metadata you want cataloged:

```sql
CREATE USER atlan_user PASSWORD '<strong-password>';
-- Minimum: schema access, so INFORMATION_SCHEMA metadata can be fetched
GRANT USAGE ON SCHEMA <schema> TO atlan_user_role;
-- Optional, for sample-data preview in Atlan:
GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA <schema> TO atlan_user_role;
GRANT atlan_user_role TO atlan_user;
```

Repeat the grants for each database and schema you want to crawl - a connection sees one database at a time.

:::tip Planning to use the miner (lineage from query history)?

Have the admin also enable the query-history extension now - it needs a server restart on self-managed servers (on RDS/Aurora it's a parameter-group change):

`CREATE EXTENSION IF NOT EXISTS pg_stat_statements;` then `GRANT pg_read_all_stats TO atlan_user;`

Skipping this is a recurring cause of miner preflight failures - see [troubleshooting](https://docs.atlan.com/llms/connectors/postgresql/troubleshooting-postgresql-connectivity/llms.txt).

:::

## Phase 2 - Get your tenant's egress IPs

**Owner:** Atlan User + Atlan support

[Raise a support request](https://docs.atlan.com/support/submit-request) from within Atlan with your tenant URL: "Please share the public egress (NAT) IPs for my tenant, for allowlisting a PostgreSQL source." Values are tenant-specific - don't reuse IPs from another tenant or an old ticket. See [Atlan Network Details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt) for what else to ask for in the same request.

:::caution QA and production tenants have different IPs

If you run more than one Atlan tenant (for example, a QA instance), each has its own egress IPs. A real support pattern: production connections fine, QA connections all timing out - because only production's IPs were allowlisted. Ask for the IPs of every tenant that will connect.

:::

## Phase 3 - Open firewall

**Owner:** Your cloud/network team

- **AWS RDS/Aurora:** add an inbound rule to the database's security group - source = Atlan's egress IPs, port = 5432 (or yours), protocol TCP. The instance must be "publicly accessible" for the internet path.
- **Azure Database for PostgreSQL:** add Atlan's IPs under **Networking → Firewall rules**.
- **Self-managed / on-prem:** open the port on every firewall between the internet and the server. If a proxy or load balancer sits in front, it must forward the PostgreSQL port - see [Special cases](https://docs.atlan.com/llms/connectors/postgresql/special-cases/llms.txt) for the reverse-proxy pattern.

## Phase 4 - Configure pg_hba.conf and SSL

**Owner:** Postgres admin

Gate 2. Even with the firewall open, PostgreSQL itself must accept the connection:

```

# TYPE DATABASE USER ADDRESS METHOD

hostssl analytics atlan_user 203.0.113.10/32 scram-sha-256
hostssl analytics atlan_user 203.0.113.11/32 scram-sha-256

# hostssl = SSL required. Place these BEFORE any broader reject/catch-all rules.

```

- **Self-managed:** add a rule per Atlan IP (or the CIDR support gave you), for the right database and user, then reload PostgreSQL. Rule order matters - the first matching rule wins.
- **RDS/Aurora:** you can't edit `pg_hba.conf`; AWS manages it. What you control is the parameter group - notably `rds.force_ssl` (when `1`, all connections must use SSL) - and the authentication method per user (password vs. `rds_iam`).
- **Decide your SSL stance now.** If the server requires SSL (a `hostssl` rule or `rds.force_ssl=1`), the Atlan connection must be configured with SSL mode `require` or stricter in Phase 5. Mismatch here is the single most ticketed failure.
- If the user authenticates via PAM/LDAP rather than a normal database password, verify that stack accepts non-interactive service accounts - or switch this user to `scram-sha-256`, which is cleaner for service accounts.

## Phase 5 - Connect and verify

**Owner:** Atlan User

1. In Atlan, open **New workflow → PostgreSQL Assets** and choose **Direct** extraction.
2. Enter **Host** (the database's DNS hostname - prefer it over a raw IP, which can change on restart), **Port**, **Database**, and your credentials. Auth options per [Crawl PostgreSQL](https://docs.atlan.com/llms/connectors/postgresql/crawl-postgresql/llms.txt): Basic (username/password), IAM User (AWS access key + secret + database username), or IAM Role (AWS Role ARN + database username + optional External ID).
3. Set the SSL mode to match Phase 4 (see the caution below).
4. Click **Test connection**, then run the preflight checks when configuring the crawler.

:::caution If you can't find an SSL setting

The connector has historically defaulted to a permissive SSL mode with no obvious field in the setup form, causing rejections against SSL-required servers. If your server requires SSL and you don't see an SSL mode field in your tenant's form, [raise a support ticket](https://docs.atlan.com/support/submit-request) and ask for the connection's `sslmode` to be set to `require` - reference "PostgreSQL sslmode configuration."

:::

## Success checklist

- **Test connection** passes in the Atlan UI
- Preflight checks pass when you configure the crawler
- A crawl scoped to one small schema completes
- A full crawl (and miner run, if configured) completes on schedule at least once

All green? You're done. Any step failing - see [Troubleshooting PostgreSQL connectivity](https://docs.atlan.com/llms/connectors/postgresql/troubleshooting-postgresql-connectivity/llms.txt).

## Next steps

[Crawl PostgreSQL](https://docs.atlan.com/llms/connectors/postgresql/crawl-postgresql/llms.txt): Configure and run the crawler to extract metadata from PostgreSQL

---