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
Highlighted

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
Highlighted

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.

View solution in original post

1 REPLY 1
Highlighted

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.

View solution in original post

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