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 or deny).

Here’s an example of a policy that allows querying a table called “myTable”:

{
  "version": "v1",
  "statements": [
    {
      "description": "A sample policy - allow query on a table called 'myTable', deny everything else",
      "resources": [
        "srn2:cluster#*: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”).

​
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

​
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",
  "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",
  "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",
  "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",
    "statements": [
    {
        "resources": "srn2:cluster#*:table#*",
        "effect": "allow",
        "actions": "*"
      },
      {
        "resources": "srn2:cluster#*",
        "effect": "allow",
        "actions": [
          "Get*",
          "*Task",
          "RecommendConfig"
        ]
      }
    ]
  }

​
Pinot Table Reader

A Pinot table reader can perform any read-only operation on a given table.

{
  "version": "v1",
  "statements": [
    {
      "description": "Allow any read-only operation on a Pinot table",
      "resources": "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",
  "statements": [
    {
      "description": "Allow querying a Pinot table",
      "resources": "srn2:cluster#myCluster:table#myTable",
      "effect": "allow",
      "actions": "Query"
    }
  ]
}

​
RBAC Admin

This policy allows viewing and making changes to the RBAC policies, roles, and assignments.

{
  "version": "v1",
  "statements": [
    {
      "description": "Allow all actions on policies and role",
      "resources": [
        "srn2:policy#*",
        "srn2:role#*"
      ]
      "effect": "allow",
      "actions": "*"
    }
  ]
}

​
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",
  "statements": [
    {
      "description": "Query tables with the prefix 'Prod'",
      "resources": "srn2:cluster#*:table#Prod*",
      "effect": "allow",
      "actions": "Query"
    },
    {
      "description": "All actions on tables with the prefix 'Test'",
      "resources": "srn2:cluster#*:table#Test*",
      "effect": "allow",
      "actions": "*"
    },
    {
      "description": "Deny dropping tables and pausing consumption on all tables",
      "resources": "srn2:cluster#*:table#*",
      "effect": "deny",
      "actions": [
        "Delete*",
        "PauseConsumption"
      ]
    }
  ]
}