Open Stack

Hello fellow openstackers,

I'm trying to figure something out that confuses me around how Swift
handles roles from Keystone, and what the ACLs allow.

In the Swift config you can specify roles which can manage the
containers for their project ('operator_roles'), and anyone with such a
role appears to bypass ACLs on their containers.

But beyond that Swift doesn't seem to handle roles in the same way other
projects do. It has no policy.json file, so you can't limit access to
the Swift API to specific roles beyond 'operator_roles'. To do any real
limiting in Swift you have to use ACLs. Sure you can limit specific
containers via ACLs to a user on a project, and even with a given role,
but ACLs are user defined, and it feels odd that they would bypass scope
and roles.

If you assign an ACL to a container  for a given user but don't specify
project, Swift only cares that the user is authenticated (does at least
need to be a scope token, right?) and that the ACL is valid, but does
not respect role/token scope really.

That means that even if you wanted to do a read_only role for everything
(nova, cinder, etc), you could always bypass that with ACLs in Swift.
This means Swift's authorisation model can entirely bypass the Keystone
one in the context of Swift. This seems kind of broken. I can understand
some cases where that would be useful, but it seems to go against the
rest of the authorisation model in OpenStack, where roles define
explicitly where and what you have access to (or at least at meant to).

Am I understanding this wrong? Or missing something obvious? Or is this
just how it is and it won't change? Because it feels wrong, and I'm not
sure if that's just me not understanding it, me being paranoid in ways I
shouldn't, or this really isn't right. I don't like the idea that we
have two authorisation mechanisms (the core one being Keystone) that can
be bypassed by Swift ACLs for the purposes of itself. Which makes Swift
in truth have a higher precedence than Keystone for the purposes of
scope when it comes to it's own resource. It means there are multiple
sources of truth, one which is the authority for all other services, and
another that is the authority for itself. That might makes for all kind
of mistakes, as people will assume that Keystone scope is honored
everywhere, since mostly that is the case.

I'm asking because I'd like to setup fine grained roles for each
service, and when I make a role that can only talk to Nova, I don't
really like the idea of an ACL being able to bypass that. Not to mention
there really isn't anything role based I can do via roles/Keystone for
Swift that can't be bypassed in some way by ACLs, nor can I make a role
that is read_only for Swift for that given project. I can't have
swift_readonly, swift_write, swift_manage (manage being able to do
ACLs). Even with account level ACLs (which don't yet work with Keystone
anyway), they wouldn't be implied by roles and would have to be set
manually on project creation, so... it doesn't really work either.

Part of me would at least feel far more comfortable if there was a
setting in Swift that enforced roles and scope so that you could only
ever talk to Swift in your project regardless of ACLs, but that feels
like only one of many things that would need to happen. What I imagine
as being my ideal scenario for Swift in OpenStack is Swift respects
roles and scope always, but then ACLs are a way of making fine grained
per user/group permissions to containers/objects within that scope.
Sharing between projects may be useful, but rescoping to the other
project isn't too hard if everything is mostly role based, and sharing
to a project/user that cannot outright accept that sharing permission is
innately scary (which is why Glance's cross-project sharing model works
well). Even more so if the user can't audit their permissions (can a
user see what ACLs apply to them?).

I'm hoping saner minds can help me either understand or figure out if
I'm being silly, or if the permission model between Swift and Keystone
really is weird/broken.

This is also coming from a public cloud perspective rather than a
private one, so who knows if what I'm trying to solve fits with what
others may be thinking. I'm also curious how other clouds look at this,
and what their views are around permissions management between keystone
and swift.

Cheers,
Adrian