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
