[ 
https://issues.apache.org/jira/browse/HDFS-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837315#comment-13837315
 ] 

Alejandro Abdelnur commented on HDFS-5569:
------------------------------------------

Adam,

Regarding Kerberos, I meant you could restrict to which subnets the KDC is 
avail, then clients could get TGT from those subnets. Granted, not much fine 
grain control.

On the reverse DNS lookup, with WebHDFS this will have to be done in ALL node 
of the cluster as well (all DNs), and for every HTTP request. Yes caching may 
help, but config wise is not a couple of machines but all nodes.

A twist to Haohui's suggestion of a proxy. Instead using HDFS WebHdfs you could 
use HttpFS. HttpFS implements the WebHfds HTTP API, but it run fully contained 
in a Tomcat server. You don't need to expose the whole cluster to the clients, 
just the box were Tomcat runs. And, AFAIK, Tomcat support via configuration 
allow/deny. HttpFS is part of Hadoop 2, so it is there already.


> WebHDFS should support a deny/allow list for data access
> --------------------------------------------------------
>
>                 Key: HDFS-5569
>                 URL: https://issues.apache.org/jira/browse/HDFS-5569
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: webhdfs
>            Reporter: Adam Faris
>              Labels: features
>
> Currently we can't restrict what networks are allowed to transfer data using 
> WebHDFS.  Obviously we can use firewalls to block ports, but this can be 
> complicated and problematic to maintain.  Additionally, because all the jetty 
> servlets run inside the same container, blocking access to jetty to prevent 
> WebHDFS transfers also blocks the other servlets running inside that same 
> jetty container.
> I am requesting a deny/allow feature be added to WebHDFS.  This is already 
> done with the Apache HTTPD server, and is what I'd like to see the deny/allow 
> list modeled after.   Thanks.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to