On 11/14/2013 10:03 AM, Steven Hardy wrote:
On Wed, Nov 13, 2013 at 10:04:04AM -0600, Dolph Mathews wrote:
I guarantee there's a few things I'm forgetting, but this is my collection
of things we discussed at the summit and determined to be good things to
pursue during the icehouse timeframe. The contents represent a high level
mix of etherpad conclusions and hallway meetings.
https://gist.github.com/dolph/7366031
Looks good, but I have some feedback on items which were discussed (either
in the delegation session or in the hallway with ayoung/jlennox), and are
high priority for Heat, I don't see these captured in the page above:
Delegation:
- Need a way to create a secret derived from a trust (natively, not via
ec2tokens extension), and it needs to be configurable such that it
won't expire, or has a very long expiry time. ayoung mentioned a
credential mechanism, but I'm not sure which BP he was referring to, so
clarification appreciated.
I am not sure this is pointing the right direction. Trusts assume
authentication from an separate source, like the token the trustee
passes in when executing the trust. Long term credentials should be
used in conjunction with a trust, but separate to it. I suspect that
there is something that could be done with X509, Trusts, and Token
Binding that would make sense here.
Something like:
1. Identify client machine
2. Generate new Cert for Client machice (Key stays on client, gets
signed by CA)
3. Generate trust, and link trust to new cert.
4. Client machine uses cert and trust to get tokens.
Client:
- We need a way to get the role-tenant pairs (not just the tenant-less
role list) into the request context, so we can correctly scope API
requests. I raised this bug:
A token is scoped to something; project, domain, whatever. Providing
tokens that are scoped wider is somewhat suspect. What you want to do
is to query the data from Keystone using an unscoped token. But any
token from a user sent back to Keystone (except a trust token) should be
able to access this information.
Put another way: you need to query the role information for additional
requests to Keystone. A token is specifically for proving that you have
access to the information to a third party. Since anything that is going
to be done with this information is going to be validated by Keystone,
it is OK to do it as a query against Keystone itself.
So, I think what you want is a way to query all roles for a user on all
projects in all domains. This can be done taody doing individual calls
(enumerate domains, enumerat projects) which is chatty. If it proves
to be a performance bottleneck, we can optimize it into a single call.
https://bugs.launchpad.net/python-keystoneclient/+bug/1250982
Related to this thread (reminder - which you said you'd respond to ;):
http://lists.openstack.org/pipermail/openstack-dev/2013-November/018201.html
This topic came up again today related to tenant-scoped nova flavors:
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html
Closely related to this bug I think:
https://bugs.launchpad.net/keystone/+bug/968696
I'd welcome discussion on how we solve the request-scoping issue
openstack-wide, currently I'm thinking we need the role-tenant pairs (and
probably role-domain pairs) in the request context, so we can correctly
filter in the model_query when querying the DB while servicing the
API request.
Thanks,
Steve
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
