[openstack-dev] [Keystone][Design Session] Where to propose extensions to trusts?

Johannes Grassler jgrassler at suse.de
Fri Oct 21 09:01:53 UTC 2016


Hello,

I've got a last minute proposal, or rather two of them for the Keystone side of
the design sessions in Barcelona. I guess it's something that would fit the
Authorization work session on Friday (09:00-09:40) but I'm not sure I can
simply add it on the Etherpad. Also, I may not able to attend the session in
person since I'll need to join the Barbican session in the same time slot as
well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:

1. Scope extensions for trusts
==============================

Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to
grant their service users or dedicated trustee users limited rights for various
purposes, such as deferred operations on behalf of the user or providing access to
certificate containers. These trusts can only be limited to a set of roles in a
given project right now. The Admin guide mentions an endpoint limitation on top of
that, but I haven't found any code in Keystone for handling that. I played with it
a bit and found that every keyword argument Keystone doesn't know what to do
with ends up in the trust table's `extra` column, but there's no code for doing
anything with it as far as I can tell. It would be a useful thing, though and
implementing it goes hand in hand with my proposal: I'd like to see an ability
to scope trusts to:

   1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL and nothing else")
   2) A fixed path (i.e. "This trust may only access /v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
   3) A fixed URL (i.e. "This trust may only access
      http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)

The main thing I'm currently interested in is whether this is feasible. If so,
I'd be happy to work on a blueprint and implementation. I believe this is
really important to allow services and users to limit trusts to exactly the
access level needed and not a bit more.


2. Lightweight trusts
=====================

When Keystone trusts are created the current practice is to either

   1) Delegate the trust to a service user using the trust (example: Heat)
   2) Create a dedicated trustee user for delegating the trust to (example:
      Magnum)

(1) is fine as far as I'm concerned, but I think (2) could do with some
improvement. The dedicated trustee user will have a user name and password that
needs to be used to authenticate as that user (along with a trust ID to consume
the trust). I'd rather see a long-lived trust token scoped to the trust that
can be extended upon expiry for that purpose. Just like a regular token, in
other words. For the following reasons:

   1) Everybody who creates such a user will have different idea of a secure
      password length. A token is generated by keystone in a centralized manner
      and always of a sufficient length to make for a secure secret.
   2) It requires third party software that may need to authenticate as the
      trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver
      (used by Magnum). Most such software should be able to handle an auth
      token, on the other hand.
   3) There is less cleanup required after the trust has served its purpose:
      only the trust needs to be deleted at that point, but no trustee user.

Comments on these two proposals (and advice on a suitable forum for discussing
them at the summit) would be greatly appreciated. Thank you!

Cheers,

Johannes


Footnotes:

[0] In a pinch I could probably ask a colleague to stand in for me, but I'd
     prefer a solution where I can be present for both discussions.

-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany



More information about the OpenStack-dev mailing list