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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev