Re: [Openstack] [Heat] Locked Outputs
Alright. The problem: If a program generates a password, and displays it on a screen over and over again, it is more susceptible to being compromised. Possible solutions: 1).Provide a way to limit the availability of stack outputs returned from heat. 2).Provide a way to express metadata about stack outputs returned from heat. From: Clint Byrum [cl...@fewbar.com] Sent: Tuesday, November 12, 2013 8:46 PM To: openstack Subject: Re: [Openstack] [Heat] Locked Outputs Excerpts from Andrew Plunk's message of 2013-11-12 17:24:25 -0800: > Thanks for reiterating that Zane. The problem I have is I want to display > generated passwords once, and only once in a ui. I want the ability to flag > or conditionally display outputs based on conditions. > A problem is stated with a cause and an effect "Users may lose control of the UI after the first time outputs are displayed, leading to credential compromise". Another example: "English encourages use of overloaded terms which can be ambiguous, requiring multiple iterations to communicate ideas effectively." Solution: "I want to define terms more clearly before using them in sentences." "I want to ..." is a _solution_. Maybe we can try one more time? ___ 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
Re: [Openstack] [Heat] Locked Outputs
Thanks for reiterating that Zane. The problem I have is I want to display generated passwords once, and only once in a ui. I want the ability to flag or conditionally display outputs based on conditions. Now you can argue that this belongs in heater, and I would not necessarily disagree with that. However, I think that the outputs could be a lot more powerful if we started extending them to be displayed in certain conditions. Clint's encryption example could fall into this case, "display this output only after encrypting it with this key", my use case is of course "display this output once and only once" or "display this output with a flag after the first time". -Andrew Plunk From: Zane Bitter [zbit...@redhat.com] Sent: Tuesday, November 12, 2013 7:32 AM To: openstack@lists.openstack.org Subject: Re: [Openstack] [Heat] Locked Outputs On 07/11/13 18:07, 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. That's not the problem, that's a solution. As Clint pointed out, you haven't described the problem yet. - ZB ___ 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
Re: [Openstack] [Heat] Locked Outputs
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
[Openstack] [Heat] Locked Outputs
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:
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
Any feedback would be appreciated. Thanks!
-Andrew Plunk
___
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
