PDP 42 (New Resource String Format for Authorization)

Status: In Review

Table of Contents:

• Introduction
  • Background
  • Problems With the Current Resource String Format
  • Key Requirements
• Proposed Resource String Format
  • Key Design Goals & Constraints
  • Proposed Format
    • The "Domain" Part
    • The "Resource Id" Part
• Examples
  • Sample Resource Strings in Proposed Format
  • Sample Resource Patterns That May Be Used in Access Control Entries

Introduction

This proposal is for modifying the resource string format used for authorizing Controller, Segment Store and Schema Registry operations, so that resources can be identified precisely, uniquely and consistently, for the purposes of authorization.

Background

Authorization in Pravega protects resources like scopes, streams, reader groups, and key-value tables against unauthorized access. The resources are uniquely identified using a character-based "resource string".

Here are a few examples from the current scheme:

1. MarketData - A scope with name MarketData.
2. MarketData/Prices - A stream with name Prices under the same scope.
3. MarketData/PriceChangeCalculator - A reader group with name PriceChangeCalculator in the same scope, which reads from a specified stream in the same scope.

More examples can be found here.

Problems With the Current Resource String Format

The main problems with the current scheme are:

1. Certain resources cannot be distinguished. For example, both Reader Groups and Streams are represented as <scope-name>/<resource-name>. So, if a stream and a reader group shared the same name, providing access to one'd provide access to the other too.
2. The structure of the resource strings has started to diverge. For example. Key Value Tables, for example, are identified using <scope-name>/_kvtable/<resource-name>, which is inconsistent with the rest of the resource types. These divergences shall make it harder and harder for admins to specify Access Control Lists (ACL).
3. The current scheme works for two-level hierarchies alone in Pravega main code. The default Password-Based Auth Handler doesn't understand three-level hierarchy. Schema Registry uses a three-level hierarchy.

Key Requirements

1. The new scheme must allow for distinguishing resources of different types.
2. The format should work uniformly for resources in Pravega, Schema Registry, and components that may be introduced in the future.

Proposed Resource String Format

Key Design Goals & Constraints

Here are the key design goals:

1. Extensibility: As new resource types are introduced, authorization shall be extended to cover those resource types as well.
2. Consistency: Understanding a few instances of the resources should enable developers and admins to guess what should it be for other resource types.
3. Efficiency: Processing the resource string for authorization must not require complex and inefficient logic.

Here are the key constraints:

1. Authorization is performed for both application-created resources and internal resources created for internal purposes. Examples of the latter are: a) the _system scope, and b) MarketData/_RGPriceChangeCalculator.

   Internal resources tend to have names containing the prefix _. So, the scheme should avoid the use of the character _.

Proposed Format

The following is the general format of the resource string:

domain::resource-id

The "Domain" Part

The domain indicates the susbsystem where the resource string apply, and can take on values prn (For Pravega Resource Name) and prn.scheme-registry.

The domain part may be omitted in ACLs. If omitted, it is derived based on the context. For example, / (as opposed to prn::/ or prn::/) denotes the root resource in the respective domains Pravega and Schema Registry.

The "Resource Id" Part

Unlike the domain part, the resource-id part is mandatory. The specific format of the resource id part depends on the resource type. All resource strings follow these common rules:

1. All resource types except the root resource are indicated using corresponding tags.

   prn::/ <--- the root resource
   prn::/scope:myscope <--- a specific scope
   prn::/scope:myscope/stream:mystream <--- a specific stream
   

2. Forward slashes indicate hierarchical relationships. For example, a scope is under the root resource /, and a stream is under a scope. So, a stream mystream in scope myscope is represented as:

   prn/scope:myscope/stream:mystream`
   

3. The following are the supported tags for denoting resource types. Additional tags may be added in the future. Also, as is illustrated below, multiple words are separated using the - character.

   • Pravega: scope, stream, reader-group, key-value-table
   • Schema registry: group, namespace

   Accordingly, a myrg reader group resource is represented as prn::/scope:myscope/reader-group:myrg

See some more examples in the next section.

Examples

Sample Resource Strings in Proposed Format

The table below lists a few examples of resource strings that can be used for making authorization decisions.

Resource type	Resource String Example	Description of the example resource
Root	prn::/	Used for creating and listing root level resources like Scopes
Scope	prn::/scope:MarketData	A Scope with name MarketData
Stream	prn::/scope:MarketData/stream:Prices	A Stream Prices in Scope MarketData
ReaderGroup	prn::/scope:MarketData/reader-group:Prices	A Reader Group PriceChangeCalculator in Scope MarketData
Key Value Table	prn::/scope:MarketData/key-value-table:LatestScriptPrices	A Key Value Table LatestScriptPrices in Scope MarketData
Schema Registry Group	prn.schema-registry::/namespace:mynamespace/group:mygroup	A group mygroup in mynamespace namespace

Sample Resource Patterns That May Be Used in Access Control Entries

The table below shows a few examples of resource patterns that Auth Handler plugin (like the built-in Password Auth Handler) may use in their ACEs, to reference multiple resource instances.

Resource Pattern	What does it reference?
*	All resources in the system
prn::/scope:*	All the Scopes in the system
prn::/scope:MarketData	The MarketData scope
prn::/scope:MarketData/*	All direct and indirect child objects under the MarketData scope.
prn::/scope:MarketData/stream:*	All streams in scope MarketData
prn::/scope:MarketData/stream:str*	All streams with names starting from str
prn::/scope:MarketData/key-value-table:*	All key-value tables (KVT) in scope MarketData
prn::/scope:MarketData/key-value-table:kvt123	A KVT with name kvt123