Open Stack

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-request at 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" per se. Just that the models used to be in sync but as Keystone as added things, tight integration with Swift hasn't kept up.

Swift doesn't have the Keystone policy.json support plumbed through, so Swift's ACLs are all it knows how to do. I'd like to see support for RBAC in Swift, but it's not something that's happened yet (nor is it something that anyone is currently working on, as far as I know).

--John



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171122/84294c40/attachment.sig>