Open Stack

On Nov 14, 2013, at 12:34 PM, Zane Bitter <zbitter at redhat.com> 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack