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:
allow
or deny
).Here’s an example of a policy that allows querying a table called “myTable”:
“actions”: “*”
).deny
is implicitly applied (the equivalent of writing “effect”: “deny”
).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.
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.
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.
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.
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.
A cluster administrator can perform all actions in a Pinot cluster
The same policy can also be written like this:
A table admin can perform any action on a table.
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.
This policy allows querying a given table.
This policy allows viewing and making changes to the RBAC policies, roles, assignments, and API tokens.
Wildcards provide flexibility to leverage naming conventions used in your organization.
In this example, the policy will:
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:
allow
or deny
).Here’s an example of a policy that allows querying a table called “myTable”:
“actions”: “*”
).deny
is implicitly applied (the equivalent of writing “effect”: “deny”
).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.
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.
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.
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.
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.
A cluster administrator can perform all actions in a Pinot cluster
The same policy can also be written like this:
A table admin can perform any action on a table.
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.
This policy allows querying a given table.
This policy allows viewing and making changes to the RBAC policies, roles, assignments, and API tokens.
Wildcards provide flexibility to leverage naming conventions used in your organization.
In this example, the policy will: