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)
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 on
nks.
-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 display
ensitive 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
>
>
__
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
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 outpu
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
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
e "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
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 st
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-
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
ost 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 t
6 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
imply 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.
>>
>
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. He
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.
>>>
>>> Thi
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
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
19 matches
Mail list logo