Support for nested group / cascading group in access control list (ACLs).

[#1]

Every time a new group in a organization needs access control, hdfs service needs to go through configuration change and service restart. This could be avoided by supporting cascading groups and onus will be on SysAdmins managing AD / LDAP.

[#2 · Accepted solution]

Does this question refer to Hadoop Service Level Authorization?

http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-common/ServiceLevelAuth.html

If so, then there is no need to restart the NameNode to make changes in service-level ACLs take effect. Instead, an admin can run this command:

hdfs dfsadmin -refreshServiceAcl

More documentation on this command is available here:

http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#dfsadmin

There is similar functionality for YARN too:

http://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-site/YarnCommands.html#rmadmin

Another way to manage this is to declare a single "hadoopaccess" group for use in the service-level ACL definitions. Whenever a new set of users needs access, they would be added to this group. This shifts the management effort to an AD/LDAP administrator. Different IT shops would likely make a different trade-off between managing it that way or managing it in the service-level authorization policy files. Both approaches are valid, and it depends on the operator's preference.