Skip to content

Access Management Policy

An Access Management Policy controls which roles can access schema objects on Snowflake and sidecar-connected data sources. Instead of managing privileges by hand, you define a policy in ALTR that specifies which roles should have which level of access to which objects, and ALTR enforces it on the data source.

On Snowflake, an Access Management Policy has three parts:

  • Target objects — the objects the policy covers, identified by one of the matching strategies below.
  • Roles — the roles on your data source that receive access. Policies target roles, not individual users, and the roles must already exist on the data source — ALTR does not create them.
  • Privilege level — read or write. OLTP repositories use a different privilege vocabulary for the same idea — create, read, update, delete — set per rule; see Restrict Access to Repository Objects.

Whether a policy covers objects created after it is defined depends on what its rule targets: a rule targeting a schema or database automatically extends to tables and views created inside it afterward, once ALTR applies the policy — via Snowflake’s own future-grants feature, no extra configuration needed. A rule targeting individual tables or views by name or tag pattern — or a schema/database rule whose target doesn’t exist yet — only picks up new matches if a refresh schedule is configured when the policy is created; by default (none), ALTR does not re-scan for new objects after initial application.

On Snowflake, a policy targets its objects using one of these matching strategies:

StrategyExampleBehavior
ExactCUSTOMERSMatches objects with exactly this name
Starts-withANALYTICS_*Matches objects whose name begins with the prefix
Ends-with*_PIIMatches objects whose name ends with the suffix
Fully-qualifiedDB.SCHEMA.TABLEMatches one specific object by its full name
Tag-based (AND)Tag A AND Tag BMatches objects that carry all of the specified tags
Tag-based (OR)Tag A OR Tag BMatches objects that carry any of the specified tags

On Snowflake, when more than one Access Management Policy applies to the same object, the resulting access is the union of all privileges those policies grant. One policy cannot subtract access that another policy grants.

On Snowflake, ALTR applies a policy by granting the corresponding privileges to the policy’s roles on your Snowflake account. Grants are applied on a scheduled basis, so there is a delay between saving a policy and its enforcement. If the policy’s rule targets a schema or database, tables and views created inside it afterward are covered automatically through Snowflake’s native future grants. Otherwise, new objects matching a policy’s pattern are only picked up if a refresh schedule is configured. For the specific privileges ALTR grants by object type and privilege level, see Access Management Policy on Snowflake.

On sidecar-connected data sources, ALTR enforces the policy in real time: the sidecar parses each incoming query, identifies the objects it accesses, and cancels queries the policy does not allow. ALTR relies on query parsing to identify accessed objects; support for all query types is not guaranteed. For how the sidecar evaluates and blocks queries, see Access Management Policy with Sidecars.

To create an Access Management Policy on Snowflake:

  1. Select Policy in the navigation menu.
  2. Click Create Policy and choose the Access Management Policy type.
  3. Select Snowflake as the connection type.
  4. Enter a Policy Name and select the Data Source the policy applies to.
  5. Choose a rule type — Object Name or Tag — and, for each rule, set role-based access (read, write, or read and write) for the matching tables or views.
  6. Set a policy-refresh schedule — none, daily, weekly, or monthly.
  7. Click Save. ALTR begins enforcing the policy on the next scheduled run.

For an OLTP repository, see Restrict Access to Repository Objects for the full procedure.

Users can request access to Snowflake data objects themselves, and an approved request automatically creates the corresponding Access Management Policy. See Access Requests.