Re: [Openstack] [Heat] Locked Outputs
On Nov 14, 2013, at 12:34 PM, Zane Bitter wrote: > On 14/11/13 17:16, Randall Burt wrote: >> I think it could work for dashboards as well. The behavior would be to >> display the masked value and add a control that once activated, retrieves >> the unmasked value. Since one hopes this dashboard would be using some >> library like python-heatclient, its not that much work. > > It _could_ work, especially if the control shows/hides all of the hidden > outputs at once. I was thinking of the case where you would show/hide them > individually, in which case trying to make use of the 2 APIs would lead to > comically bad code. e.g.: > > * Request the (possibly masked) output data. > * Display a control next to all outputs that have 'Hidden: true'. > * When the control is clicked, request the non-masked data > - Your data is now potentially inconsistent, so maybe you should update all > of the outputs. > * Display the non-masked data for that output. And change the data for all > the other outputs. But not the ones marked 'Hidden', because that will show > all of them. > * If the user clicks again, repeat this process, fetching the masked data > again. > * Remember not to update the fields marked Hidden, except for the one where > the click was, and the Hidden fields that are currently shown. While you're right that that's pretty horrible, it doesn't match what's actually done in most cases. In my experience data constancy is generally relegated to some optimistic/pessimistic locking scheme on the backend and not the UI, so this example seems a bit contrived to me. It could simply be: * Request all the output data * Display control on hidden: true * When control clicked, retrieve unmasked data for that key. You're data has no greater chance of being inconsistent from that last step than sitting on the screen simply changing non-masked values. > > We could simplify this a bit: > * Request the (possibly masked) output data. > * Request the unmasked output data. > - Your data is now potentially inconsistent, so maybe you should update all > of the outputs, aka throw out everything from the previous, masked, request > that you just made. > * Hide the data and display a control next to all outputs that have 'Hidden: > true'. > * When the control is clicked, display the non-masked data for that output. > * If the user clicks again, hide the data. > > Which reduces to what I was suggesting: > * Request the unmasked output data. > * Hide the data and display a control next to all outputs that have > 'Sensitive: true'. > * When the control is clicked, display the non-masked data for that output. > * If the user clicks again, hide the data. > >> As to there being no security value in masking sensitive data > > My point here was simple: if there is a known URL from which you can obtain > sensitive data, the existence of another known URL from which you cannot > obtain sensitive data does not in any meaningful sense increase the security > of the system. And that's fine if security is not the reason you're doing it, > I'm just pointing out that I don't see any other reasons and security isn't > one either. True, but its not about *security* in the sense of completely protecting data; the extra step implies intent and somewhat prevents exposing sensitive data unintentionally. > >> , we already have a precedent for this in parameters > > We do, and consistency is nice, but simplicity of both the implementation and > consumers' implementations is also good. Agreed, and I wouldn't be opposed to having a way to say: give me *all* the data either masked or unmasked. I assume that hidden parameters are masked to conform to AWS api behavior, so its somewhat confusing that the same pattern wasn't afforded to outputs as well. As it stands now, though, we don't have a way to get hidden data at all. I suppose this and your previous statements argues the point of masking the data at all on the Heat api side, but I think that's a tougher row to hoe that simply providing access. > > cheers, > Zane. > >> without having the ability to get the unmasked values IIRC. The fact that >> those are user-supplied sensitive data versus system generated sensitive >> data is irrelevant since its the template author (which isn't always the >> person deploying the template) that determines a value's sensitivity, not >> some inherent property of the value. > > > ___ > 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
On 14/11/13 17:16, Randall Burt wrote: I think it could work for dashboards as well. The behavior would be to display the masked value and add a control that once activated, retrieves the unmasked value. Since one hopes this dashboard would be using some library like python-heatclient, its not that much work. It _could_ work, especially if the control shows/hides all of the hidden outputs at once. I was thinking of the case where you would show/hide them individually, in which case trying to make use of the 2 APIs would lead to comically bad code. e.g.: * Request the (possibly masked) output data. * Display a control next to all outputs that have 'Hidden: true'. * When the control is clicked, request the non-masked data - Your data is now potentially inconsistent, so maybe you should update all of the outputs. * Display the non-masked data for that output. And change the data for all the other outputs. But not the ones marked 'Hidden', because that will show all of them. * If the user clicks again, repeat this process, fetching the masked data again. * Remember not to update the fields marked Hidden, except for the one where the click was, and the Hidden fields that are currently shown. We could simplify this a bit: * Request the (possibly masked) output data. * Request the unmasked output data. - Your data is now potentially inconsistent, so maybe you should update all of the outputs, aka throw out everything from the previous, masked, request that you just made. * Hide the data and display a control next to all outputs that have 'Hidden: true'. * When the control is clicked, display the non-masked data for that output. * If the user clicks again, hide the data. Which reduces to what I was suggesting: * Request the unmasked output data. * Hide the data and display a control next to all outputs that have 'Sensitive: true'. * When the control is clicked, display the non-masked data for that output. * If the user clicks again, hide the data. As to there being no security value in masking sensitive data My point here was simple: if there is a known URL from which you can obtain sensitive data, the existence of another known URL from which you cannot obtain sensitive data does not in any meaningful sense increase the security of the system. And that's fine if security is not the reason you're doing it, I'm just pointing out that I don't see any other reasons and security isn't one either. , we already have a precedent for this in parameters We do, and consistency is nice, but simplicity of both the implementation and consumers' implementations is also good. cheers, Zane. without having the ability to get the unmasked values IIRC. The fact that those are user-supplied sensitive data versus system generated sensitive data is irrelevant since its the template author (which isn't always the person deploying the template) that determines a value's sensitivity, not some inherent property of the value. ___ 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
On Nov 13, 2013, at 3:51 PM, Zane Bitter wrote: > On 13/11/13 18:14, Randall Burt wrote: >> >> On Nov 13, 2013, at 9:18 AM, Zane Bitter >> wrote: >> >>> On 13/11/13 04:08, Andrew Plunk wrote: 2).Provide a way to express metadata about stack outputs returned from heat. >>> >>> This could involve something like a "Sensitive: true" field in the Output >>> schema. Heat would ignore it but pass it on to clients so that something >>> like the dashboard could e.g. require an extra click to show it, and hide >>> it again after a timeout. >>> >>> Alternatively, as lifeless points out, you could pass the password in using >>> a hidden input. That's the currently supported way, and I suspect the >>> better one in most cases. >> >> I mostly agree with this suggestion. For symmetry with parameters, we could >> simply add a key to outputs "hidden: true". For things like stack-list, the >> default would be to display a masked value like we do for parameters. I >> think we should then add the ability to retrieve the unmasked values for >> parameters and outputs. > > I think that would work well for the CLI client, but if I were the dashboard > I don't think that is the way I would want to fetch the data. There's no > actual security benefit to returning a masked value. > > - ZB I think it could work for dashboards as well. The behavior would be to display the masked value and add a control that once activated, retrieves the unmasked value. Since one hopes this dashboard would be using some library like python-heatclient, its not that much work. As to there being no security value in masking sensitive data, we already have a precedent for this in parameters without having the ability to get the unmasked values IIRC. The fact that those are user-supplied sensitive data versus system generated sensitive data is irrelevant since its the template author (which isn't always the person deploying the template) that determines a value's sensitivity, not some inherent property of the value. ___ 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
On 13/11/13 18:14, Randall Burt wrote: On Nov 13, 2013, at 9:18 AM, Zane Bitter wrote: On 13/11/13 04:08, Andrew Plunk wrote: 2).Provide a way to express metadata about stack outputs returned from heat. This could involve something like a "Sensitive: true" field in the Output schema. Heat would ignore it but pass it on to clients so that something like the dashboard could e.g. require an extra click to show it, and hide it again after a timeout. Alternatively, as lifeless points out, you could pass the password in using a hidden input. That's the currently supported way, and I suspect the better one in most cases. I mostly agree with this suggestion. For symmetry with parameters, we could simply add a key to outputs "hidden: true". For things like stack-list, the default would be to display a masked value like we do for parameters. I think we should then add the ability to retrieve the unmasked values for parameters and outputs. I think that would work well for the CLI client, but if I were the dashboard I don't think that is the way I would want to fetch the data. There's no actual security benefit to returning a masked value. - 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
Re: [Openstack] [Heat] Locked Outputs
On Nov 13, 2013, at 9:18 AM, Zane Bitter wrote: > On 13/11/13 04:08, Andrew Plunk wrote: >> 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. > > OK, this is something we can work with, thanks :) > >> Possible solutions: >> >> 1).Provide a way to limit the availability of stack outputs returned from >> heat. > > This is IMHO a bad idea. Amongst other things it will cause chaos with nested > stacks in combination with the multi-region feature coming up. It's not even > a particularly good solution to the problem - what if the time you needed it > was the second, not the first? (Maybe you accidentally clicked away, or maybe > a connection dropped the first time.) What if you really need the password > again later? What if the first time you viewed it (when it really does show > the password) you didn't click away but just left it sitting around visible? > >> 2).Provide a way to express metadata about stack outputs returned from heat. > > This could involve something like a "Sensitive: true" field in the Output > schema. Heat would ignore it but pass it on to clients so that something like > the dashboard could e.g. require an extra click to show it, and hide it again > after a timeout. > > Alternatively, as lifeless points out, you could pass the password in using a > hidden input. That's the currently supported way, and I suspect the better > one in most cases. I mostly agree with this suggestion. For symmetry with parameters, we could simply add a key to outputs "hidden: true". For things like stack-list, the default would be to display a masked value like we do for parameters. I think we should then add the ability to retrieve the unmasked values for parameters and outputs. > > cheers, > Zane. >> >> ____ >> 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 >> > > > ___ > 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
On 11/12/2013 08:08 PM, Andrew Plunk wrote: 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. I don't buy the problem. Using an anaology, the first time the information is shared, it becomes public. It can then be assumed that once information is shared the *first* time, anyone that cares about that information now knows it. Passwords work the same way - if a user sees the password once, they could write it down, give it to their friends, post it on twitter, etc. The fact that it is exposed via the GUI multiple times isn't any more dangerous then these other scenarios. Further argument is if you don't trust your users with the password, don't put in the outputs section. I don't quite get how this would enhance security though, because if they have the OpenStack credentials, theoretically they could access the VM and obtain the password whether you like it or not. Further, they stack-create'ed the vm so ideally they would have responsibility for the security of the stack. Regards -steve 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 ___ 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
On 13/11/13 04:08, Andrew Plunk wrote: 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. OK, this is something we can work with, thanks :) Possible solutions: 1).Provide a way to limit the availability of stack outputs returned from heat. This is IMHO a bad idea. Amongst other things it will cause chaos with nested stacks in combination with the multi-region feature coming up. It's not even a particularly good solution to the problem - what if the time you needed it was the second, not the first? (Maybe you accidentally clicked away, or maybe a connection dropped the first time.) What if you really need the password again later? What if the first time you viewed it (when it really does show the password) you didn't click away but just left it sitting around visible? 2).Provide a way to express metadata about stack outputs returned from heat. This could involve something like a "Sensitive: true" field in the Output schema. Heat would ignore it but pass it on to clients so that something like the dashboard could e.g. require an extra click to show it, and hide it again after a timeout. Alternatively, as lifeless points out, you could pass the password in using a hidden input. That's the currently supported way, and I suspect the better one in most cases. cheers, Zane. 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 ___ 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
On 13 November 2013 16:08, Andrew Plunk wrote: > 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. 3) Don't generate the password 4) Don't show the password at all (just supply it to the cluster being configured) [which the hidden output setting already implements] So - why are you generating a password - what is the password for / where it is being used ? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ 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
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
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
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
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
Re: [Openstack] [Heat] Locked Outputs
On Thu, Nov 07, 2013 at 05:07:16PM +, 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. I still think we need more info regarding the actual use-case, this sounds like you're trying to build a UI-ish access pattern into Heat at the API level? > >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. Exactly, if a user can authenticate with Heat, and has sufficient privileges, why wouldn't they be able to access the outputs of the stack, sensitive or otherwise? The whole idea that limiting providing the output value to the (authenticated) user only once improves security seems bogus to me - I mean, if I give you my credit card details, you have them, doesn't matter if I tell you them 1 or 100 times ;) Steve ___ 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
Excerpts from Randall Burt's message of 2013-11-11 06:45:54 -0800:
> (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:
>
We don't generally use the outputs inside the stack, they are for use
outside the stack. For nested stacks the key would need to be generated
and passed in, the same way one would do in the client version. This is
the most problematic part of using the encrypted output that I proposed.
> /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).
>
That is indeed a nice middle ground. Add to it a policy definition that
would allow one to have users that can show stacks and create stacks but
not view hidden outputs and this becomes a decent way to contain users
while enabling privileged users.
___
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
(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
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
___
Mail
Re: [Openstack] [Heat] Locked Outputs
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]
> 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
___
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
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
