<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>(sorry for the double-post Steve)</div>
<div><br>
</div>
<div><span style="font-family: monospace; ">I agree with Steve here. Clint's suggestion is good, but wouldn't it prevent the practical use of that value inside the orchestration itself? Also, how would I use that method for outputs that are generated from attributes?
I think we can do something similar to what we do for parameters and allow outputs to be tagged as "hidden". That way, those values would be masked for normal stack-show, resource-show, etc. Then we add a new api call to get the unmasked value of an output;
something like: </span><br style="font-family: monospace; ">
<br style="font-family: monospace; ">
<span style="font-family: monospace; ">/stacks/{stack_name}/{stack_id}/outputs/{output_key}/value?unmask=true</span><br style="font-family: monospace; ">
<br style="font-family: monospace; ">
<span style="font-family: monospace; ">Instead of the query param, we could also simply say that by convention, when the output value is requested this way, its always unmasked).</span></div>
<br>
<div>
<div>On Nov 10, 2013, at 2:35 PM, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On 11/08/2013 06:07 AM, Andrew Plunk wrote:<br>
<blockquote type="cite">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.<br>
<br>
<blockquote type="cite">So it seems that the problem you are seeking to solve is limiting access<br>
to sensitive outputs. The solution mentioned above certainly narrows<br>
the attack surface, but it suffers from a DOS race condition where a<br>
bad actor can lock you out of your own resource.<br>
</blockquote>
Also, if an attacker is able to authenticate as your account, you have much bigger problems than them locking you out of an output.<br>
</blockquote>
A non-malicious race condition would be launching your stack through<br>
Horizon. Just clicking around will very quickly use up your one stack-show.<br>
<br>
I would suggest either encryption like Clint suggested, or an extra<br>
attribute to stack-show so that sensitive outputs are only returned when<br>
explicitly asked for.<br>
<br>
<blockquote type="cite">Thanks.<br>
-Andrew<br>
________________________________________<br>
From: Clint Byrum [<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>]<br>
Sent: Wednesday, November 06, 2013 8:36 PM<br>
To: openstack<br>
Subject: Re: [Openstack] [Heat] Locked Outputs<br>
<br>
Excerpts from Andrew Plunk's message of 2013-11-07 06:48:33 +0800:<br>
<blockquote type="cite">Hello All,<br>
<br>
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:<br>
<br>
</blockquote>
This is an interesting concept. I'd like to start with a problem<br>
statement though, as it is not clear what this is meant to solve.<br>
<br>
<blockquote type="cite">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.<br>
example:<br>
<blockquote type="cite">show stack<br>
</blockquote>
"outputs": {<br>
"password": "password"<br>
}<br>
<br>
<blockquote type="cite">show stack<br>
</blockquote>
"outputs": {<br>
}<br>
<br>
<br>
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.<br>
example:<br>
<br>
<blockquote type="cite">show stack<br>
</blockquote>
"outputs": {<br>
"password": {<br>
"value": "password",<br>
"locked": false<br>
}<br>
}<br>
<br>
<blockquote type="cite">show stack<br>
</blockquote>
"outputs": {<br>
"password": {<br>
"value": "password",<br>
"locked": true<br>
}<br>
}<br>
<br>
<br>
The outputs section of the template for either case would could look like:<br>
outputs:<br>
password:<br>
value: { get_attr: [ some_resource, some_value ] }<br>
description: The password<br>
view_once: True<br>
<br>
</blockquote>
So it seems that the problem you are seeking to solve is limiting access<br>
to sensitive outputs. The solution mentioned above certainly narrows<br>
the attack surface, but it suffers from a DOS race condition where a<br>
bad actor can lock you out of your own resource.<br>
<br>
I have a different idea for that, which is to encrypt the output using<br>
public key cryptography.<br>
<br>
heat stack-create -f mytemplate.yaml -P PasswordRecipientKey="$(gpg<br>
--armor --print-key <a href="mailto:me@foo.com">me@foo.com</a>)"<br>
<br>
And then have an output type of "Encrypted"<br>
<br>
Outputs:<br>
Password:<br>
Type: Encrypted<br>
Keys:<br>
- {Ref: PasswordRecipientKey}<br>
<br>
Now you can simply decrypt this with your local gpg key. heatclient<br>
could even automatically do this for you making it transparent as long<br>
as you have a gpg key agent running.<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote>
</div>
<br>
</body>
</html>