[openstack-dev] [keystone][security] Service User Permissions

David Chadwick d.w.chadwick at kent.ac.uk
Thu Jun 2 10:19:58 UTC 2016

Hi Jamie

In my opinion no security token should have the potential to last
forever. This is a bad idea and can lead to all sorts of security
vulnerabilities, some of which you highlight below. I thus take issue
with your statement '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'.
Whilst this is true for many situations, I think it should be qualified
with a statement about how long this validation should hold for, such as
'but only for a configurable amount of time, or a certain amount of
resource usage....<add your own condition here>'.

If a security token does not have an expiry time or condition, then
there are two common ways of solving this: polling or notifications.
Various techniques have been deployed for these e.g. CRLs,
publish/subscribe etc. This will require a security layer in OpenStack
that will allow interprocess communications. Is there any ongoing work
along these lines, or plans to introduce it? I believe that various
publish/subscribe mechanisms are available for OpenStack e.g. Marconi.
If so why not leverage one of these, rather than going down the path you

At least one research project (e.g. Coco Cloud) has built U-Con into
OpenStack and this provides the functionality you require, but because
this implementation relies on XACML and obligations, it is probably too
heavyweight for you. However the conceptual model is sound and could be
adapted to solve your requirements.

Hope this is helpful to you



On 02/06/2016 06:23, Jamie Lennox wrote:
> 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/
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list