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
