Custom Policy Configuration
Define and implement custom RBAC policies in StarTree Cloud by configuring granular permissions using StarTree Resource Names (SRNs), supporting over 150 distinct actions for precise access control across environments, clusters, and tables.
A policy configuration is a collection of one or more statement objects, each containing:
- A description of the policy statement.
- One or more actions that the policy statement applies to.
- The resources that the policy statement is applied to, identified using the SRN format.
- The effect of the policy statement (
allow
ordeny
).
Here’s an example of a policy that allows querying a table called “myTable”:
- Within a policy, deny statements take precedence regardless of their location in the policy.
- If actions aren’t explicitly specified, then all actions are implicitly included in the statement (the equivalent of writing
“actions”: “*”
). - If the effect isn’t explicitly specified, then
deny
is implicitly applied (the equivalent of writing“effect”: “deny”
).
Identifying resources using SRNs
A StarTree Resource Name (SRN) is a unique identifier for any resource within your StarTree environment. It follows a standardized format that makes it easy to understand and use.
SRNv2 format
The basic format of an SRNv2 is: srn2:<resource-type>#<resource-id>
.
For example: srn2:table#myTable identifies the table called “myTable”.
Some resources may have a more complex format to represent hierarchical relationships.
Constructing an SRNv2 string
Each SRNv2 string starts with the prefix srn2:
, followed by the resource type and then the resource identifier. A simple SRNv2 would follow this format: srn2:resource-type#resource-id
Since resources in StarTree are hierarchical, the SRNv2 string can include any number of levels of hierarchy. An SRNv2 with two levels of hierarchy would look like this: srn2:resource-type#resource-id:sub-resource-type#sub-resource-id
Commonly used resource types include: environment, cluster, workspace, and table.
Hierarchy levels can be omitted. For example, you can write a policy that applies to all tables called “myTable” across the entire environment by omitting the cluster resource type. Alternatively, you can explicitly include all clusters by adding cluster#*
in the SRN.
Examples of Policy Configurations for Common Functional Roles
With over 150 distinct actions, Apache Pinot and StarTree allow for very granular custom policy creation. This section provides guidance on mapping common functional roles and application usage to the specific permissions required in Apache Pinot.
This information serves as a guide for RBAC administrators to create and maintain policies and roles efficiently.
System Administrator
A System Administrator can perform all actions on any resource in the environment.
The system-admin
policy is predefined in StarTree, so you won’t need to define it yourself. We’re just showing it here as an example.
Cluster Administrator
A cluster administrator can perform all actions in a Pinot cluster
The same policy can also be written like this:
Table Admin
A table admin can perform any action on a table.
Table Reader
A table reader policy allows any read-only operation on a given table using the Query Console UI. Unlike the QueryTable policy, this policy includes additional permissions that allow the UI to retrieve additional helpful information about the table.
Query Table
This policy allows querying a given table.
RBAC Admin
This policy allows viewing and making changes to the RBAC policies, roles, assignments, and API tokens.
Using Wildcards
Wildcards provide flexibility to leverage naming conventions used in your organization.
In this example, the policy will:
- Allow all actions on tables with the prefix “Test”
- Allow queries on tables with the prefix “Prod”
- Deny deletes for all tables