Open Stack

Dolph,

Donagh McCabe wrote: 
    I'm toying with the idea that Swift would know what projects were needed to use an X-Service-Token.....

I decided to write that up in the spec. For anyone interested, see https://review.openstack.org/#/c/105228/

I think domain-level role assignments that are inherited to projects is prone to misconfiguration. For example, if the role is called "image_service", you could imagine a naïve administrator thinking that all users needed "image_service" so they can talk to Glance. Nothing would break and it might be some time before anyone realises they are vulnerable. With my proposal, once the system is initially configured (in /etc/swift/proxy-server.conf) there are no on-going implications.

Regards,
Donagh

-----Original Message-----
From: McCabe, Donagh 
Sent: 17 July 2014 16:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Swift] Composite Auth question

Dolph,

> The project in the primary X-Auth-Token (rather than the secondary X-Service-Token) should be the one that conveys the scope

That had been my assumption and had hoped that was ok. It certainly seemed good enough for Swift

> …so a service could be assigned a role on a domain with inheritance, and then the service can generate project-scoped tokens...

This creates two issues:

A/ There is an extra overhead on domain owners to setup the service user with the appropriate role. In a multi-domain environment, this means that the glance service user is probably in a different domain than the end-user's domain (e.g., glance user is setup in domain A; the owners of domains B, C, D need to know details of a domain A user). This is more feasible than doing it for every project, but still is some overhead. [footnote]

B/ The glance service needs to ask Keystone for a token for every request -- it cannot simply re-use a glance-user token. So there are several extra calls needed: glance to ask for a token scoped to the end-user's project; Keystone to create the token; Swift won't find it in memcache, so it will need to validate the token.. I may be overstating this. If glance/cinder is the use-case, this is not much overhead for a comparatively infrequent event.

I'm toying with the idea that Swift would know what projects were needed to use an X-Service-Token. In effect, Swift would know that container X is owned by project X, but is also owned-for-update by glance project. With this scheme, the composite auth is teamed with "composite ownership". Specifically, the X-Service-Token is scoped to the glance project, X-Auth-Token is scoped to the end-user's project and Swift checks both.

I didn't want to offer up this idea because it's more complexity for the deployer (but once done, the domain admins would not have to do anything)

A general question: I understand the Swift use-case. I believe there are other use cases for composite auth. Do they have similar project-role-scope issues? I guess Swift is different in that the user gets to name the project (in the path) whereas other projects derive the target project form the X-Auth-Token.

[footnote] I use glance as an example...applies to Cinder and *every* service that plans to use composite auth


From: Dolph Mathews [mailto:dolph.mathews at gmail.com] 
Sent: 17 July 2014 15:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Swift] Composite Auth question


On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh <Donagh.McCabe at hp.com> wrote:
Hi,
 
I’m working on the Swift implications of using composite authorization [1] [2].
 
My question for Keystone developers is : what  project-id do we expect the service token to be scoped to - the service's project or the end-user's project? When reviewing the Keystone spec, I had assumed the former. However, now that I'm looking at it in more detail, I would like to check my understanding.
FWIW, prior to reading the below, I would have said I don't think it should matter to Swift. The project in the primary X-Auth-Token (rather than the secondary X-Service-Token) should be the one that conveys the scope. But... I'm probably wrong, and I think I prefer option 2 below.
 
The implications are:
 
1/ If scoped to the service's project, the role used must be exclusive to Glance/Cinder.
I.e. an end-user must never be assigned this role.
In effect, a role on one project grants the service user some privileges on every project.
Keystone would never make this last behavior ^ explicit, without hierarchical multitenancy (and a single root project)... because we already have the solution I describe below...
 
2/ if scoped to the end-user's project, the glance/cinder service user must have a role on every project that uses them (including across domains); this seems infeasible.
Keystone does have domain-level role assignments that are inherited to projects... so a service could be assigned a role on a domain with inheritance, and then the service can generate project-scoped tokens (with the domain-level role applied) for any project in the domain. I think that would make option 2 much more feasible, but yes- you still need a role assignment for per domain in the system.
 
Regards,
Donagh
 
[1] swift-specs: https://review.openstack.org/105228
[2] keystone-specs: https://review.openstack.org/#/c/96315/

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev