You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Roshan Naik (JIRA)" <ji...@apache.org> on 2014/08/06 01:17:12 UTC

[jira] [Created] (FLUME-2442) Need an alternative to providing clear text passwords in flume config

Roshan Naik created FLUME-2442:
----------------------------------

             Summary: Need an alternative to providing clear text passwords in flume config
                 Key: FLUME-2442
                 URL: https://issues.apache.org/jira/browse/FLUME-2442
             Project: Flume
          Issue Type: Bug
          Components: Sinks+Sources
    Affects Versions: v1.5.0.1
            Reporter: Roshan Naik
            Assignee: Roshan Naik


For some sources and sinks, currently, passwords to keystores/other are specified in clear text in the flume config file.   Since flume config files are often easily accessible to a broader audience (like in source control for instance), the visibility of these passwords can be too much and risky for institutions where security is too critical (like banks) 

To help address this visibility issue it would be desirable to do the following two things :

1) Store the password in a separate file and provide the path of that password file in the flume config. this will enable the flume config to be shared with a wider audience and reduce risk. the password file will need to be very tightly guarded. Some components like file channel & JMS source already do this. 

2) As an additional measure, obfuscate the password in the external password file. A simple command line tool can be used to generate the obfuscated password file. Flume source/sink configuration will read the password file and de-obfuscate the password before using it to access the keystore. This obfuscation step IMO is nice but unclear to me if it is essential.


The following Sources and Sinks appear to use inline cleartext passwords:
- Avro Source
- Avro sink
- HTTP(S) source 

JDBC channel also uses inline passwords but i am not aware of anybody who uses JDBC channel. So it may not be an issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)