Whirr
  1. Whirr
  2. WHIRR-642

Whirr writes the AWS Secret key to the stdout. is it an unforeseen byproduct or intended behavior?

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.7.1, 0.9.0
    • Fix Version/s: 0.8.1
    • Component/s: cli
    • Labels:
      None
    • Environment:

      OSX Mountain Lion

      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 ?

      1. whirr-642.diff
        0.8 kB
        Steve Loughran

        Activity

        Hide
        Steve Loughran added a comment -

        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:

        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}
        

        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.

        Show
        Steve Loughran added a comment - 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: 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} 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.
        Hide
        Steve Loughran added a comment -

        uprating to major as this is a security issue

        Show
        Steve Loughran added a comment - uprating to major as this is a security issue
        Hide
        Steve Loughran added a comment -

        if you search for fs.s3.awsSecretAccessKey you do find places where it has been unintentionally published, showing that this a real security issue

        Show
        Steve Loughran added a comment - if you search for fs.s3.awsSecretAccessKey you do find places where it has been unintentionally published, showing that this a real security issue
        Hide
        Steve Loughran added a comment -

        This patch omits the configuration dump and so keeps secrets secret:

        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}}}]}
        
        
        
        Show
        Steve Loughran added a comment - This patch omits the configuration dump and so keeps secrets secret: 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}}}]}
        Hide
        Tom White added a comment -

        I just committed this. Thanks Steve!

        Show
        Tom White added a comment - I just committed this. Thanks Steve!
        Hide
        Steve Loughran added a comment -

        thanks -though it could also go into any other supported branches (e.g. 0.7.x), as its low-risk and important.

        Show
        Steve Loughran added a comment - thanks -though it could also go into any other supported branches (e.g. 0.7.x), as its low-risk and important.
        Hide
        Tom White added a comment -

        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.

        Show
        Tom White added a comment - 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.
        Hide
        Andrew Bayer added a comment -

        0.8 branch is looking good, though I think we should bump jclouds to 1.5.0 release too.

        Show
        Andrew Bayer added a comment - 0.8 branch is looking good, though I think we should bump jclouds to 1.5.0 release too.
        Hide
        Tom White added a comment -

        Great! BTW jclouds is on 1.5.0 in trunk and 0.8 after WHIRR-659.

        Show
        Tom White added a comment - Great! BTW jclouds is on 1.5.0 in trunk and 0.8 after WHIRR-659 .

          People

          • Assignee:
            Steve Loughran
            Reporter:
            P Mohan
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development