[
https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459552#comment-13459552
]
Steve Loughran commented on WHIRR-642:
--------------------------------------
I've seen this too. It's dangerous as output can get shared around -that key
will leak, and as it's in a vast amount of log noise you may not even notice
that you've emailed it or attached it to a bug report.
Here's a full example:
{code}
Cluster{instances=[Instance{roles=[hadoop-datanode, hadoop-tasktracker],
publicIp=54.245.15.109, privateIp=10.248.9.130, id=us-west-2/i-ade1989e,
nodeMetadata={id=us-west-2/i-ade1989e, providerId=i-ade1989e,
name=hdp1-ade1989e, location={scope=ZONE, id=us-west-2a,
description=us-west-2a, parent=us-west-2, iso3166Codes=[US-OR]}, group=hdp1,
imageId=us-west-2/ami-3659d706, os={family=unrecognized, arch=paravirtual,
version=, description=597934776782/HDP node, is64Bit=true},
status=RUNNING[running], loginPort=22, hostname=ip-10-248-9-130,
privateAddresses=[10.248.9.130], publicAddresses=[54.245.15.109],
hardware={id=t1.micro, providerId=t1.micro, processors=[{cores=1.0,
speed=1.0}], ram=630, volumes=[{id=vol-f6a8d6d0, type=SAN, device=/dev/sda1,
bootDevice=true, durable=true}], hypervisor=xen,
supportsImage=And(requiresRootDeviceType(ebs),Or(isWindows(),requiresVirtualizationType(paravirtual)),ALWAYS_TRUE,ALWAYS_TRUE)},
loginUser=ec2-user, userMetadata={Name=hdp1-ade1989e}}},
Instance{roles=[hadoop-namenode, hadoop-jobtracker, hadoop-datanode,
hadoop-tasktracker], publicIp=54.245.21.13, privateIp=10.252.48.78,
id=us-west-2/i-93e198a0, nodeMetadata={id=us-west-2/i-93e198a0,
providerId=i-93e198a0, name=hdp1-93e198a0, location={scope=ZONE, id=us-west-2b,
description=us-west-2b, parent=us-west-2, iso3166Codes=[US-OR]}, group=hdp1,
imageId=us-west-2/ami-3659d706, os={family=unrecognized, arch=paravirtual,
version=, description=597934776782/HDP node, is64Bit=true},
status=RUNNING[running], loginPort=22, hostname=ip-10-252-48-78,
privateAddresses=[10.252.48.78], publicAddresses=[54.245.21.13],
hardware={id=t1.micro, providerId=t1.micro, processors=[{cores=1.0,
speed=1.0}], ram=630, volumes=[{id=vol-f5a8d6d3, type=SAN, device=/dev/sda1,
bootDevice=true, durable=true}], hypervisor=xen,
supportsImage=And(requiresRootDeviceType(ebs),Or(isWindows(),requiresVirtualizationType(paravirtual)),ALWAYS_TRUE,ALWAYS_TRUE)},
loginUser=ec2-user, userMetadata={Name=hdp1-93e198a0}}}],
configuration={hadoop.job.ugi=root,root,
mapred.job.tracker=ec2-54-245-21-13.us-west-2.compute.amazonaws.com:8021,
hadoop.socks.server=localhost:6666, fs.s3n.awsAccessKeyId=ACCESS_KEY_HERE
dfs.client.use.legacy.blockreader=true,
fs.s3.awsSecretAccessKey=SECRET_KEY_HERE, fs.s3.awsAccessKeyId=ACCESS_KEY_HERE,
hadoop.rpc.socket.factory.class.default=org.apache.hadoop.net.SocksSocketFactory,
fs.default.name=hdfs://ec2-54-245-21-13.us-west-2.compute.amazonaws.com:8020/,
fs.s3n.awsSecretAccessKey=SECRET_KEY_HERE}
{code}
the root cause is that {{Cluster.toString()}} prints out the entire
configuration, which includes all these secrets.
I propose stripping that line out, so the configuration does not get printed. I
don't see end users gaining anything from this -all that happens is a security
risk arises.
> Whirr writes the AWS Secret key to the stdout. is it an unforeseen byproduct
> or intended behavior?
> --------------------------------------------------------------------------------------------------
>
> Key: WHIRR-642
> URL: https://issues.apache.org/jira/browse/WHIRR-642
> Project: Whirr
> Issue Type: Bug
> Components: cli
> Affects Versions: 0.7.1
> Environment: OSX Mountain Lion
> Reporter: P Mohan
> Priority: Minor
>
> I used Whirr to launch a CDH cluster. Towards the end the whirr output has
> the AWS secret key in plain text as shown below.
> fs.s3.awsSecretAccessKey=qBqa*********************************, fs.s3.a
> wsAccessKeyId=AKIA*****************,
> hadoop.rpc.socket.factory.class.default=org.apache.hadoop.net.SocksSocketFactory,
> fs.default.name=hdfs://ec2-**********.compute-1.amazonaws.c
> om:8020/, fs.s3n.awsSecretAccessKey=qBqaott5*************************}}
> is this intended behavior. Would it be not better to mask or not print the
> AWS Secret key to the stdout.
> One gd thing i noticed is that the AWS Secret Key is not written to the
> whirr.log file. Can we not have the same behavior for the stdout as well ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
