[
https://issues.apache.org/jira/browse/HDFS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417245#comment-13417245
]
Aaron T. Myers commented on HDFS-2617:
--------------------------------------
bq. Have you tested HsftpFileSystem too? Do we even support encrypting the
transfer data if spnego is enabled?
No I didn't, but you make a good point. Thoughts on what to do here? Perhaps we
should disallow use of Hsftp if SSL (either KSSL or cert-based) isn't enabled?
bq. The addition of useKssl(conf) seems rather invasive in the sense that many
callers have to be modified to specifically have knowledge of kssl.
It's really not all that many callers. Maybe we can cut down on a few, but it's
going to go from like 10 to 7, or something.
bq. A simple boolean complicates the ability to add new auth systems in the
future.
I'm skeptical that we'll be adding more HTTP auth systems to branch-1, so I'm
hesitant to build up a generic system for something that will only have two
actual options.
bq. SecurityUtil.openSecureHttpConnection swaps out the https scheme with http
if kssl is not enabled. Negates a bunch of changes in HftpFileSystem and
DelegationTokenFetcher.
The reason I didn't do this is because use of KSSL is only within HDFS, whereas
SecurityUtil is in Common, and I didn't want to add a dependency on HDFS to
Common. That said, it might be reasonable to move the dfs.use.kssl.auth key to
Common, change it to "hadoop.security.use.kssl.auth", and then move the
NameNode#useKsslAuth method to SecurityUtil itself. How does this sound?
bq. Add a NameNode.getSecurePort(conf) that can use kssl to determine if the
https or http port should be returned, HftpFileSystem could use this for the
default secure port to be agnostic to kssl.
Seems like a good idea.
bq. Maybe add an arg to the ctor of HttpServer for the auth filter, or add a
setter for the auth filter so addInternalServlet and the many calls to it don't
need to be modified.
I don't think this is reasonable since a single HttpServer might very well have
individual servlets that have different auth filter requirements.
bq. The initialization of a secure HttpServer in places such as the NN and 2NN
seem virtually identical, maybe create a common method? Would centralize one of
the main kssl checks.
I'll take a look at options for refactoring this, but I honestly don't think
there's a lot of code that can be shared, or any new method that would be added
would have to be heavily parameterized for just two call sites.
bq. A few places appear to assume that if kssl is off, that the connection must
be spnego w/o even checking if security is enabled.
Can you point them out specifically?
> Replaced Kerberized SSL for image transfer and fsck with SPNEGO-based solution
> ------------------------------------------------------------------------------
>
> Key: HDFS-2617
> URL: https://issues.apache.org/jira/browse/HDFS-2617
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: security
> Reporter: Jakob Homan
> Assignee: Jakob Homan
> Fix For: 2.1.0-alpha
>
> Attachments: HDFS-2617-a.patch, HDFS-2617-b.patch,
> HDFS-2617-branch-1.patch, HDFS-2617-config.patch, HDFS-2617-trunk.patch,
> HDFS-2617-trunk.patch, HDFS-2617-trunk.patch, HDFS-2617-trunk.patch,
> hdfs-2617-1.1.patch
>
>
> The current approach to secure and authenticate nn web services is based on
> Kerberized SSL and was developed when a SPNEGO solution wasn't available. Now
> that we have one, we can get rid of the non-standard KSSL and use SPNEGO
> throughout. This will simplify setup and configuration. Also, Kerberized
> SSL is a non-standard approach with its own quirks and dark corners
> (HDFS-2386).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
