Open Stack

On Nov 13, 2013, at 3:51 PM, Zane Bitter <zbitter at redhat.com> wrote:

> On 13/11/13 18:14, Randall Burt wrote:
>> 
>> On Nov 13, 2013, at 9:18 AM, Zane Bitter <zbitter at redhat.com>
>>  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.