[
https://issues.apache.org/jira/browse/HDFS-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836705#comment-13836705
]
Colin Patrick McCabe commented on HDFS-5569:
--------------------------------------------
Hi Adam,
In order for this to work, you need to distribute an appropriate configuration
XML file to every DataNode and NameNode. This seems to be no more or less
complex than setting an appropriate {{iptables}} configuration file on every
node.
I have mixed feelings about adding something to HDFS that can easily and simply
be done at a lower level. It seems like complexity we don't really need.
It's also worth noting that hostname-based security is also not very secure.
For example, what happens if a bad guy configures his PC to have the IP address
of a good guy? At that point, he has an allowed hostname and can access all
the goodies. If we add explicit support for this kind of security in Hadoop,
people will think that we are endorsing it as secure, which it is manifestly
not.
My recommendation, for what it's worth, is to set up Kerberos and appropriate
firewalls, to achieve real security.
> 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)
