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

Steve Martinelli s.martinelli at gmail.com
Fri Oct 21 13:07:15 UTC 2016


On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler <jgrassler at suse.de>
wrote:

> 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
>

The Authorization work session is more than appropriate, please go ahead
and add the items to the etherpad. Do try to be there in person, it'll make
things easier. If you can't make the session then you can always pop into
another keystone session or lurk around until the end of one where we can
talk.


> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/e8ff7457/attachment.html>


More information about the OpenStack-dev mailing list