Page tree
Skip to end of metadata
Go to start of metadata
Following are the core policies that the authorization module follows. Detailed policies for entities are listed in the table after that. For new entities and entities not listed here, these core policies should be followed.
  1. Create needs a WRITE on the parent
  2. Delete needs an ADMIN on the entity
  3. Delete all deletes all entities the user has privileges for and shows errors for the ones not deleted.
  4. List needs a READ/WRITE/ADMIN on the entity.
  5. Get needs a READ  on the entity and READ on the parent.
  6. Setting preferences needs WRITE on the entity
  7. Getting preferences needs READ on the entity
  8. Update needs ADMIN on the entity
  9. Adding metadata needs ADMIN on the entity
  10. Reading metadata needs READ on the entity




EntityOperationRequired PrivilegesResultant PrivilegesNotes
NamespacecreateWRITE (Instance)ALL (Namespace) 
 updateADMIN (Namespace)  
 listREAD/WRITE/ADMIN (Namespace) Listing will list all the namespaces, even if the current user does not have access to it.
 getREAD (Namespace)  
 deleteADMIN (Namespace)  
 set preferenceWRITE (Namespace)  
 get preferenceREAD (Namespace)  
 searchREAD (Namespace)  
ArtifactaddWRITE (Namespace)ALL (Artifact) 
 deleteADMIN (Artifact)  
 getREAD (Artifact)  
 listREAD/WRITE/ADMIN (Artifact)  
 write propertyADMIN (Artifact)  
 delete propertyADMIN (Artifact)  
 get propertyREAD (Artifact)  
 write metadataADMIN (Artifact)  
 read metadataREAD (Artifact)  

WRITE (Namespace)

READ(Artifact if deployed from an artifact)

ALL (Application) 
 getREAD (Application)  
 listREAD/WRITE/ADMIN (Application)  
 updateADMIN (Application)  
 deleteADMIN (Application)  
 set preferenceWRITE (Application)  
 get preferenceREAD (Application)  
 add metadataADMIN (Application)  
 get metadataREAD (Application)  

EXECUTE (Program)

READ (Namespace)

 set instancesADMIN (Program)  
 listREAD/WRITE/ADMIN (Program)  
 set runtime argsADMIN (Program)  
 get runtime argsREAD (Program)  
 get instancesREAD (Program)  
 set preferenceWRITE (Program)  
 get preferenceREAD (Program)  
 get statusREAD (Program)  
 get historyREAD (Program)  
 add metadataADMIN (Program)  
 get metadataREAD (Program)  
 emit logsWRITE (question) (Namespace)  
 view logsREAD (Program)  
 emit metricsWRITE (question) (Namespace)  
 view metricsREAD (Program)  
StreamscreateWRITE (Namespace)ALL (Stream) 
 update propertiesADMIN (Stream)  
 deleteADMIN (Stream)  
 truncateADMIN (Stream)  

WRITE (Stream)

READ (Namespace)


READ (Stream)

READ (Namespace)

 listREAD/WRITE/ADMIN (Streams)  
 read events

READ (Stream)

READ (Namespace)

 set preferencesWRITE (Stream)  
 get preferencesREAD (Stream)  
 add metadataADMIN (Stream)  
 get metadataREAD (Stream)  
 view lineageREAD (Stream)  
 emit metricsWRITE (question) (Namespace)  
 view metricsREAD (Stream)  
DatasetscreateWRITE (Namespace)ALL (Dataset) 

READ (Dataset)


 listREAD/WRITE/ADMIN (Datasets)  

ADMIN (Dataset)


 dropADMIN (Dataset)  
 truncateADMIN (Dataset)  
 upgradeADMIN (Dataset)  
 add metadataADMIN (Dataset)  
 get metadataREAD (Dataset)  
 view lineageREAD (Dataset)  
 emit metricsWRITE (question) (Namespace)  
 view metricsREAD (Dataset)  
  • No labels


  1. List needs a READ on the parent. It lists all entities even if the user has no privilege on the entity, as long as they have read on the parent.

    This seems contrary to the original requirement: When you go to a page in CDAP, you should only those entities that you have access to. This was a specific requirement that may have come from customers. It would be good to confirm before changing this.

    1. Also, even if we end up making this change, can I not list something if I have WRITE or ADMIN on the parent?

    2. Yes that's the one I wanted feedback on. I was trying to follow filesystem permissions but I remember discussing this requirement earlier. Although with hierarchical privileges that would be interesting.

      1. To me, hierarchical privileges applies in the scenario where having a READ/WRITE/ADMIN on a parent would give you a READ/WRITE/ADMIN on its children. It shouldn't apply for listing. Thoughts?

  2. For the sake of completion, it would be good to mention the policies for metrics, logs, search. Also for the monitor (system services) APIs.

  3. Get needs a READ  on the entity

    This seems wrong. So if I have WRITE or ADMIN on an entity, I wouldn't be able to view it on the UI?

    1. Should you be able to view the details if you only have admin or write?

      1. I think so. However, you shouldn't be able to read the data.