Custom policy cofiguration
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”:
{
"version": "v1",
"statements": [
{
"description": "Sample policy - Query a given table, deny everything else",
"resources": [
"srn2:cluster#myCluster:table#myTable"
],
"effect": "allow",
"actions": [
"query"
]
}
]
}
A few important things to note:
- 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”
).
You can find additional examples of policy configurations below.
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:cluster#myCluster identifies the cluster called “myCluster”.
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.
cluster#*
in the SRN.Examples of policy configurations
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.)
{
"Version": "v1",
"PolicyName": "SystemAdministrator",
"Statements": [
{
"Description": "Can do everything in an environment",
"Resources": [
"*"
],
"Effect": "Allow",
"Actions": [
"*"
]
}
]
}
Pinot Administrator
A Pinot administrator can perform all actions in a Pinot cluster
{
"Version": "v1",
"PolicyName": "PinotAdministrator",
"Statements": [
{
"Description": "Allow all actions on 'myCluster' Pinot cluster, and all tables in the cluster",
"Resources": [
"srn2:cluster#myCluster",
"srn2:cluster#myCluster:table#*"
],
"Effect": "Allow",
"Actions": [
"*"
]
}
]
}
The same policy can also be written like this:
{
"Version": "v1",
"PolicyName": "PinotAdministrator",
"Statements": [
{
"Description": "Allow all actions on 'myCluster' Pinot cluster, including all resources in the hierarchy under myCluster.",
"Resources": [
"srn2:cluster#myCluster:*#*"
],
"Effect": "Allow",
"Actions": [
"*"
]
}
]
}
Pinot Table Admin
A Pinot table admin can perform any actions on a table
{
"Version": "v1",
"PolicyName": "PinotTableAdmin",
"Statements": [
{
"Description": "Allow all actions on 'myTable' table",
"Resource": "srn2:cluster#my-cluster:table#myTable",
"Effect": "Allow",
"Actions": [
"*"
]
}
]
}
Pinot Table Reader
A Pinot table reader can perform any read-only operation on a given table.
{
"Version": "v1",
"PolicyName": "PinotTableReader",
"Statements": [
{
"Description": "Allow any read-only operation on a Pinot table",
"Resource": "srn2:cluster#myCluster:table#myTable",
"Effect": "Allow",
"Actions": [
"Query",
"GetInstancePartitions",
"GetConsumingSegmentsInfo",
"GetStats",
...,
...,
...
]
}
]
}
- For a full list of available actions, see Actions
Pinot Table Query
This policy allows querying a given Pinot table.
{
"Version": "v1",
"PolicyName": "PinotTableReader",
"Statements": [
{
"Description": "Allow querying a Pinot table",
"Resource": "srn2:cluster#myCluster:table#myTable",
"Effect": "Allow",
"Actions": [
"Query"
]
}
]
}
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
{
"Version": "v1",
"PolicyName": "DataScientist",
"Statements": [
{
"Description": "Query tables with the prefix 'Prod'",
"Resource": "srn2:cluster#*:table#Prod*",
"Effect": "Allow",
"Actions": [
"Query"
]
},
{
"Description": "All actions on tables with the prefix 'Test'",
"Resource": "srn2:cluster#*:table#Test*",
"Effect": "Allow",
"Actions": [
"*"
]
},
{
"Description": "Deny dropping tables and pausing consumption on all tables",
"Resource": "srn2:cluster#*:table#*",
"Effect": "Deny",
"Actions": [
"Delete*",
"PauseConsumption"
]
}
]
}