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

[Johannes Grassler]

Hello,

On 10/21/2016 03:07 PM, Steve Martinelli wrote:

On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler 
wrote:

I've got a last minute proposal, or rather two of them for the Keystone
side of the design sessions in Barcelona.

[...]

The Authorization work session is more than appropriate, please go ahead
and add the items to the etherpad.


Ok, will do. Thank you!


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.


I'll try to make the Authorization session. I think I can find an arrangement
for the Barbican session.

Cheers,

Johannes

--
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steve Martinelli]

On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler 
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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Johannes Grassler]

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev