As long as the request-id is validated that it looks like a guid/request id, I
have no problem trusting the input and passing that around. In fact we want to
be able to take request-id inputs on the API, as we have other systems that
call into our openstack api’s so if there is an issue it would be nice to be
able to use the same request-id between those external systems and openstack.
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
On 5/16/17, 10:01 AM, "Sean Dague" <s...@dague.net> wrote:
After the forum session on logging, we came up with what we think is an
approach here for global request ids -
https://review.openstack.org/#/c/464746/ - it would be great of
interested operators would confirm this solves their concerns.
There is also an open question. A long standing concern was "trusting"
the request-id, though I don't really know how that could be exploited
for anything really bad, and this puts in a system for using service
users as a signal for trust.
But.... the whole system is a lot easier, and comes together quicker, if
we don't have that. For especially public cloud users, are there any
concerns that you have in letting users set Request-Id (assuming you'll
also still have a 2nd request-id that's service local and acts like
request-id today)?
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
