Authorization allows users to enforce fine-grained access control on CDAP entities: namespaces, artifacts, applications, programs, datasets, streams, and secure keys. All operations on these entities, listing, viewing, creating, updating, managing, deleting, are governed by authorization policies.
Differences Between New and Old Model
CDAP has migrated to the new auth model in 4.3 and old auth model will not work. The detailed new authorization policy can be checked above.
In general, this summarizes the authorization policies change in CDAP:
No hierarchical authorization enforcement is supported, which means having a privilege on an entity's parent does not give that privilege on the entity. For example, having READ on the namespace does not give READ to the datasets and streams in the namespace.
No authorization bootstrap, no privileges on instance and no admin users. The new model removes the requirement of privileges on CDAP instance and admin users. Each privilege needs to be pre-granted to create the entity either through CDAP CLI or through an external interface of the supported authorization extension.
Automatic grant on entity creation and automatic revoke on entity deletion are removed. It is the responsibility of the administrator to create and delete privileges.
Authorization Policy Pushdown
Currently, CDAP does not support the pushing of authorization policy grants and revokes to storage providers. As a result, when a user is granted READ or WRITE access on existing datasets or streams, permissions are not updated in the storage providers. The same applies when authorization policies are revoked.
A newly-applied authorization policy will be enforced when the dataset or stream is accessed from CDAP, but not when it is accessed directly in the storage provider. If the pushdown of permissions to storage providers is desired, it needs to be done manually. This will be done automatically in a future release of CDAP.
This limitation has a larger implication when Cross-namespace Dataset Access is used. When accessing a dataset from a different namespace, CDAP currently presumes that the user accessing the dataset has been granted permissions on the dataset in the storage provider prior to accessing the dataset from CDAP.
For example, if a program in the namespace ns1 tries to access a fileset in the namespace ns2, the user running the program should be granted the appropriate (READ, WRITE, or both) privileges on the fileset. Additionally, the user needs to be granted appropriate permissions on the HDFS directory that the fileset points to. When impersonation is used in the program's namespace, this user is the impersonated user, otherwise it is the user that the CDAP Master runs as.