You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whirr.apache.org by "P Mohan (JIRA)" <ji...@apache.org> on 2012/08/22 01:36:38 UTC
[jira] [Created] (WHIRR-642) Whirr writes the AWS Secret key to the
stdout. is it an unforeseen byproduct or intended behavior?
P Mohan created WHIRR-642:
-----------------------------
Summary: 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 stdin.
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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459557#comment-13459557 ]
Steve Loughran commented on WHIRR-642:
--------------------------------------
if you search for {{fs.s3.awsSecretAccessKey}} you do find places where it has been unintentionally published, showing that this a real security issue
> 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
>
> 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
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Andrew Bayer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461883#comment-13461883 ]
Andrew Bayer commented on WHIRR-642:
------------------------------------
0.8 branch is looking good, though I think we should bump jclouds to 1.5.0 release too.
> 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, 0.9.0
> Environment: OSX Mountain Lion
> Reporter: P Mohan
> Assignee: Steve Loughran
> Fix For: 0.8.1
>
> Attachments: whirr-642.diff
>
>
> 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
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462658#comment-13462658 ]
Tom White commented on WHIRR-642:
---------------------------------
Great! BTW jclouds is on 1.5.0 in trunk and 0.8 after WHIRR-659.
> 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, 0.9.0
> Environment: OSX Mountain Lion
> Reporter: P Mohan
> Assignee: Steve Loughran
> Fix For: 0.8.1
>
> Attachments: whirr-642.diff
>
>
> 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
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (WHIRR-642) Whirr writes the AWS Secret key to the
stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Loughran updated WHIRR-642:
---------------------------------
Priority: Major (was: Minor)
uprating to major as this is a security issue
> 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
>
> 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
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461728#comment-13461728 ]
Tom White commented on WHIRR-642:
---------------------------------
Steve - I just pushed this to branch-0.7 too.
I think we should do a release soon. Andrew said he was testing the 0.8 branch, so once we get a good test run we should roll a RC.
> 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, 0.9.0
> Environment: OSX Mountain Lion
> Reporter: P Mohan
> Assignee: Steve Loughran
> Fix For: 0.8.1
>
> Attachments: whirr-642.diff
>
>
> 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
[jira] [Updated] (WHIRR-642) Whirr writes the AWS Secret key to the
stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Loughran updated WHIRR-642:
---------------------------------
Attachment: whirr-642.diff
This patch omits the configuration dump and so keeps secrets secret:
{code}
Started cluster of 2 instances
Cluster{instances=[Instance{roles=[hadoop-datanode, hadoop-tasktracker], publicIp=54.245.30.157, privateIp=10.252.34.203, id=us-west-2/i-79d3aa4a, nodeMetadata={id=us-west-2/i-79d3aa4a, providerId=i-79d3aa4a, name=hdp1-79d3aa4a, 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-34-203, privateAddresses=[10.252.34.203], publicAddresses=[54.245.30.157], hardware={id=t1.micro, providerId=t1.micro, processors=[{cores=1.0, speed=1.0}], ram=630, volumes=[{id=vol-c999e7ef, 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-79d3aa4a}}}, Instance{roles=[hadoop-namenode, hadoop-jobtracker, hadoop-datanode, hadoop-tasktracker], publicIp=50.112.35.185, privateIp=10.252.48.62, id=us-west-2/i-63d3aa50, nodeMetadata={id=us-west-2/i-63d3aa50, providerId=i-63d3aa50, name=hdp1-63d3aa50, 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-62, privateAddresses=[10.252.48.62], publicAddresses=[50.112.35.185], hardware={id=t1.micro, providerId=t1.micro, processors=[{cores=1.0, speed=1.0}], ram=630, volumes=[{id=vol-d499e7f2, 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-63d3aa50}}}]}
{code}
> 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
> Attachments: whirr-642.diff
>
>
> 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
[jira] [Commented] (WHIRR-642) Whirr writes the AWS Secret key to
the stdout. is it an unforeseen byproduct or intended behavior?
Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461390#comment-13461390 ]
Steve Loughran commented on WHIRR-642:
--------------------------------------
thanks -though it could also go into any other supported branches (e.g. 0.7.x), as its low-risk and important.
> 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, 0.9.0
> Environment: OSX Mountain Lion
> Reporter: P Mohan
> Assignee: Steve Loughran
> Fix For: 0.8.1
>
> Attachments: whirr-642.diff
>
>
> 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
[jira] [Updated] (WHIRR-642) Whirr writes the AWS Secret key to the
stdout. is it an unforeseen byproduct or intended behavior?
Posted by "P Mohan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
P Mohan updated WHIRR-642:
--------------------------
Description:
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 ?
was:
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 stdin.
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 ?
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira