Overview

TBD

Highlights of the Auth policy

• Pluggable authorization backend

• Supports granular privileges at individual entity level

• Privileges on each entity are evaluated independently

• Privileges are not hierarchical

• Supports wildcard privileges for simpler privilege management

• Only admins of the authorization backend can do grants

Brief overview of the auth policy

Supported privileges - READ, WRITE, EXECUTE, ADMIN

Create or deploy or delete an entity - ADMIN on the entity

Read from a dataset or stream or secure key - READ on the entity

Write to a dataset or stream or secure key - WRITE on the entity

Execute a program - EXECUTE on the program

Deploy an app that runs impersonating another user - ADMIN on the principal

Get information (need a good term) on an entity - any privilege on the entity

For an entity to be visible to an user - any privilege on the entity or its descendants

Give a link to the auth matrix here

Misc usage notes

Explain Wildcards etc.

We can discuss -

• what wildcard privileges are required to make someone an admin on all entities in a namespace, etc

• wildcard privileges required to give someone execute on all programs in an app

Sentry integration

Grant revoke list commands for Sentry along with entity formats and wildcards (* and ?)

Talk about roles, groups, how to assign privileges etc. here

Sentry property to update to add an admin, etc.

After any update to privileges, user/group wait for 15 mins (depends on cache timeout)

Differences between 4.2 and 4.3

• No hierarchy

• No instance admin, no privileges on instance

• No auto-grants to entity creator

• Pre-grants on entity required to create entities

Migrating from 4.2 to 4.3

• Come up with the new authorization model for your CDAP instance since the old one will not work anymore.

• Upgrade from 4.2 to 4.3

• After CDAP has started up run the following command (needs cleanup) to drop the old roles (note the auth token should be of the sentry admin for dropping roles)

$ for role in curl -v "http://<hostname>:11015/v3//security/authorization/roles" -H "Authorization: Bearer AghjZGFwANzsmf3CV9zczM/DV87Xqs4HQAycFxjjL1owXSdbprQxJExjL3tscVI9+FaDQ4cmTGGu" | python -m json.tool | fgrep '"name": ".' | cut -f 4 -d '"'; do curl -H "Authorization: Bearer AghjZGFwANzsmf3CV9zczM/DV87Xqs4HQAycFxjjL1owXSdbprQxJExjL3tscVI9+FaDQ4cmTGGu" "http://<hostname>:11015/v3//security/authorization/roles/$role" -X DELETE; done

• Grant the new privileges

Auth matrix

TBD

Debugging (internal)

• Understand the auth model of the user, and figure out what privileges are present and what should be given

• Wait for (cache timeout * 2) + 1 seconds after any change to privileges or user/group for it to take effect

• Enable TRACE logging on class co.cask.cdap.security.authorization.sentry.binding.SentryAuthorizer. This should tell what policies are being used for what enforcement