Open Stack

Hi All,

I'd like to bring to the attention of the wider security groups and
OpenStack users the Service Users Permissions [1] spec currently proposed
against keystonemiddleware.

To summarize quickly OpenStack has long had the problem of token expiry
happening in the middle of a long running operation and failing service to
service requests and there have been a number of ways proposed around this
including trusts and using the service users to perform operations.

Ideally in a big system like this we only want to validate a token and
policy once on a user's first entry to the system, however all services
only communicate via the public interfaces so we cannot tell at validation
time whether this is the first, second, or twentieth time we are validating
a token. (If we ever do OpenStack 2.0 we should change this)

The proposed spec provides a way to simulate the at-edge validation for
service to service communication. If a request has an X-Service-Token
header (an existing concept) then instead of validating the user's token we
should trust all the headers sent with that request (X_USER_ID,
X_PROJECT_ID etc). We would still validate the X-Service-Token header. This
has the effect that one service asserts to another that it has already
validated this token and the receiving service shouldn't validate it again
and bypass the expiry problem.

The glaring security issue here is that a user with the service role can
now emulate any request on behalf of any user by sending the expected
authenticated headers. This will place an extreme level of trust on
accounts that up to now have generally only been able to validate a token.
There is both the concern here that a malicious service could craft new
requests with bogus credentials as well as services deciding that this
provides them the ability to do non-expiring trusts from a user where it
can simply replay the headers it received on previous requests to perform
future operations on behalf of a user. This is _absolutely not_ the
intended use case but something I expect to come up.

There is a variation of this mentioned in the spec where we pass only the
user-id, project-id and audit information from service to service and then
middleware can recreate the token from this information similar to how
fernet tokens work today. There is additional processing here which in the
standard case will simply reproduce the same headers that the last service
already knew and it still allows a large amount of emulation from the
service.

There are possibly ways we can secure this header bundle via signing
however the practical result is essentially a secondary expiry time and an
operational complexity that will make PKI tokens and rotating fernet keys
appear trivial for the benefit of securing a service that we already trust
with our tokens.

As this has such far reaching implications throughout openstack i would
like outside input on whether the risks are worth the reward in this case,
and what we would need to do to secure a deployment like this.

Please comment here and on the spec.



Thanks,

Jamie



[1] https://review.openstack.org/#/c/317266/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160602/b2327a17/attachment.html>