Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

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

Solved Go to solution

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

Expert Contributor

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

Accepted Solutions

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

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.

1 REPLY 1

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

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.

Don't have an account?
Coming from Hortonworks? Activate your account here