Role-Based Access Control

This section provides information about how access control works for Apache Polaris.

Polaris uses a role-based access control (RBAC) model in which the Polaris administrator assigns access privileges to catalog roles and then grants access to resources to principals by assigning catalog roles to principal roles.

These are the key concepts to understanding access control in Polaris:

• Securable object
• Principal role
• Catalog role
• Privilege

Securable object🔗

A securable object is an object to which access can be granted. Polaris has the following securable objects:

• Catalog
• Namespace
• Iceberg table
• View
• Policy

Principal role🔗

A principal role is a resource in Polaris that you can use to logically group Polaris principals together and grant privileges on securable objects.

Polaris supports a many-to-many relationship between principals and principal roles. For example, to grant the same privileges to multiple principals, you can assign a single principal role to those principals. Likewise, a principal can be granted multiple principal roles.

You don’t grant privileges directly to a principal role. Instead, you configure object permissions at the catalog role level, and then grant catalog roles to a principal role.

The following table shows examples of principal roles that you might configure in Polaris:

Catalog role🔗

A catalog role belongs to a particular catalog resource in Polaris and specifies a set of permissions for actions on the catalog or objects in the catalog, such as catalog namespaces or tables. You can create one or more catalog roles for a catalog.

You grant privileges to a catalog role and then grant the catalog role to a principal role to bestow the privileges to one or more principals.

Polaris also supports a many-to-many relationship between catalog roles and principal roles. You can grant the same catalog role to one or more principal roles. Likewise, a principal role can be granted to one or more catalog roles.

The following table displays examples of catalog roles that you might configure in Polaris:

RBAC model🔗

The following diagram illustrates the RBAC model used by Polaris. For each catalog, the Polaris administrator assigns access privileges to catalog roles and then grants principals access to resources by assigning catalog roles to principal roles. Polaris supports a many-to-many relationship between principals and principal roles.

Access control privileges🔗

This section describes the privileges that are available in the Polaris access control model. Privileges are granted to catalog roles, catalog roles are granted to principal roles, and principal roles are granted to principals to specify the operations that principals can perform on objects in Polaris.

To grant the full set of privileges (drop, list, read, write, etc.) on an object, you can use the full privilege option.

Table privileges🔗

View privileges🔗

Namespace privileges🔗

Catalog privileges🔗

Policy privileges🔗

Semantic model privileges🔗

Semantic models use their own privileges, independently of table and view privileges. The management API supports grants on individual models and at namespace or catalog scope. Model-scoped grant inspection is deferred; model grants appear in the existing catalog-role grant listing.

Privileges granted on a namespace or catalog apply to descendant models. At these scopes, SEMANTIC_MODEL_CREATE, SEMANTIC_MODEL_READ, and SEMANTIC_MODEL_WRITE also permit listing models, matching table and view privileges. SEMANTIC_MODEL_FULL_METADATA grants list, create, read, update, and drop access within that scope. CATALOG_MANAGE_METADATA and CATALOG_MANAGE_CONTENT also cover semantic model metadata operations within their scope. NAMESPACE_FULL_METADATA and CATALOG_FULL_METADATA cover namespace and catalog metadata operations, respectively, and do not imply semantic model privileges. These metadata privileges do not confer grant management. Single-model grants require SEMANTIC_MODEL_MANAGE_GRANTS_ON_SECURABLE on the model. Revocation additionally requires CATALOG_ROLE_MANAGE_GRANTS_FOR_GRANTEE on the recipient role, following policy grant semantics. CATALOG_MANAGE_ACCESS can satisfy these grant-management checks within its scope. Namespace/catalog grants continue to use the existing namespace/catalog grant-management permissions.

Model authorization is independent of source table/view privileges. Source-access authorization on create/update and propagated read-time checks are deferred. Model privileges do not grant access to the underlying tables or views.

Use the existing management grant endpoint PUT /api/management/v1/catalogs/{catalogName}/catalog-roles/{catalogRoleName}/grants with a namespace grant, for example, to allow reading models in the sales namespace:

{
  "grant": {
    "type": "namespace",
    "namespace": ["sales"],
    "privilege": "SEMANTIC_MODEL_READ"
  }
}

For catalog-wide access, use type: "catalog" and omit namespace. To grant access only to the revenue model in the sales namespace, use:

{
  "grant": {
    "type": "semantic-model",
    "namespace": ["sales"],
    "semanticModelName": "revenue",
    "privilege": "SEMANTIC_MODEL_READ"
  }
}

Single-model grants can provide read, write, drop, full metadata, or grant-management access. They do not permit listing or creating models in the containing namespace; list and create privileges must be granted at namespace or catalog scope. Grant revocation uses the same request body with POST to the role’s grants endpoint. The existing role-grants listing returns grants with their model, namespace, or catalog scope.

RBAC example🔗

The following diagram illustrates how RBAC works in Polaris and includes the following users:

• Alice: A service admin who signs up for Polaris. Alice can create principals. She can also create catalogs and namespaces and configure access control for Polaris resources.

• Bob: A data engineer who uses Apache Spark™ to interact with Polaris.

  • Alice has created a principal for Bob. It has been granted the Data_engineer principal role, which in turn has been granted the following catalog roles: Catalog contributor and Data administrator (for both the Silver and Gold zone catalogs in the following diagram).

  • The Catalog contributor role grants permission to create namespaces and tables in the Bronze zone catalog.

  • The Data administrator roles grant full administrative rights to the Silver zone catalog and Gold zone catalog.

• Mark: A data scientist who uses trains models with data managed by Polaris.

  • Alice has created a principal for Mark. It has been granted the Data_scientist principal role, which in turn has been granted the catalog role named Catalog reader.

  • The Catalog reader role grants read-only access for a catalog named Gold zone catalog.