[ https://issues.apache.org/jira/browse/OOZIE-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883443#comment-15883443 ]
Robert Kanter edited comment on OOZIE-2803 at 2/24/17 8:14 PM: --------------------------------------------------------------- +1 I also tried this out in a cluster was (Author: rkanter): +1 > 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, OOZIE-2803-002.patch, > OOZIE-2803-003.patch, OOZIE-2803-004.patch, OOZIE-2803-005.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)