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.math...@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.mcc...@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@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
