<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler <span dir="ltr"><<a href="mailto:jgrassler@suse.de" target="_blank">jgrassler@suse.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I've got a last minute proposal, or rather two of them for the Keystone side of<br>
the design sessions in Barcelona. I guess it's something that would fit the<br>
Authorization work session on Friday (09:00-09:40) but I'm not sure I can<br>
simply add it on the Etherpad. Also, I may not able to attend the session in<br>
</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">person since I'll need to join the Barbican session in the same time slot as<br>
well[0], so I'd appreciate an alternative venue if that's possible.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hence I'll put them forth here for now:<br>
<br>
1. Scope extensions for trusts<br>
==============================<br>
<br>
Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to<br>
grant their service users or dedicated trustee users limited rights for various<br>
purposes, such as deferred operations on behalf of the user or providing access to<br>
certificate containers. These trusts can only be limited to a set of roles in a<br>
given project right now. The Admin guide mentions an endpoint limitation on top of<br>
that, but I haven't found any code in Keystone for handling that. I played with it<br>
a bit and found that every keyword argument Keystone doesn't know what to do<br>
with ends up in the trust table's `extra` column, but there's no code for doing<br>
anything with it as far as I can tell. It would be a useful thing, though and<br>
implementing it goes hand in hand with my proposal: I'd like to see an ability<br>
to scope trusts to:<br>
<br>
1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL and nothing else")<br>
2) A fixed path (i.e. "This trust may only access /v1/secrets/238ca94d-6115-4fe6<wbr>-b41f-c445eeb47df8)<br>
3) A fixed URL (i.e. "This trust may only access<br>
<a href="http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8" rel="noreferrer" target="_blank">http://192.168.123.20:9311/<wbr>v1/secrets/238ca94d-6115-4fe6-<wbr>b41f-c445eeb47df8</a>)<br>
<br>
The main thing I'm currently interested in is whether this is feasible. If so,<br>
I'd be happy to work on a blueprint and implementation. I believe this is<br>
really important to allow services and users to limit trusts to exactly the<br>
access level needed and not a bit more.<br>
<br>
<br>
2. Lightweight trusts<br>
=====================<br>
<br>
When Keystone trusts are created the current practice is to either<br>
<br>
1) Delegate the trust to a service user using the trust (example: Heat)<br>
2) Create a dedicated trustee user for delegating the trust to (example:<br>
Magnum)<br>
<br>
(1) is fine as far as I'm concerned, but I think (2) could do with some<br>
improvement. The dedicated trustee user will have a user name and password that<br>
needs to be used to authenticate as that user (along with a trust ID to consume<br>
the trust). I'd rather see a long-lived trust token scoped to the trust that<br>
can be extended upon expiry for that purpose. Just like a regular token, in<br>
other words. For the following reasons:<br>
<br>
1) Everybody who creates such a user will have different idea of a secure<br>
password length. A token is generated by keystone in a centralized manner<br>
and always of a sufficient length to make for a secure secret.<br>
2) It requires third party software that may need to authenticate as the<br>
trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver<br>
(used by Magnum). Most such software should be able to handle an auth<br>
token, on the other hand.<br>
3) There is less cleanup required after the trust has served its purpose:<br>
only the trust needs to be deleted at that point, but no trustee user.<br>
<br>
Comments on these two proposals (and advice on a suitable forum for discussing<br>
them at the summit) would be greatly appreciated. Thank you!<br>
<br>
Cheers,<br>
<br>
Johannes<br>
<br>
<br>
Footnotes:<br>
<br>
[0] In a pinch I could probably ask a colleague to stand in for me, but I'd<br>
prefer a solution where I can be present for both discussions.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Johannes Grassler, Cloud Developer<br>
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)<br>
GF: Felix Imendörffer, Jane Smithard, Graham Norton<br>
Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div></div>