Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

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

avatar
Super Collaborator

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.

1 ACCEPTED SOLUTION

avatar

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.

View solution in original post

1 REPLY 1

avatar

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.