(sorry for the double-post Steve)
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:
/stacks/{stack_name}/{stack_id}/outputs/{output_key}/value?unmask=true
Instead of the query param, we could also simply say that by convention, when
the output value is requested this way, its always unmasked).
On Nov 10, 2013, at 2:35 PM, Steve Baker
<sba...@redhat.com<mailto:sba...@redhat.com>>
wrote:
On 11/08/2013 06:07 AM, Andrew Plunk wrote:
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.
A non-malicious race condition would be launching your stack through
Horizon. Just clicking around will very quickly use up your one stack-show.
I would suggest either encryption like Clint suggested, or an extra
attribute to stack-show so that sensitive outputs are only returned when
explicitly asked for.
Thanks.
-Andrew
________________________________________
From: Clint Byrum [cl...@fewbar.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
