Amandeep Khurana wrote:
On Wed, Mar 25, 2009 at 12:23 PM, Kan Zhang <k...@yahoo-inc.com> wrote:
On 3/25/09 2:49 AM, "Doug Cutting" <cutt...@apache.org> wrote:
2. The Jira doesnt have cover the access control aspect of things. As a
client, I can skip talking to the NN and get blocks from the DN straight
away. There is no way to prevent it. This paper takes care of that
aspect as
well.
The intent is that access to a block on a datanode will require
authentication. Currently it does not, but as security features are
added this clearly must change. HADOOP-4343 does not mention how this
will be done, but I believe it must be implemented in the same timeframe
as namenode authentication.
We plan to use capability tokens issued by NN to control accesses to DN
(see
HADOOP-4359). If DN authenticates users, those capability tokens can be
made
non-transferable. This will improve security since stolen tokens can't be
used by the attacker. Another benefit of having authentication is to be
able
to establish an encrypted communication channel afterwards (if the
authentication protocol used supports it). However, I think DN user
authentication may not be necessary for many use cases and can be addressed
after NN authentication is done.
Got it. There is no user authentication at the DN. I'm not sure why you got
that impression. Authentication is done only once by the NN. Thereafter its
only capabilities being passed around. However, there are 2 main
differences:
1. You plan to use symmetric key and I proposed asymmetric key.
2. The authentation protocol you plan to use is Kerberos and I dont think
thats scalable. Hence a different one that my paper talks about.
Brian's points about x509 integration are relevant -they are people who
have to worry about trust.
There's a separate issue bubbling up here and that is US government
export rules regarding encryption and the like. Apache has to deal with
that already, and has a page covering the status:
http://www.apache.org/licenses/exports/
generally, if you use jsch or the bouncy castle implementations of JSSE
then it's not your project's problem. Building security and encryption
support more directly into the app is something that needs to be looked
at very carefully. It's where legal issues take priority over coding ones.
