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