[jira] [Updated] (OOZIE-2803) Mask passwords when printing out configs/args in MapReduceMain and SparkMain

["Peter Bacsko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OOZIE-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Bacsko updated OOZIE-2803:
--------------------------------
    Attachment: OOZIE-2803-001.patch

> Mask passwords when printing out configs/args in MapReduceMain and SparkMain
> ----------------------------------------------------------------------------
>
>                 Key: OOZIE-2803
>                 URL: https://issues.apache.org/jira/browse/OOZIE-2803
>             Project: Oozie
>          Issue Type: Bug
>          Components: action
>            Reporter: Peter Bacsko
>            Assignee: Peter Bacsko
>            Priority: Critical
>         Attachments: OOZIE-2803-001.patch
>
>
> Sometimes passwords are displayed in both MapReduce and Spark action.
> *MapReduce*: when using {{HADOOP_CREDSTORE_PASSWORD}}, it must be passed to some Hadoop-specific config values, like {{mapred.child.env}}. This is easy to fix because we already have a method {{logMasking()}} where you can define a {{maskSet}} which contains a list of property keys to be masked.
> Note that this is not necessarily the perfect solution, since you can pass multiple env. vars separated by a colon, and only the password specific parts should be masked. But we need a working solution relatively quickly - later we can enhance this, eg. we can re-use {{PasswordMasker}} in some way (right now it only works with {{Map<String, String>}}).
> *Spark*:  for Spark, we have to pass passwords like this:
> {{--conf spark.executorEnv.HADOOP_CREDSTORE_PASSWORD=<custom keystore password>}}
> The Spark arguments are printed in {{SparkMain.run()}}. There is already a code in {{LauncherMapper.printArgs()}} which deals with situations like this, but it's not perfect because it only works if the args look something like {{--password pwd123}}. So if a single arg contains a password, it doesn't work, therefore we need a different approach here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)