On 22 Nov 2017, at 22:08, Adrian Turjak wrote:
> 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
The short answer (and you should probably get a longer one at some point) is
that you're right. I wouldn't say it's "broken"
