Skip to main content

Security

This FAQ answers common questions about Lakehouse security controls, authentication and authorization, and encryption.

Access control and encryption​

Is access to Lakehouse secure? How does Lakehouse handle data?​

Yes. Lakehouse protects metadata through layered security controls:

  • The catalog is the only entry point that query engines use to access Lakehouse metadata.
  • Iceberg data files and metadata files are stored in Atlan-managed object storage and encrypted at rest.
  • Access to object storage is logged and tracked.
  • You control end-user access in your query engine by using the engine’s native access controls (for example, Snowflake RBAC).

How does authentication work between query engine and catalog?​

The query engine authenticates to the catalog by using an engine-to-catalog credential. The catalog validates the credential on every metadata request and enforces namespace and table permissions.

This is service-to-service authentication. End users don't sign in to the catalog.

How are credentials authorized to access specific assets in Lakehouse? Where’s authorization managed and enforced?​

The OAuth client that the query engine uses is mapped to a read-only catalog role scoped to only the Iceberg namespaces and tables explicitly permitted for that Lakehouse.

Authorization is managed in Polaris, the catalog component of Atlan. Polaris enforces namespace- and table-level permissions on every catalog request. If the credential isn't authorized to access a table, Polaris doesn't return metadata for it.

In addition, query engine administrators can apply the engine's native access controls to the linked Lakehouse catalog or tables to further restrict which users and roles can query Lakehouse data.

When a query runs:

  1. The query engine authenticates to the catalog using its catalog integration credential.
  2. The catalog authorizes the request and returns only permitted Iceberg metadata, including file locations and temporary object storage credentials scoped to those files.
  3. The query engine uses the temporary credentials to read the required files from object storage and process the query.

How does catalog control access to data files?​

At query time, the catalog provides authorized query engines with the locations of the data files required to run the query and temporary credentials to access those object storage locations.

Do existing Atlan account security policies apply?​

Yes. The catalog inherits your existing account security policies. If you have configured IP allowlists for your Atlan account, those same restrictions apply to catalog access.

Credential rotation​

Does Lakehouse support credential rotation?​

Yes. Atlan can rotate the OAuth credentials that your query engine uses to authenticate to the Lakehouse catalog. To request a credential rotation, or to set up a recurring rotation schedule, contact Atlan Support.

What happens after credentials are rotated?​

After rotation, the new credentials are available on the Lakehouse setup page in Atlan. You must update your query engine connection with the new credentials for queries to continue working. See the credential update steps for your engine:

Is there downtime during credential rotation?​

Queries that use the previous credentials fail once the old credentials are invalidated. To minimize disruption, update your query engine connection as soon as new credentials are available.

My Atlan tenant uses private networking. How do I connect my query engine to Lakehouse?​

If your Atlan tenant is deployed with a private or isolated network configuration (for example, IP allowlists), your query engine must be able to reach the tenant's catalog endpoint over HTTPS. Requests from IPs outside the allowlist are blocked, which causes catalog integration errors such as Failed to create catalog integration in Snowflake.

To allow your query engine to connect:

  1. Open a Support ticket with Atlan.
  2. In the ticket, provide the egress IPs or NAT range that your query engine uses to call external services. Your cloud or network team can provide these.
  3. Atlan Support adds those IPs to your tenant's load-balancer allowlist.

Once the IPs are allowlisted, your query engine can reach the catalog endpoint and complete the integration setup.

Setup permissions​

Why is Snowflake administrator access required during setup?​

Snowflake requires elevated privileges to create a catalog integration, register the external catalog, and create external Iceberg tables. This access is required during setup to bootstrap the integration and apply least-privilege roles for ongoing use.

After setup, day-to-day querying runs under restricted Snowflake roles. Lakehouse doesn't require ongoing Snowflake admin credentials.