I’m also agree with you Matt that it will free us from complexity of
handling S3 policy or Swift ACL if we save the current state of OPA. But if
we want use this state of OPA we should act for S3 policy and Swift ACL
that if user is setting them it shouldn’t be allowed and return user that
you can’t set them! Because now when OPA integration is enabled and user
set bucket policy it returns success but actually it doesn’t work!
What are your thoughts?
On Sun, Jan 19, 2020 at 12:33 AM Seena Fallah <seenafallah(a)gmail.com> wrote:
I think the other problem caused when OPA integration
is enabled and we
set bucket policy is when user wants to get his/her bucket policy. Some
policies are set through OPA (for example in OPA rules we have user A that
has access to user B bucket so OPA return true on authorizing request and
it acts like bucket policy) and some through bucket policy (s3 clients
command). So when user is getting his/her bucket policy what data should we
return? The policies that are set through bucket policy or OPA rules for
that bucket?
I fact I think OPA rules are not static and will change in time and so
there should be a client interface for that OPA server that users could
change their rules for their buckets (giving access to put, get, ... to
someone else and etc.). So if the client exists there is no need to bucket
policy and we can make it disable (by returning 405) when OPA integration
is enabled (I repeat that still now in Ceph latest version when OPA
integration is enabled bucket policies aren’t work!) because the policies
that are set with bucket policy can be check with OPA, too.
What’s your opinion?
On Fri, Jan 17, 2020 at 9:40 PM Seena Fallah <seenafallah(a)gmail.com>
wrote:
> I think when OPA integration is enabled the source of truth for
> authorizing should be OPA (it is right now in Ceph and all requests are
> authorizing with OPA and Ceph doesn’t authorize any request by it self).
> When user is using bucket policy feature he/she wants to get access to
> someone else so when he/she is the bucket owner, he/she can perform this
> action and we should apply this policy for him/her. If we want policies
> just update within OPA server/client and S3 clients (s3cmd, aws, ...) don’t
> edit policies, we should reply to them that set/delpolicy isn’t allowed
> from here (return 405 for example; just for saying that the request that
> user send isn’t successful).
>
> Yes we can have some process and simplification before sending it to OPA
> but the s3 policy has a general structure so OPA server can decode it by it
> self.
>
> On Fri, Jan 17, 2020 at 9:16 PM Matt Benjamin <mbenjami(a)redhat.com>
> wrote:
>
>> The larger question, I think, is what OPA is supposed to do with it.
>> The larger question I think it asks is whether OPA or Ceph owns a
>> particular dimension of policy--or, perhaps, which owns policy for
>> what portions of the namespace (at any particular point in time).
>>
>> Without any new interaction, when OPA is configured, OPA can make a
>> direct authorization decision with all available information for
>> Ceph/RGW, notwithstanding any S3 or Swift ACL or S3 policy that might
>> exist--including any that might have been stored prior to turning on
>> this proposed feature to push policy documents to OPA. This
>> overriding property of the OPA integration when in use frees us from a
>> lot of complexity regarding which system is the source of truth, and
>> for what.
>>
>> I can see value in more sophisticated integration that mutually
>> comprehends policy--but I'm having trouble with "send policy documents
>> to OPA, maybe it will do something with them."
>>
>> Matt
>>
>> On Fri, Jan 17, 2020 at 12:01 PM Seena Fallah <seenafallah(a)gmail.com>
>> wrote:
>> >
>> > Hello Ash
>> >
>> > With bucket policy user A can get access to user B for putting object
>> on bucket C. So if this policy sent to Ceph and OPA integration is enabled
>> it will be discard because this policy isn’t sent to OPA server to be
>> updated.
>> > Here is a documentation for bucket policy:
>> >
https://docs.ceph.com/docs/master/radosgw/bucketpolicy/
>> >
>> > With this PR when user set bucket policy, the data of that policy will
>> sent to OPA server to be applied and so OPA can get access to user that
>> gets access to bucket via bucket policy.
>> >
>> > On Fri, Jan 17, 2020 at 8:24 PM Ash Narkar <ash(a)styra.com> wrote:
>> >>
>> >> Hello Seena,
>> >>
>> >> The OPA integration is with the RGW and the intent is to check if an
>> authenticated user is allowed to perform a particular action on a
>> particular resource. For example, can Bob delete a bucket based on some
>> attribute like his location. I am not familiar with the internals of Ceph's
>> bucket policy command. It would be great to get some context here and
>> discuss if the bucket policy can be authorized with OPA which is the intent
>> of your PR I believe.
>> >>
>> >> Thanks
>> >> Ash
>> >>
>> >> On Fri, Jan 17, 2020 at 6:33 AM Seena Fallah
<seenafallah(a)gmail.com>
>> wrote:
>> >>>
>> >>> So when OPA integration is enabled the bucket policy from users
will
>> not work!
>> >>> I think it’s about Ceph architecture not OPA because OPA is for
>> authorizing the requests and bucket policy is one of the authorizing
>> methods that OPA should support.
>> >>>
>> >>> On Fri, Jan 17, 2020 at 5:56 PM Matt Benjamin
<mbenjami(a)redhat.com>
>> wrote:
>> >>>>
>> >>>> Hi Seena,
>> >>>>
>> >>>> As I wrote in a comment on your PR, my current intuition is
that
>> what
>> >>>> you're doing here isn't consistent with the original
intent of the
>> OPA
>> >>>> integration we currently have, nor with the OPA model in
general.
>> >>>>
>> >>>> That said, I'd really like some feedback from OPA
architects, CC'd.
>> >>>>
>> >>>> regards,
>> >>>>
>> >>>> Matt
>> >>>>
>> >>>> On Thu, Jan 16, 2020 at 5:04 AM Seena Fallah
<seenafallah(a)gmail.com>
>> wrote:
>> >>>> >
>> >>>> > Hi all. In OPA integration from Ceph there is no
integration for
>> bucket policy.
>> >>>> > When user is setting bucket policy to his/her bucket the
OPA
>> server won't get who get's access to that bucket so after that if the
>> request is coming from the user (that gets access to that bucket via bucket
>> policy) to access that bucket (PUT, GET,...), OPA will reject that because
>> of no data in database.
>> >>>> > I have create a pull request for this problem so if user
creates
>> a bucket policy for his/her bucket, the policy data will send to OPA server
>> to be update on the database.
>> >>>> > I think the main idea of having OPA is to have all
authorization
>> in OPA and Ceph don't authorize any request by it self.
>> >>>> > Here is the pull request and I would be thankful to hear
about
>> your comments.
>> >>>> >
https://github.com/ceph/ceph/pull/32294
>> >>>> > Thanks.
>> >>>> > _______________________________________________
>> >>>> > Dev mailing list -- dev(a)ceph.io
>> >>>> > To unsubscribe send an email to dev-leave(a)ceph.io
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Matt Benjamin
>> >>>> Red Hat, Inc.
>> >>>> 315 West Huron Street, Suite 140A
>> >>>> Ann Arbor, Michigan 48103
>> >>>>
>> >>>>
http://www.redhat.com/en/technologies/storage
>> >>>>
>> >>>> tel. 734-821-5101
>> >>>> fax. 734-769-8938
>> >>>> cel. 734-216-5309
>> >>>>
>>
>>
>> --
>>
>> Matt Benjamin
>> Red Hat, Inc.
>> 315 West Huron Street, Suite 140A
>> Ann Arbor, Michigan 48103
>>
>>
http://www.redhat.com/en/technologies/storage
>>
>> tel. 734-821-5101
>> fax. 734-769-8938
>> cel. 734-216-5309
>>
>>