sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Krugler (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SQOOP-335) Support custom class to provide passwords on slaves
Date Fri, 09 Sep 2011 22:02:09 GMT
Support custom class to provide passwords on slaves

                 Key: SQOOP-335
                 URL: https://issues.apache.org/jira/browse/SQOOP-335
             Project: Sqoop
          Issue Type: New Feature
    Affects Versions: 1.4.0
            Reporter: Ken Krugler

In highly secure environments, any transmission of passwords in the clear creates security
audit issues. 

https://issues.cloudera.org/browse/SQOOP-145 tries to address this via putting passwords in
files, but the file itself still winds up getting transmitted in the clear as it is written
to HDFS. And passwords are dynamic, provided at run-time via other infrastructure - so the
file would need to be generated with each job run.

For situations where mechanisms exist to provide restricted/secure access to passwords, what's
needed is a plug-in approach - a "password manager" class that is available on all the servers,
and is used by Sqoop. E.g. --password-manager <class> similar to --compression-codec
<class>. An optional --password-param <string> would also be handy (see below).

The class would need a no-argument constructor, and a getPassword(context, param) call. In
the context should be all of the connection information (host, port, etc). The param is whatever
was specified by --password-param, or null.

This would satisfy all of our requirements for flexibility, security, and integration with
existing security systems.

I assume that any jar found in $SQOOP_HOME/lib will be available on the classpath, so that
would be the preferred method for making the password manager class available everywhere.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message