The problem I am trying to solve here is not to secure an output, but to provide the ability to only display an output to an end user one time.
>So it seems that the problem you are seeking to solve is limiting access >to sensitive outputs. The solution mentioned above certainly narrows >the attack surface, but it suffers from a DOS race condition where a >bad actor can lock you out of your own resource. Also, if an attacker is able to authenticate as your account, you have much bigger problems than them locking you out of an output. Thanks. -Andrew ________________________________________ From: Clint Byrum [cl...@fewbar.com] Sent: Wednesday, November 06, 2013 8:36 PM To: openstack Subject: Re: [Openstack] [Heat] Locked Outputs Excerpts from Andrew Plunk's message of 2013-11-07 06:48:33 +0800: > Hello All, > > Imagine for a minute that you are displaying outputs from heat, but some of > those outputs could have sensitive data (think passwords or private keys). It > would be beneficial to allow outputs to be accessed once, and then go into a > locked state. This could result in the following: > This is an interesting concept. I'd like to start with a problem statement though, as it is not clear what this is meant to solve. > 1). After an output is accessed for the first time, the output will become > locked, and subsequent calls to the engine to return that output will return > nothing. > example: > >show stack > > "outputs": { > "password": "password" > } > > >show stack > > "outputs": { > } > > > 2). Another option is after an output is accessed for the first time, the > output will become locked, and subsequent calls to the engine will return the > output with a flag saying that this output has been locked, allowing whatever > is consuming that output to take the necessary action. > example: > > >show stack > > "outputs": { > "password": { > "value": "password", > "locked": false > } > } > > >show stack > > "outputs": { > "password": { > "value": "password", > "locked": true > } > } > > > The outputs section of the template for either case would could look like: > outputs: > password: > value: { get_attr: [ some_resource, some_value ] } > description: The password > view_once: True > So it seems that the problem you are seeking to solve is limiting access to sensitive outputs. The solution mentioned above certainly narrows the attack surface, but it suffers from a DOS race condition where a bad actor can lock you out of your own resource. I have a different idea for that, which is to encrypt the output using public key cryptography. heat stack-create -f mytemplate.yaml -P PasswordRecipientKey="$(gpg --armor --print-key m...@foo.com)" And then have an output type of "Encrypted" Outputs: Password: Type: Encrypted Keys: - {Ref: PasswordRecipientKey} Now you can simply decrypt this with your local gpg key. heatclient could even automatically do this for you making it transparent as long as you have a gpg key agent running. _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack