<div dir="ltr"><div><div><div><div><div>Hi All, <br><br></div>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. <br><br></div>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. <br><br></div>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)<br><br></div>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. <br><br></div>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. <br><div><div><div><div><br>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.<br><br></div><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div>Please comment here and on the spec.<br><br><br></div><div><br></div><div>Thanks, <br><br></div><div>Jamie<br><br><br><br>[1] <a href="https://review.openstack.org/#/c/317266/">https://review.openstack.org/#/c/317266/</a><br></div></div></div></div></div>