How to define Ranger policies in UI for non-leaf resource types ?

[#1]

We are creating a new Ranger plugin for Apache HAWQ(incubating) service, which is similar to Postgres DB. We have defined the following resources: DATABASE, SCHEMA, TABLE as a resource hierarchy (schema is a parent of table and database is a parent of schema). All of them are marked as mandatory in service definition JSON, as the same table might exist in different schemas / databases so the parent resource types also serve as a namespace for the leaf types.

This allows us to create a policy such that a user can create any table in a given db/schema (X/Y) by specifying "X" for DATABASE and "Y" for SCHEMA and "*" for TABLE and assign CREATE access-type to the user.

However, how can we define a policy such that a user can create any (or specific) database only ? The Ranger Admin UI requires entries for resource sub-levels (schema and table in this case), so it is not possible to just specify "*" for DATABASE and nothing for schema and table. Removing mandatory designation from SCHEMA / TABLE is not an option either as they are required when working with tables.

The same question applies to SCHEMA resource, we want to be able to specify how users are allowed to interact with schemas. It seems that the policies can only be specified for leaf resources in the resource type hierarchy.

[#2]

@Alexander Denissov

may I know why you need to give authorization to just create database or schema alone?

@Madhan Neethiraj Ping you on this to check if this is possible with current model. Please provide your input.

[#3]

@Alexander Denissov if you would like to restrict users to perform 'create' only on higher level resources (like database/schema), consider using separate permissions - like create-database/create-schema, instead of generic 'create'.

I think the notion of 'optional' resource is not yet defined precisely. Your usecase, of allowing only at higher-level resource, seems to be good candidate to allow optional resources to be empty. This would however require changes in a number of places - like policy-engine, policy-validation, etc. It will help if you can file a JIRA with details.

[#4]

@Ramesh Mani @Madhan Neethiraj @Don Bosco Durai

Our thinking is that if Ranger <--> HAWQ integration is enabled, all traditional privilege checking inside HAWQ that is managed via GRANT statements will be turned off to allow Ranger to be the single source of truth for authorization decisions. That will require that create/connect/usage operations for databases and schemas are authorized by Ranger as well, hence the need to define policies for resources on all levels of the resource hierarchy.

If we use different permissions (like create-database), which resource will we define it on ? We can't define it on the table level.

One hacky way to achieve what we need is to model database / schema twice -- once as a top-level resource without children so that we can define policies on it and once as a parent to serve as context for children.

|-- database

|-- db-parent

___|-- schema

|-- db-parent

___|-- schema-parent

______|-- table

In this way we can still define policies on database / schema / table resource types while being able to provide context for schema and table resources. This will be functional, but very confusing to users, with the first level drop down showing "database" and "db-parent" as options to navigate the further levels of resource hierarchy. So that's why I was wondering if there was an out-of-the-box way for doing so.

[#5 · Accepted solution]

>> If we use different permissions (like create-database), which resource will we define it on ? We can't define it on the table level.

There is no restriction on the permissions that can be specified on a specific resource. Following policies can be used for your usecases. Please review.

1. To permit creation of databases named like testdb*: resource: { database=testdb*; schema=*; table=* }; permission: [ create-database ]

2. To permit creation of schemas under database db1: resource: { database=db1; schema=*; table=* }; permission: [ create-schema ]

3. To permit creation of tables under database=db1; schema=schema1: resource: { database=db1; schema=schema1; table=* }; permission: [ create-table ]

[#6]

Thank you Mahdan, this seems to be a reasonable workaround in the absence of the core feature.