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@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@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@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@ceph.io To unsubscribe send an email to dev-leave@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

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@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@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@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@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@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@ceph.io To unsubscribe send an email to dev-leave@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

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@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@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@gmail.com> wrote:

...

Hello Ash

With bucket policy user A can get access to user B for putting object

...

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@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

...

...

Thanks Ash

On Fri, Jan 17, 2020 at 6:33 AM Seena Fallah <seenafallah@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@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@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

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. 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. 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@ceph.io > To unsubscribe send an email to dev-leave@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

I am a big fan of the IAM policy documents, both because of the flexibility and expressiveness they provide, and because they're in a format that all of our s3 clients understand. I'm not familiar enough with OPA to know what extra capabilities it offers that IAM policy cannot, but I have serious concerns about the performance and scalability of a model where radosgw has to send blocking RPCs to OPA in order to authorize each and every request. On the other hand, consider a model where a Policy Agent exercises its control over authorization by writing IAM documents to radosgw, which we use to cheaply authorize requests out of our metadata cache. I would imagine that this model could cover a lot of interesting use cases, without breaking support for existing s3 applications that rely on bucket policy - as the proposal to reject PutBucketPolicy requests would. Is this something that OPA could feasibly do? For use cases that aren't supported by the existing policy grammar, we're open to maintaining extensions to these documents. We already implement a number of s3 extensions [1][2] that are easily accessible via python/boto and the aws cli. But a model where radosgw outsources authorization entirely is a hard sell, because it conflicts with feature development going forward. One example would be support for PublicAccessBlock [3], where radosgw needs full visibility into policy to detect cases where public access would be granted. [1] https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions [2] https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... [3] https://github.com/ceph/ceph/pull/30033 On 1/20/20 12:21 PM, Seena Fallah wrote:

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@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

Hi all. Any updates here? On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah <seenafallah@gmail.com> wrote:

OPA can be used in companies that uses many services like k8s, Ceph,... and want to have one central point for authorizing users so they can maintenance their access for each user on each service for example and etc. It’s just a use case and so it’s really good to have it. I think this is the biggest use case for having OPA in products that gets an option to centralize authorizing for all types of services.

Performance for this model is issue like having keystone with Ceph. So I think it’s based on users that active this integrations at all.

The model for writing policies to radosgw isn’t really good I think because of the reason above if this accrued there is always two copies of policies and it doesn’t sounds good for maintaining.

If bucket policy disable, s3 clients like boto3 and etc will not work for setting polices but I think when someone is enabling OPA for authorizing it will also have an API for his/her OPA server to set/del policies and they can call these APIs to set/del policies. And for extensions like PublicAccessBlock, it will disable because OPA is just authorizing requests and Ceph doesn’t authorize any request when OPA integration is enabled so OPA should handle any incoming policies were made by S3 policies. So it doesn’t make conflicts and if OPA integration is enabled it won’t work as we return 405 on each set/del policies requests and if OPA is disabled users can use this policies.

On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley <cbodley@redhat.com> wrote:

...

I am a big fan of the IAM policy documents, both because of the flexibility and expressiveness they provide, and because they're in a format that all of our s3 clients understand.

I'm not familiar enough with OPA to know what extra capabilities it offers that IAM policy cannot, but I have serious concerns about the performance and scalability of a model where radosgw has to send blocking RPCs to OPA in order to authorize each and every request.

On the other hand, consider a model where a Policy Agent exercises its control over authorization by writing IAM documents to radosgw, which we use to cheaply authorize requests out of our metadata cache. I would imagine that this model could cover a lot of interesting use cases, without breaking support for existing s3 applications that rely on bucket policy - as the proposal to reject PutBucketPolicy requests would.

Is this something that OPA could feasibly do?

For use cases that aren't supported by the existing policy grammar, we're open to maintaining extensions to these documents. We already implement a number of s3 extensions [1][2] that are easily accessible via python/boto and the aws cli.

But a model where radosgw outsources authorization entirely is a hard sell, because it conflicts with feature development going forward. One example would be support for PublicAccessBlock [3], where radosgw needs full visibility into policy to detect cases where public access would be granted.

[1]

https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions

[2]

https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras...

[3] https://github.com/ceph/ceph/pull/30033

On 1/20/20 12:21 PM, Seena Fallah wrote:

...

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@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

My take so far is that this is not a bug, and I'd like not to introduce special-case logic to override or suppress processing of native policy. Matt On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah <seenafallah@gmail.com> wrote:

I think it's very good that Ceph export its authorization and we could have external source of truth with it. S3 policies can transport to OPA and updates by users set/del policies. But now we have conflict with OPA integration and S3 policies which is set when OPA integration is enabled, aren't work.

Can you all please help to fix this bug?

On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Hi all.

Any updates here?

On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

OPA can be used in companies that uses many services like k8s, Ceph,... and want to have one central point for authorizing users so they can maintenance their access for each user on each service for example and etc. It’s just a use case and so it’s really good to have it. I think this is the biggest use case for having OPA in products that gets an option to centralize authorizing for all types of services.

Performance for this model is issue like having keystone with Ceph. So I think it’s based on users that active this integrations at all.

The model for writing policies to radosgw isn’t really good I think because of the reason above if this accrued there is always two copies of policies and it doesn’t sounds good for maintaining.

If bucket policy disable, s3 clients like boto3 and etc will not work for setting polices but I think when someone is enabling OPA for authorizing it will also have an API for his/her OPA server to set/del policies and they can call these APIs to set/del policies. And for extensions like PublicAccessBlock, it will disable because OPA is just authorizing requests and Ceph doesn’t authorize any request when OPA integration is enabled so OPA should handle any incoming policies were made by S3 policies. So it doesn’t make conflicts and if OPA integration is enabled it won’t work as we return 405 on each set/del policies requests and if OPA is disabled users can use this policies.

On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley <cbodley@redhat.com> wrote:

...

I am a big fan of the IAM policy documents, both because of the flexibility and expressiveness they provide, and because they're in a format that all of our s3 clients understand.

I'm not familiar enough with OPA to know what extra capabilities it offers that IAM policy cannot, but I have serious concerns about the performance and scalability of a model where radosgw has to send blocking RPCs to OPA in order to authorize each and every request.

On the other hand, consider a model where a Policy Agent exercises its control over authorization by writing IAM documents to radosgw, which we use to cheaply authorize requests out of our metadata cache. I would imagine that this model could cover a lot of interesting use cases, without breaking support for existing s3 applications that rely on bucket policy - as the proposal to reject PutBucketPolicy requests would.

Is this something that OPA could feasibly do?

For use cases that aren't supported by the existing policy grammar, we're open to maintaining extensions to these documents. We already implement a number of s3 extensions [1][2] that are easily accessible via python/boto and the aws cli.

But a model where radosgw outsources authorization entirely is a hard sell, because it conflicts with feature development going forward. One example would be support for PublicAccessBlock [3], where radosgw needs full visibility into policy to detect cases where public access would be granted.

[1] https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions

[2] https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras...

[3] https://github.com/ceph/ceph/pull/30033

On 1/20/20 12:21 PM, Seena Fallah wrote:

...

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@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@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

Amazon AWS S3 has two type of policies. One from bucket policy and one form IAM. I think it could be better to have two policies models in Ceph one from bucket policy and one form OPA if its enable. So if you are okay we can change the PR to make bucket policy enabled when OPA is enabled, too. Because now bucket policies not working when OPA integration is enabled. On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah <seenafallah@gmail.com> wrote:

Matt When OPA integration is enabled S3 policies doesn’t work! If you want them to be worked we should bypass S3 policies to OPA for being applied and worked. Here we have conflict in OPA integration with S3 policies!

On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin <mbenjami@redhat.com> wrote:

...

My take so far is that this is not a bug, and I'd like not to introduce special-case logic to override or suppress processing of native policy.

Matt

On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

I think it's very good that Ceph export its authorization and we could

...

But now we have conflict with OPA integration and S3 policies which is set when OPA integration is enabled, aren't work.

Can you all please help to fix this bug?

On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Hi all.

Any updates here?

On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah <seenafallah@gmail.com>

wrote:

...

...

OPA can be used in companies that uses many services like k8s,

Ceph,... and want to have one central point for authorizing users so they can maintenance their access for each user on each service for example and etc. It’s just a use case and so it’s really good to have it. I think this is the biggest use case for having OPA in products that gets an option to centralize authorizing for all types of services.

...

Performance for this model is issue like having keystone with Ceph.

So I think it’s based on users that active this integrations at all.

...

The model for writing policies to radosgw isn’t really good I think

because of the reason above if this accrued there is always two copies of

...

...

...

If bucket policy disable, s3 clients like boto3 and etc will not work

for setting polices but I think when someone is enabling OPA for authorizing it will also have an API for his/her OPA server to set/del

...

...

...

And for extensions like PublicAccessBlock, it will disable because OPA is just authorizing requests and Ceph doesn’t authorize any request when OPA integration is enabled so OPA should handle any incoming policies were made by S3 policies. So it doesn’t make conflicts and if OPA integration is enabled it won’t work as we return 405 on each set/del

...

...

...

On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley <cbodley@redhat.com>

wrote:

...

...

I am a big fan of the IAM policy documents, both because of the flexibility and expressiveness they provide, and because they're in a format that all of our s3 clients understand.

I'm not familiar enough with OPA to know what extra capabilities it offers that IAM policy cannot, but I have serious concerns about the performance and scalability of a model where radosgw has to send blocking RPCs to OPA in order to authorize each and every request.

On the other hand, consider a model where a Policy Agent exercises

its

...

control over authorization by writing IAM documents to radosgw, which we use to cheaply authorize requests out of our metadata cache. I would imagine that this model could cover a lot of interesting use cases, without breaking support for existing s3 applications that rely on bucket policy - as the proposal to reject PutBucketPolicy requests would.

Is this something that OPA could feasibly do?

For use cases that aren't supported by the existing policy grammar, we're open to maintaining extensions to these documents. We already implement a number of s3 extensions [1][2] that are easily accessible via python/boto and the aws cli.

But a model where radosgw outsources authorization entirely is a hard sell, because it conflicts with feature development going forward. One example would be support for PublicAccessBlock [3], where radosgw needs full visibility into policy to detect cases where public access would be granted.

[1]

https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions

...

[2]

https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras...

...

[3] https://github.com/ceph/ceph/pull/30033

On 1/20/20 12:21 PM, Seena Fallah wrote: > 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@gmail.com > <mailto:seenafallah@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

...

...

...

...

> 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

...

...

...

...

> 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

...

...

...

...

> 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@gmail.com <mailto:seenafallah@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

...

...

...

...

> 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@redhat.com <mailto:mbenjami@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

...

...

...

...

> 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

...

...

...

...

> 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@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@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

...

...

...

...

> 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@gmail.com <mailto:seenafallah@gmail.com>> wrote: > >>> > >>> So when OPA integration is enabled the bucket

...

...

...

...

> 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@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@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

...

...

...

...

> bucket so after that if the request is coming from the > user (that gets access to that bucket via bucket

...

...

...

...

> to access that bucket (PUT, GET,...), OPA will reject

...

...

...

...

> 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

have external source of truth with it. S3 policies can transport to OPA and updates by users set/del policies. policies and it doesn’t sounds good for maintaining. policies and they can call these APIs to set/del policies. policies requests and if OPA is disabled users can use this policies. policy) that that policy point in policy perform a policy that policy) that thankful to

...

...

...

...

> hear about your comments. > >>>> > https://github.com/ceph/ceph/pull/32294 > >>>> > Thanks. > >>>> > _______________________________________________ > >>>> > Dev mailing list -- dev@ceph.io <mailto: dev@ceph.io> > >>>> > To unsubscribe send an email to dev-leave@ceph.io > <mailto:dev-leave@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 > > > _______________________________________________ > Dev mailing list -- dev@ceph.io > To unsubscribe send an email to dev-leave@ceph.io _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@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

On 1/28/20 2:45 PM, Matthias Muench wrote:

Hi, I think making Ceph special to what the rest of the clients in the world would expect would be a bit off the idea of providing S3 like service. To my understanding, setting OPA to be the source of truth would introduce latency (based on Casey’s comments) and will not allow to set policies (based on Seena). The first one brings us towards harder latency and especially depending on extern systems resource capability (assume central resource as the idea is and therefor not necessarily really “in reach” within an acceptable latency, routing in addition, etc.). The second one says simply that this would break any existing compatibility with clients and use cases. To me it looks not that good to loose on both ends.

Agreed. Even if one has to opt-in to this broken s3 compatiblity, I'm skeptical that users will find this to be a compelling target for their applications. The existing prototype of OPA integration sends this authorization request to OPA -in addition to- radosgw's own authorization logic, where we consult any of our user/bucket policies or ACLs that apply. In this model, OPA is not the only source of truth. It just has the opportunity to deny access that we would otherwise grant, so it doesn't require that we break compatibility with any S3 features that conflict with OPA's view of policy. Were we to change this so that OPA was the only source of truth, then we'd be left with two bad options: either reject all requests to modify policy and break existing applications, or send all policy/ACL information to OPA and require every OPA policy script to implement s3-compatible enforcement of them. I also don't see any benefit to this model - why, if an client wants to use s3 policy to restrict a certain access, would OPA want to override that and grant access instead?

I could live more with the latency issue but wouldn’t like it. For the second, I can understand the idea of having simplification for auditing the access but I’m not that convinced to take the burden of being “the special” one that nobody wants to work with. So, I would love to see the full fledged support of setting the policy by clients, no matter what the result would be in terms of implementing it to interact with OPA. Instead, having an additional requirement to implement additional handling to set policies different from what S3 actually provides would require special clients first and secondly an additional path to OPA with all the additional burden to tweak security to allow this path to OPA. I feel that the first wouldn’t happen (special clients) and the second in practice not either because of security constraints by the OPA admin folks.

G, -matt

—————————————————— Matthias Muench Senior Specialist Solution Architect EMEA Storage Specialist matthias.muench@redhat.com <mailto:mmuench@redhat.com> Phone: +49-160-92654111 <tel:+49-160-92654111>

Red Hat GmbH Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> 85630 Grasbrunn <x-apple-data-detectors://2/1> Germany <x-apple-data-detectors://2/1> _______________________________________________________________________ Red Hat GmbH, http://www.de.redhat.com <http://de.redhat.com/> · Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen HRB 153243 · Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

...

On Jan 28, 2020, at 15:02, Seena Fallah <seenafallah@gmail.com> wrote:

 Amazon AWS S3 has two type of policies. One from bucket policy and one form IAM. I think it could be better to have two policies models in Ceph one from bucket policy and one form OPA if its enable. So if you are okay we can change the PR to make bucket policy enabled when OPA is enabled, too. Because now bucket policies not working when OPA integration is enabled.

On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote:

Matt When OPA integration is enabled S3 policies doesn’t work! If you want them to be worked we should bypass S3 policies to OPA for being applied and worked. Here we have conflict in OPA integration with S3 policies!

On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin <mbenjami@redhat.com <mailto:mbenjami@redhat.com>> wrote:

My take so far is that this is not a bug, and I'd like not to introduce special-case logic to override or suppress processing of native policy.

Matt

On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: > > I think it's very good that Ceph export its authorization and we could have external source of truth with it. S3 policies can transport to OPA and updates by users set/del policies. > But now we have conflict with OPA integration and S3 policies which is set when OPA integration is enabled, aren't work. > > Can you all please help to fix this bug? > > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: >> >> Hi all. >> >> Any updates here? >> >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: >>> >>> OPA can be used in companies that uses many services like k8s, Ceph,... and want to have one central point for authorizing users so they can maintenance their access for each user on each service for example and etc. It’s just a use case and so it’s really good to have it. I think this is the biggest use case for having OPA in products that gets an option to centralize authorizing for all types of services. >>> >>> Performance for this model is issue like having keystone with Ceph. So I think it’s based on users that active this integrations at all. >>> >>> The model for writing policies to radosgw isn’t really good I think because of the reason above if this accrued there is always two copies of policies and it doesn’t sounds good for maintaining. >>> >>> If bucket policy disable, s3 clients like boto3 and etc will not work for setting polices but I think when someone is enabling OPA for authorizing it will also have an API for his/her OPA server to set/del policies and they can call these APIs to set/del policies. >>> And for extensions like PublicAccessBlock, it will disable because OPA is just authorizing requests and Ceph doesn’t authorize any request when OPA integration is enabled so OPA should handle any incoming policies were made by S3 policies. So it doesn’t make conflicts and if OPA integration is enabled it won’t work as we return 405 on each set/del policies requests and if OPA is disabled users can use this policies. >>> >>> >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote: >>>> >>>> I am a big fan of the IAM policy documents, both because of the >>>> flexibility and expressiveness they provide, and because they're in a >>>> format that all of our s3 clients understand. >>>> >>>> I'm not familiar enough with OPA to know what extra capabilities it >>>> offers that IAM policy cannot, but I have serious concerns about the >>>> performance and scalability of a model where radosgw has to send >>>> blocking RPCs to OPA in order to authorize each and every request. >>>> >>>> On the other hand, consider a model where a Policy Agent exercises its >>>> control over authorization by writing IAM documents to radosgw, which we >>>> use to cheaply authorize requests out of our metadata cache. I would >>>> imagine that this model could cover a lot of interesting use cases, >>>> without breaking support for existing s3 applications that rely on >>>> bucket policy - as the proposal to reject PutBucketPolicy requests would. >>>> >>>> Is this something that OPA could feasibly do? >>>> >>>> For use cases that aren't supported by the existing policy grammar, >>>> we're open to maintaining extensions to these documents. We already >>>> implement a number of s3 extensions [1][2] that are easily accessible >>>> via python/boto and the aws cli. >>>> >>>> But a model where radosgw outsources authorization entirely is a hard >>>> sell, because it conflicts with feature development going forward. One >>>> example would be support for PublicAccessBlock [3], where radosgw needs >>>> full visibility into policy to detect cases where public access would be >>>> granted. >>>> >>>> [1] >>>> https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >>>> >>>> [2] >>>> https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >>>> >>>> [3] https://github.com/ceph/ceph/pull/30033 >>>> >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >>>> >             >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >>>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >>>> > >>>> > >>>> > _______________________________________________ >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >>>> _______________________________________________ >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >>>> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

I think we should not be introducing new special case behavior, nor sending policy documents to OPA, which from what we have heard and read, intends to make no use of them. Matt On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah <seenafallah@gmail.com> wrote:

I think it’s better to OR between two of the bucket policies and OPA policies. So if one of them reject certain access the request will reject as AWS do on its IAM and bucket policy. Are you okay with this idea?

On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley <cbodley@redhat.com> wrote:

...

On 1/28/20 2:45 PM, Matthias Muench wrote:

...

Hi, I think making Ceph special to what the rest of the clients in the world would expect would be a bit off the idea of providing S3 like service. To my understanding, setting OPA to be the source of truth would introduce latency (based on Casey’s comments) and will not allow to set policies (based on Seena). The first one brings us towards harder latency and especially depending on extern systems resource capability (assume central resource as the idea is and therefor not necessarily really “in reach” within an acceptable latency, routing in addition, etc.). The second one says simply that this would break any existing compatibility with clients and use cases. To me it looks not that good to loose on both ends.

Agreed. Even if one has to opt-in to this broken s3 compatiblity, I'm skeptical that users will find this to be a compelling target for their applications.

The existing prototype of OPA integration sends this authorization request to OPA -in addition to- radosgw's own authorization logic, where we consult any of our user/bucket policies or ACLs that apply. In this model, OPA is not the only source of truth. It just has the opportunity to deny access that we would otherwise grant, so it doesn't require that we break compatibility with any S3 features that conflict with OPA's view of policy.

Were we to change this so that OPA was the only source of truth, then we'd be left with two bad options: either reject all requests to modify policy and break existing applications, or send all policy/ACL information to OPA and require every OPA policy script to implement s3-compatible enforcement of them. I also don't see any benefit to this model - why, if an client wants to use s3 policy to restrict a certain access, would OPA want to override that and grant access instead?

...

I could live more with the latency issue but wouldn’t like it. For the second, I can understand the idea of having simplification for auditing the access but I’m not that convinced to take the burden of being “the special” one that nobody wants to work with. So, I would love to see the full fledged support of setting the policy by clients, no matter what the result would be in terms of implementing it to interact with OPA. Instead, having an additional requirement to implement additional handling to set policies different from what S3 actually provides would require special clients first and secondly an additional path to OPA with all the additional burden to tweak security to allow this path to OPA. I feel that the first wouldn’t happen (special clients) and the second in practice not either because of security constraints by the OPA admin folks.

G, -matt

—————————————————— Matthias Muench Senior Specialist Solution Architect EMEA Storage Specialist matthias.muench@redhat.com <mailto:mmuench@redhat.com> Phone: +49-160-92654111 <tel:+49-160-92654111>

Red Hat GmbH Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> 85630 Grasbrunn <x-apple-data-detectors://2/1> Germany <x-apple-data-detectors://2/1> _______________________________________________________________________ Red Hat GmbH, http://www.de.redhat.com <http://de.redhat.com/> · Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen HRB 153243 · Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

...

On Jan 28, 2020, at 15:02, Seena Fallah <seenafallah@gmail.com> wrote:

 Amazon AWS S3 has two type of policies. One from bucket policy and one form IAM. I think it could be better to have two policies models in Ceph one from bucket policy and one form OPA if its enable. So if you are okay we can change the PR to make bucket policy enabled when OPA is enabled, too. Because now bucket policies not working when OPA integration is enabled.

On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote:

Matt When OPA integration is enabled S3 policies doesn’t work! If you want them to be worked we should bypass S3 policies to OPA for being applied and worked. Here we have conflict in OPA integration with S3 policies!

On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin <mbenjami@redhat.com <mailto:mbenjami@redhat.com>> wrote:

My take so far is that this is not a bug, and I'd like not to introduce special-case logic to override or suppress processing of native policy.

Matt

On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: > > I think it's very good that Ceph export its authorization and we could have external source of truth with it. S3 policies can transport to OPA and updates by users set/del policies. > But now we have conflict with OPA integration and S3 policies which is set when OPA integration is enabled, aren't work. > > Can you all please help to fix this bug? > > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: >> >> Hi all. >> >> Any updates here? >> >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: >>> >>> OPA can be used in companies that uses many services like k8s, Ceph,... and want to have one central point for authorizing users so they can maintenance their access for each user on each service for example and etc. It’s just a use case and so it’s really good to have it. I think this is the biggest use case for having OPA in products that gets an option to centralize authorizing for all types of services. >>> >>> Performance for this model is issue like having keystone with Ceph. So I think it’s based on users that active this integrations at all. >>> >>> The model for writing policies to radosgw isn’t really good I think because of the reason above if this accrued there is always two copies of policies and it doesn’t sounds good for maintaining. >>> >>> If bucket policy disable, s3 clients like boto3 and etc will not work for setting polices but I think when someone is enabling OPA for authorizing it will also have an API for his/her OPA server to set/del policies and they can call these APIs to set/del policies. >>> And for extensions like PublicAccessBlock, it will disable because OPA is just authorizing requests and Ceph doesn’t authorize any request when OPA integration is enabled so OPA should handle any incoming policies were made by S3 policies. So it doesn’t make conflicts and if OPA integration is enabled it won’t work as we return 405 on each set/del policies requests and if OPA is disabled users can use this policies. >>> >>> >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote: >>>> >>>> I am a big fan of the IAM policy documents, both because of the >>>> flexibility and expressiveness they provide, and because they're in a >>>> format that all of our s3 clients understand. >>>> >>>> I'm not familiar enough with OPA to know what extra capabilities it >>>> offers that IAM policy cannot, but I have serious concerns about the >>>> performance and scalability of a model where radosgw has to send >>>> blocking RPCs to OPA in order to authorize each and every request. >>>> >>>> On the other hand, consider a model where a Policy Agent exercises its >>>> control over authorization by writing IAM documents to radosgw, which we >>>> use to cheaply authorize requests out of our metadata cache. I would >>>> imagine that this model could cover a lot of interesting use cases, >>>> without breaking support for existing s3 applications that rely on >>>> bucket policy - as the proposal to reject PutBucketPolicy requests would. >>>> >>>> Is this something that OPA could feasibly do? >>>> >>>> For use cases that aren't supported by the existing policy grammar, >>>> we're open to maintaining extensions to these documents. We already >>>> implement a number of s3 extensions [1][2] that are easily accessible >>>> via python/boto and the aws cli. >>>> >>>> But a model where radosgw outsources authorization entirely is a hard >>>> sell, because it conflicts with feature development going forward. One >>>> example would be support for PublicAccessBlock [3], where radosgw needs >>>> full visibility into policy to detect cases where public access would be >>>> granted. >>>> >>>> [1] >>>> https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >>>> >>>> [2] >>>> https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >>>> >>>> [3] https://github.com/ceph/ceph/pull/30033 >>>> >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >>>> > >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >>>> > <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >>>> > >>>> > >>>> > _______________________________________________ >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >>>> _______________________________________________ >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >>>> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@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

Hi Seena, I think it would probably help if you could describe your use case here, and what role you want OPA to play in the interpretation of these bucket policies. In other words, what is it that your OPA policy is doing with these bucket policy documents that shouldn't be done within radosgw? On 1/30/20 1:09 AM, Seena Fallah wrote:

So Matt what should we have done with bucket policy if we enable OPA integration?

On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin <mbenjami@redhat.com <mailto:mbenjami@redhat.com>> wrote:

I think we should not be introducing new special case behavior, nor sending policy documents to OPA, which from what we have heard and read, intends to make no use of them.

Matt

On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: > > I think it’s better to OR between two of the bucket policies and OPA policies. So if one of them reject certain access the request will reject as AWS do on its IAM and bucket policy. > Are you okay with this idea? > > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote: >> >> >> On 1/28/20 2:45 PM, Matthias Muench wrote: >> > Hi, >> > I think making Ceph special to what the rest of the clients in the >> > world would expect would be a bit off the idea of providing S3 like >> > service. >> > To my understanding, setting OPA to be the source of truth would >> > introduce latency (based on Casey’s comments) and will not allow to >> > set policies (based on Seena). >> > The first one brings us towards harder latency and especially >> > depending on extern systems resource capability (assume central >> > resource as the idea is and therefor not necessarily really “in reach” >> > within an acceptable latency, routing in addition, etc.). The second >> > one says simply that this would break any existing compatibility with >> > clients and use cases. To me it looks not that good to loose on both ends. >> >> Agreed. Even if one has to opt-in to this broken s3 compatiblity, I'm >> skeptical that users will find this to be a compelling target for their >> applications. >> >> The existing prototype of OPA integration sends this authorization >> request to OPA -in addition to- radosgw's own authorization logic, where >> we consult any of our user/bucket policies or ACLs that apply. In this >> model, OPA is not the only source of truth. It just has the opportunity >> to deny access that we would otherwise grant, so it doesn't require that >> we break compatibility with any S3 features that conflict with OPA's >> view of policy. >> >> Were we to change this so that OPA was the only source of truth, then >> we'd be left with two bad options: either reject all requests to modify >> policy and break existing applications, or send all policy/ACL >> information to OPA and require every OPA policy script to implement >> s3-compatible enforcement of them. I also don't see any benefit to this >> model - why, if an client wants to use s3 policy to restrict a certain >> access, would OPA want to override that and grant access instead? >> >> > I could live more with the latency issue but wouldn’t like it. >> > For the second, I can understand the idea of having simplification for >> > auditing the access but I’m not that convinced to take the burden of >> > being “the special” one that nobody wants to work with. So, I would >> > love to see the full fledged support of setting the policy by clients, >> > no matter what the result would be in terms of implementing it to >> > interact with OPA. Instead, having an additional requirement to >> > implement additional handling to set policies different from what S3 >> > actually provides would require special clients first and secondly an >> > additional path to OPA with all the additional burden to tweak >> > security to allow this path to OPA. I feel that the first wouldn’t >> > happen (special clients) and the second in practice not either because >> > of security constraints by the OPA admin folks. >> > >> > G, >> > -matt >> > >> > —————————————————— >> > Matthias Muench >> > Senior Specialist Solution Architect >> > EMEA Storage Specialist >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> >> > Phone: +49-160-92654111 <tel:+49-160-92654111> >> > >> > Red Hat GmbH >> > Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> >> > 85630 Grasbrunn <x-apple-data-detectors://2/1> >> > Germany <x-apple-data-detectors://2/1> >> > _______________________________________________________________________ >> > Red Hat GmbH, http://www.de.redhat.com <http://de.redhat.com/> · >> > Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen >> > HRB 153243 · Managing Directors: Charles Cachera, Michael O'Neill, Tom >> > Savage, Eric Shander >> > >> >> On Jan 28, 2020, at 15:02, Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote: >> >> >> >>  >> >> Amazon AWS S3 has two type of policies. One from bucket policy and >> >> one form IAM. I think it could be better to have two policies models >> >> in Ceph one from bucket policy and one form OPA if its enable. >> >> So if you are okay we can change the PR to make bucket policy enabled >> >> when OPA is enabled, too. Because now bucket policies not working >> >> when OPA integration is enabled. >> >> >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >> >> >> >>     Matt When OPA integration is enabled S3 policies doesn’t work! If >> >>     you want them to be worked we should bypass S3 policies to OPA >> >>     for being applied and worked. >> >>     Here we have conflict in OPA integration with S3 policies! >> >> >> >>     On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin >> >>     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> wrote: >> >> >> >>         My take so far is that this is not a bug, and I'd like not to >> >>         introduce special-case logic to override or suppress >> >>         processing of >> >>         native policy. >> >> >> >>         Matt >> >> >> >>         On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >> >>         > >> >>         > I think it's very good that Ceph export its authorization >> >>         and we could have external source of truth with it. S3 >> >>         policies can transport to OPA and updates by users set/del >> >>         policies. >> >>         > But now we have conflict with OPA integration and S3 >> >>         policies which is set when OPA integration is enabled, aren't >> >>         work. >> >>         > >> >>         > Can you all please help to fix this bug? >> >>         > >> >>         > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >> >>         >> >> >>         >> Hi all. >> >>         >> >> >>         >> Any updates here? >> >>         >> >> >>         >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >> >>         >>> >> >>         >>> OPA can be used in companies that uses many services like >> >>         k8s, Ceph,... and want to have one central point for >> >>         authorizing users so they can maintenance their access for >> >>         each user on each service for example and etc. It’s just a >> >>         use case and so it’s really good to have it. I think this is >> >>         the biggest use case for having OPA in products that gets an >> >>         option to centralize authorizing for all types of services. >> >>         >>> >> >>         >>> Performance for this model is issue like having keystone >> >>         with Ceph. So I think it’s based on users that active this >> >>         integrations at all. >> >>         >>> >> >>         >>> The model for writing policies to radosgw isn’t really >> >>         good I think because of the reason above if this accrued >> >>         there is always two copies of policies and it doesn’t sounds >> >>         good for maintaining. >> >>         >>> >> >>         >>> If bucket policy disable, s3 clients like boto3 and etc >> >>         will not work for setting polices but I think when someone is >> >>         enabling OPA for authorizing it will also have an API for >> >>         his/her OPA server to set/del policies and they can call >> >>         these APIs to set/del policies. >> >>         >>> And for extensions like PublicAccessBlock, it will >> >>         disable because OPA is just authorizing requests and Ceph >> >>         doesn’t authorize any request when OPA integration is enabled >> >>         so OPA should handle any incoming policies were made by S3 >> >>         policies. So it doesn’t make conflicts and if OPA integration >> >>         is enabled it won’t work as we return 405 on each set/del >> >>         policies requests and if OPA is disabled users can use this >> >>         policies. >> >>         >>> >> >>         >>> >> >>         >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley >> >>         <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: >> >>         >>>> >> >>         >>>> I am a big fan of the IAM policy documents, both because >> >>         of the >> >>         >>>> flexibility and expressiveness they provide, and because >> >>         they're in a >> >>         >>>> format that all of our s3 clients understand. >> >>         >>>> >> >>         >>>> I'm not familiar enough with OPA to know what extra >> >>         capabilities it >> >>         >>>> offers that IAM policy cannot, but I have serious >> >>         concerns about the >> >>         >>>> performance and scalability of a model where radosgw has >> >>         to send >> >>         >>>> blocking RPCs to OPA in order to authorize each and >> >>         every request. >> >>         >>>> >> >>         >>>> On the other hand, consider a model where a Policy Agent >> >>         exercises its >> >>         >>>> control over authorization by writing IAM documents to >> >>         radosgw, which we >> >>         >>>> use to cheaply authorize requests out of our metadata >> >>         cache. I would >> >>         >>>> imagine that this model could cover a lot of interesting >> >>         use cases, >> >>         >>>> without breaking support for existing s3 applications >> >>         that rely on >> >>         >>>> bucket policy - as the proposal to reject >> >>         PutBucketPolicy requests would. >> >>         >>>> >> >>         >>>> Is this something that OPA could feasibly do? >> >>         >>>> >> >>         >>>> For use cases that aren't supported by the existing >> >>         policy grammar, >> >>         >>>> we're open to maintaining extensions to these documents. >> >>         We already >> >>         >>>> implement a number of s3 extensions [1][2] that are >> >>         easily accessible >> >>         >>>> via python/boto and the aws cli. >> >>         >>>> >> >>         >>>> But a model where radosgw outsources authorization >> >>         entirely is a hard >> >>         >>>> sell, because it conflicts with feature development >> >>         going forward. One >> >>         >>>> example would be support for PublicAccessBlock [3], >> >>         where radosgw needs >> >>         >>>> full visibility into policy to detect cases where public >> >>         access would be >> >>         >>>> granted. >> >>         >>>> >> >>         >>>> [1] >> >>         >>>> >> >> https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >> >>         >>>> >> >>         >>>> [2] >> >>         >>>> >> >> https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >> >>         >>>> >> >>         >>>> [3] https://github.com/ceph/ceph/pull/30033 >> >>         >>>> >> >>         >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: >> >>         >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >> >>         >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@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@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >> >>         <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >> >>         <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >> >>         >>>> >  >>>> > To unsubscribe send an email to >> >> dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >> >>         >>>> >  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >> >>         >>>> > >> >>         >>>> > >> >>         >>>> > _______________________________________________ >> >>         >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >> >>         >>>> > To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >> >>         >>>> _______________________________________________ >> >>         >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >> >>         >>>> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >> >> >> >> _______________________________________________ >> >> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >> >> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@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

On 1/30/20 2:18 PM, Seena Fallah wrote:

Hi Casey,

The main problem now is when OPA integration is enabled bucket policies aren’t work! I have checked AWS S3 that what is doing when both bucket policy and IAM policy (the policy is set with AWS panel in IAM section) is set it will OR between two of them so now in radosgw S3 we don’t have this feature and bucket policies won’t work when OPA integration is enabled.

So I think it’s better to active this feature and enabled bucket policy when OpA integration is enabled.

There is two solutions here in this discussion for enabling bucket policy on OPA integration: 1. Send bucket policy on set/del actions to OPA server to be apply on OPA policy rules so in this case the source of truth will be OPA (the state that we have now in OPA integration) and so these policies that sent from bucket policy will be applied. 2. OR between bucket policy and OPA policy like AWS S3. So there is two source of truth in this case and if any of them deny the request, the request will be denied.

What you described here in 2. is exactly how it currently works.

Do have any other solutions we have here and which of these solutions do you prefer to have?

On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Hi Seena,

I think it would probably help if you could describe your use case here, and what role you want OPA to play in the interpretation of these bucket policies. In other words, what is it that your OPA policy is doing with these bucket policy documents that shouldn't be done within radosgw?

On 1/30/20 1:09 AM, Seena Fallah wrote: > So Matt what should we have done with bucket policy if we enable OPA > integration? > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> wrote: > >     I think we should not be introducing new special case behavior, nor >     sending policy documents to OPA, which from what we have heard and >     read, intends to make no use of them. > >     Matt > >     On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >     > >     > I think it’s better to OR between two of the bucket policies and >     OPA policies. So if one of them reject certain access the request >     will reject as AWS do on its IAM and bucket policy. >     > Are you okay with this idea? >     > >     > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley >     <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: >     >> >     >> >     >> On 1/28/20 2:45 PM, Matthias Muench wrote: >     >> > Hi, >     >> > I think making Ceph special to what the rest of the clients >     in the >     >> > world would expect would be a bit off the idea of providing >     S3 like >     >> > service. >     >> > To my understanding, setting OPA to be the source of truth would >     >> > introduce latency (based on Casey’s comments) and will not >     allow to >     >> > set policies (based on Seena). >     >> > The first one brings us towards harder latency and especially >     >> > depending on extern systems resource capability (assume central >     >> > resource as the idea is and therefor not necessarily really >     “in reach” >     >> > within an acceptable latency, routing in addition, etc.). The >     second >     >> > one says simply that this would break any existing >     compatibility with >     >> > clients and use cases. To me it looks not that good to loose >     on both ends. >     >> >     >> Agreed. Even if one has to opt-in to this broken s3 >     compatiblity, I'm >     >> skeptical that users will find this to be a compelling target >     for their >     >> applications. >     >> >     >> The existing prototype of OPA integration sends this authorization >     >> request to OPA -in addition to- radosgw's own authorization >     logic, where >     >> we consult any of our user/bucket policies or ACLs that apply. >     In this >     >> model, OPA is not the only source of truth. It just has the >     opportunity >     >> to deny access that we would otherwise grant, so it doesn't >     require that >     >> we break compatibility with any S3 features that conflict with >     OPA's >     >> view of policy. >     >> >     >> Were we to change this so that OPA was the only source of >     truth, then >     >> we'd be left with two bad options: either reject all requests >     to modify >     >> policy and break existing applications, or send all policy/ACL >     >> information to OPA and require every OPA policy script to implement >     >> s3-compatible enforcement of them. I also don't see any benefit >     to this >     >> model - why, if an client wants to use s3 policy to restrict a >     certain >     >> access, would OPA want to override that and grant access instead? >     >> >     >> > I could live more with the latency issue but wouldn’t like it. >     >> > For the second, I can understand the idea of having >     simplification for >     >> > auditing the access but I’m not that convinced to take the >     burden of >     >> > being “the special” one that nobody wants to work with. So, I >     would >     >> > love to see the full fledged support of setting the policy by >     clients, >     >> > no matter what the result would be in terms of implementing it to >     >> > interact with OPA. Instead, having an additional requirement to >     >> > implement additional handling to set policies different from >     what S3 >     >> > actually provides would require special clients first and >     secondly an >     >> > additional path to OPA with all the additional burden to tweak >     >> > security to allow this path to OPA. I feel that the first >     wouldn’t >     >> > happen (special clients) and the second in practice not >     either because >     >> > of security constraints by the OPA admin folks. >     >> > >     >> > G, >     >> > -matt >     >> > >     >> > —————————————————— >     >> > Matthias Muench >     >> > Senior Specialist Solution Architect >     >> > EMEA Storage Specialist >     >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> >     >> > Phone: +49-160-92654111 <tel:+49-160-92654111> >     >> > >     >> > Red Hat GmbH >     >> > Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> >     >> > 85630 Grasbrunn <x-apple-data-detectors://2/1> >     >> > Germany <x-apple-data-detectors://2/1> >     >> > >  _______________________________________________________________________ >     >> > Red Hat GmbH, http://www.de.redhat.com <http://de.redhat.com/> · >     >> > Registered seat: Grasbrunn, Commercial register: Amtsgericht >     Muenchen >     >> > HRB 153243 · Managing Directors: Charles Cachera, Michael >     O'Neill, Tom >     >> > Savage, Eric Shander >     >> > >     >> >> On Jan 28, 2020, at 15:02, Seena Fallah >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: >     >> >> >     >> >>  >     >> >> Amazon AWS S3 has two type of policies. One from bucket >     policy and >     >> >> one form IAM. I think it could be better to have two >     policies models >     >> >> in Ceph one from bucket policy and one form OPA if its enable. >     >> >> So if you are okay we can change the PR to make bucket >     policy enabled >     >> >> when OPA is enabled, too. Because now bucket policies not >     working >     >> >> when OPA integration is enabled. >     >> >> >     >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >> >> >     >> >>     Matt When OPA integration is enabled S3 policies doesn’t >     work! If >     >> >>     you want them to be worked we should bypass S3 policies >     to OPA >     >> >>     for being applied and worked. >     >> >>     Here we have conflict in OPA integration with S3 policies! >     >> >> >     >> >>     On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin >     >> >>     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> wrote: >     >> >> >     >> >>         My take so far is that this is not a bug, and I'd >     like not to >     >> >>         introduce special-case logic to override or suppress >     >> >>         processing of >     >> >>         native policy. >     >> >> >     >> >>         Matt >     >> >> >     >> >>         On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >> >>         > >     >> >>         > I think it's very good that Ceph export its >     authorization >     >> >>         and we could have external source of truth with it. S3 >     >> >>         policies can transport to OPA and updates by users >     set/del >     >> >>         policies. >     >> >>         > But now we have conflict with OPA integration and S3 >     >> >>         policies which is set when OPA integration is >     enabled, aren't >     >> >>         work. >     >> >>         > >     >> >>         > Can you all please help to fix this bug? >     >> >>         > >     >> >>         > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >> >>         >> >     >> >>         >> Hi all. >     >> >>         >> >     >> >>         >> Any updates here? >     >> >>         >> >     >> >>         >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >> >>         >>> >     >> >>         >>> OPA can be used in companies that uses many >     services like >     >> >>         k8s, Ceph,... and want to have one central point for >     >> >>         authorizing users so they can maintenance their >     access for >     >> >>         each user on each service for example and etc. It’s >     just a >     >> >>         use case and so it’s really good to have it. I think >     this is >     >> >>         the biggest use case for having OPA in products that >     gets an >     >> >>         option to centralize authorizing for all types of >     services. >     >> >>         >>> >     >> >>         >>> Performance for this model is issue like having >     keystone >     >> >>         with Ceph. So I think it’s based on users that >     active this >     >> >>         integrations at all. >     >> >>         >>> >     >> >>         >>> The model for writing policies to radosgw isn’t >     really >     >> >>         good I think because of the reason above if this accrued >     >> >>         there is always two copies of policies and it >     doesn’t sounds >     >> >>         good for maintaining. >     >> >>         >>> >     >> >>         >>> If bucket policy disable, s3 clients like boto3 >     and etc >     >> >>         will not work for setting polices but I think when >     someone is >     >> >>         enabling OPA for authorizing it will also have an >     API for >     >> >>         his/her OPA server to set/del policies and they can call >     >> >>         these APIs to set/del policies. >     >> >>         >>> And for extensions like PublicAccessBlock, it will >     >> >>         disable because OPA is just authorizing requests and >     Ceph >     >> >>         doesn’t authorize any request when OPA integration >     is enabled >     >> >>         so OPA should handle any incoming policies were made >     by S3 >     >> >>         policies. So it doesn’t make conflicts and if OPA >     integration >     >> >>         is enabled it won’t work as we return 405 on each >     set/del >     >> >>         policies requests and if OPA is disabled users can >     use this >     >> >>         policies. >     >> >>         >>> >     >> >>         >>> >     >> >>         >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley >     >> >>         <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: >     >> >>         >>>> >     >> >>         >>>> I am a big fan of the IAM policy documents, >     both because >     >> >>         of the >     >> >>         >>>> flexibility and expressiveness they provide, >     and because >     >> >>         they're in a >     >> >>         >>>> format that all of our s3 clients understand. >     >> >>         >>>> >     >> >>         >>>> I'm not familiar enough with OPA to know what extra >     >> >>         capabilities it >     >> >>         >>>> offers that IAM policy cannot, but I have serious >     >> >>         concerns about the >     >> >>         >>>> performance and scalability of a model where >     radosgw has >     >> >>         to send >     >> >>         >>>> blocking RPCs to OPA in order to authorize each and >     >> >>         every request. >     >> >>         >>>> >     >> >>         >>>> On the other hand, consider a model where a >     Policy Agent >     >> >>         exercises its >     >> >>         >>>> control over authorization by writing IAM >     documents to >     >> >>         radosgw, which we >     >> >>         >>>> use to cheaply authorize requests out of our >     metadata >     >> >>         cache. I would >     >> >>         >>>> imagine that this model could cover a lot of >     interesting >     >> >>         use cases, >     >> >>         >>>> without breaking support for existing s3 >     applications >     >> >>         that rely on >     >> >>         >>>> bucket policy - as the proposal to reject >     >> >>         PutBucketPolicy requests would. >     >> >>         >>>> >     >> >>         >>>> Is this something that OPA could feasibly do? >     >> >>         >>>> >     >> >>         >>>> For use cases that aren't supported by the existing >     >> >>         policy grammar, >     >> >>         >>>> we're open to maintaining extensions to these >     documents. >     >> >>         We already >     >> >>         >>>> implement a number of s3 extensions [1][2] that are >     >> >>         easily accessible >     >> >>         >>>> via python/boto and the aws cli. >     >> >>         >>>> >     >> >>         >>>> But a model where radosgw outsources authorization >     >> >>         entirely is a hard >     >> >>         >>>> sell, because it conflicts with feature development >     >> >>         going forward. One >     >> >>         >>>> example would be support for PublicAccessBlock [3], >     >> >>         where radosgw needs >     >> >>         >>>> full visibility into policy to detect cases >     where public >     >> >>         access would be >     >> >>         >>>> granted. >     >> >>         >>>> >     >> >>         >>>> [1] >     >> >>         >>>> >     >> >> > https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >     >> >>         >>>> >     >> >>         >>>> [2] >     >> >>         >>>> >     >> >> > https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >     >> >>         >>>> >     >> >>         >>>> [3] https://github.com/ceph/ceph/pull/30033 >     >> >>         >>>> >     >> >>         >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: >     >> >>         >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >> >>         >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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 >     >> >> <https://www.google.com/maps/search/%C2%A0?entry=gmail&source=g>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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> >     >> >>         <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >> >>         <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >> >>         <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >> >>         <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >     >> >>         >>>> >  >>>> > To unsubscribe send an email to >     >> >> dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >> >>         >>>> >  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >     >> >>         >>>> > >     >> >>         >>>> > >     >> >>         >>>> > _______________________________________________ >     >> >>         >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     >> >>         >>>> > To unsubscribe send an email to > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >> >>         >>>> _______________________________________________ >     >> >>         >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     >> >>         >>>> To unsubscribe send an email to > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     >> >>         <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >     >> >> >     >> >> _______________________________________________ >     >> >> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >> >> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >

I should also mention that if we get access to bucket via bucket policy and reject it via AWS IAM, the request will reject so I think we should make a new behavior at what we should do with this two source of truth? On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah <seenafallah@gmail.com> wrote:

Yes but the main problem is when the policy isn't set in AWS IAM for example a user has only AmazonS3ReadOnlyAccess and we give PutObject policy via bucket policy, user can put object to that bucket but in radosgw, OPA will deny this process because there is only ReadOnlyAccess to that bucket for user and radosgw will not check bucket policy that gave access to user. I think we should weight bucket policy over OPA so if bucket policy accept that request it doesn't need to be checked with OPA BUT if there is no policy according to that request it should check by OPA because if the policy according to that request isn't set bucket policy will reject that request so it against failed!

On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley <cbodley@redhat.com> wrote:

...

On 1/30/20 2:18 PM, Seena Fallah wrote:

...

Hi Casey,

The main problem now is when OPA integration is enabled bucket policies aren’t work! I have checked AWS S3 that what is doing when both bucket policy and IAM policy (the policy is set with AWS panel in IAM section) is set it will OR between two of them so now in radosgw S3 we don’t have this feature and bucket policies won’t work when OPA integration is enabled.

So I think it’s better to active this feature and enabled bucket policy when OpA integration is enabled.

There is two solutions here in this discussion for enabling bucket policy on OPA integration: 1. Send bucket policy on set/del actions to OPA server to be apply on OPA policy rules so in this case the source of truth will be OPA (the state that we have now in OPA integration) and so these policies that sent from bucket policy will be applied. 2. OR between bucket policy and OPA policy like AWS S3. So there is two source of truth in this case and if any of them deny the request, the request will be denied.

What you described here in 2. is exactly how it currently works.

...

Do have any other solutions we have here and which of these solutions do you prefer to have?

On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Hi Seena,

I think it would probably help if you could describe your use case here, and what role you want OPA to play in the interpretation of these bucket policies. In other words, what is it that your OPA policy is doing with these bucket policy documents that shouldn't be done within radosgw?

On 1/30/20 1:09 AM, Seena Fallah wrote: > So Matt what should we have done with bucket policy if we enable OPA > integration? > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> wrote: > > I think we should not be introducing new special case behavior, nor > sending policy documents to OPA, which from what we have heard and > read, intends to make no use of them. > > Matt > > On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>

wrote:

...

> > > > I think it’s better to OR between two of the bucket policies and > OPA policies. So if one of them reject certain access the request > will reject as AWS do on its IAM and bucket policy. > > Are you okay with this idea? > > > > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > >> > >> > >> On 1/28/20 2:45 PM, Matthias Muench wrote: > >> > Hi, > >> > I think making Ceph special to what the rest of the

clients

...

> in the > >> > world would expect would be a bit off the idea of

providing

...

> S3 like > >> > service. > >> > To my understanding, setting OPA to be the source of truth would > >> > introduce latency (based on Casey’s comments) and will

not

...

> allow to > >> > set policies (based on Seena). > >> > The first one brings us towards harder latency and especially > >> > depending on extern systems resource capability (assume central > >> > resource as the idea is and therefor not necessarily

really

...

> “in reach” > >> > within an acceptable latency, routing in addition, etc.). The > second > >> > one says simply that this would break any existing > compatibility with > >> > clients and use cases. To me it looks not that good to loose > on both ends. > >> > >> Agreed. Even if one has to opt-in to this broken s3 > compatiblity, I'm > >> skeptical that users will find this to be a compelling

target

...

> for their > >> applications. > >> > >> The existing prototype of OPA integration sends this authorization > >> request to OPA -in addition to- radosgw's own authorization > logic, where > >> we consult any of our user/bucket policies or ACLs that apply. > In this > >> model, OPA is not the only source of truth. It just has the > opportunity > >> to deny access that we would otherwise grant, so it doesn't > require that > >> we break compatibility with any S3 features that conflict with > OPA's > >> view of policy. > >> > >> Were we to change this so that OPA was the only source of > truth, then > >> we'd be left with two bad options: either reject all

requests

...

> to modify > >> policy and break existing applications, or send all policy/ACL > >> information to OPA and require every OPA policy script to implement > >> s3-compatible enforcement of them. I also don't see any benefit > to this > >> model - why, if an client wants to use s3 policy to restrict a > certain > >> access, would OPA want to override that and grant access instead? > >> > >> > I could live more with the latency issue but wouldn’t like it. > >> > For the second, I can understand the idea of having > simplification for > >> > auditing the access but I’m not that convinced to take

the

...

> burden of > >> > being “the special” one that nobody wants to work with. So, I > would > >> > love to see the full fledged support of setting the policy by > clients, > >> > no matter what the result would be in terms of implementing it to > >> > interact with OPA. Instead, having an additional requirement to > >> > implement additional handling to set policies different from > what S3 > >> > actually provides would require special clients first and > secondly an > >> > additional path to OPA with all the additional burden to tweak > >> > security to allow this path to OPA. I feel that the first > wouldn’t > >> > happen (special clients) and the second in practice not > either because > >> > of security constraints by the OPA admin folks. > >> > > >> > G, > >> > -matt > >> > > >> > —————————————————— > >> > Matthias Muench > >> > Senior Specialist Solution Architect > >> > EMEA Storage Specialist > >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > >> > Phone: +49-160-92654111 <tel:+49-160-92654111> > >> > > >> > Red Hat GmbH > >> > Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> > >> > 85630 Grasbrunn <x-apple-data-detectors://2/1> > >> > Germany <x-apple-data-detectors://2/1> > >> > >

_______________________________________________________________________

...

> >> > Red Hat GmbH, http://www.de.redhat.com <http://de.redhat.com/> · > >> > Registered seat: Grasbrunn, Commercial register: Amtsgericht > Muenchen > >> > HRB 153243 · Managing Directors: Charles Cachera, Michael > O'Neill, Tom > >> > Savage, Eric Shander > >> > > >> >> On Jan 28, 2020, at 15:02, Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>

wrote:

...

> >> >> > >> >>  > >> >> Amazon AWS S3 has two type of policies. One from bucket > policy and > >> >> one form IAM. I think it could be better to have two > policies models > >> >> in Ceph one from bucket policy and one form OPA if its enable. > >> >> So if you are okay we can change the PR to make bucket > policy enabled > >> >> when OPA is enabled, too. Because now bucket policies

not

...

> working > >> >> when OPA integration is enabled. > >> >> > >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: > >> >> > >> >> Matt When OPA integration is enabled S3 policies doesn’t > work! If > >> >> you want them to be worked we should bypass S3 policies > to OPA > >> >> for being applied and worked. > >> >> Here we have conflict in OPA integration with S3 policies! > >> >> > >> >> On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin > >> >> <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> wrote: > >> >> > >> >> My take so far is that this is not a bug, and

I'd

...

> like not to > >> >> introduce special-case logic to override or suppress > >> >> processing of > >> >> native policy. > >> >> > >> >> Matt > >> >> > >> >> On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah > >> >> <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: > >> >> > > >> >> > I think it's very good that Ceph export its > authorization > >> >> and we could have external source of truth with it. S3 > >> >> policies can transport to OPA and updates by

users

...

> set/del > >> >> policies. > >> >> > But now we have conflict with OPA integration and S3 > >> >> policies which is set when OPA integration is > enabled, aren't > >> >> work. > >> >> > > >> >> > Can you all please help to fix this bug? > >> >> > > >> >> > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah > >> >> <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: > >> >> >> > >> >> >> Hi all. > >> >> >> > >> >> >> Any updates here? > >> >> >> > >> >> >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah > >> >> <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: > >> >> >>> > >> >> >>> OPA can be used in companies that uses many > services like > >> >> k8s, Ceph,... and want to have one central point for > >> >> authorizing users so they can maintenance their > access for > >> >> each user on each service for example and etc. It’s > just a > >> >> use case and so it’s really good to have it. I think > this is > >> >> the biggest use case for having OPA in products that > gets an > >> >> option to centralize authorizing for all types

of

...

> services. > >> >> >>> > >> >> >>> Performance for this model is issue like having > keystone > >> >> with Ceph. So I think it’s based on users that > active this > >> >> integrations at all. > >> >> >>> > >> >> >>> The model for writing policies to radosgw isn’t > really > >> >> good I think because of the reason above if this accrued > >> >> there is always two copies of policies and it > doesn’t sounds > >> >> good for maintaining. > >> >> >>> > >> >> >>> If bucket policy disable, s3 clients like boto3 > and etc > >> >> will not work for setting polices but I think

when

...

> someone is > >> >> enabling OPA for authorizing it will also have

an

...

> API for > >> >> his/her OPA server to set/del policies and they can call > >> >> these APIs to set/del policies. > >> >> >>> And for extensions like PublicAccessBlock, it will > >> >> disable because OPA is just authorizing requests and > Ceph > >> >> doesn’t authorize any request when OPA

integration

...

> is enabled > >> >> so OPA should handle any incoming policies were made > by S3 > >> >> policies. So it doesn’t make conflicts and if

OPA

...

> integration > >> >> is enabled it won’t work as we return 405 on

each

...

> set/del > >> >> policies requests and if OPA is disabled users

can

...

> use this > >> >> policies. > >> >> >>> > >> >> >>> > >> >> >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley > >> >> <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: > >> >> >>>> > >> >> >>>> I am a big fan of the IAM policy documents, > both because > >> >> of the > >> >> >>>> flexibility and expressiveness they

provide,

...

> and because > >> >> they're in a > >> >> >>>> format that all of our s3 clients

understand.

...

> >> >> >>>> > >> >> >>>> I'm not familiar enough with OPA to know what extra > >> >> capabilities it > >> >> >>>> offers that IAM policy cannot, but I have serious > >> >> concerns about the > >> >> >>>> performance and scalability of a model

where

...

> radosgw has > >> >> to send > >> >> >>>> blocking RPCs to OPA in order to authorize each and > >> >> every request. > >> >> >>>> > >> >> >>>> On the other hand, consider a model where a > Policy Agent > >> >> exercises its > >> >> >>>> control over authorization by writing IAM > documents to > >> >> radosgw, which we > >> >> >>>> use to cheaply authorize requests out of

our

...

> metadata > >> >> cache. I would > >> >> >>>> imagine that this model could cover a lot

of

...

> interesting > >> >> use cases, > >> >> >>>> without breaking support for existing s3 > applications > >> >> that rely on > >> >> >>>> bucket policy - as the proposal to reject > >> >> PutBucketPolicy requests would. > >> >> >>>> > >> >> >>>> Is this something that OPA could feasibly

do?

...

> >> >> >>>> > >> >> >>>> For use cases that aren't supported by the existing > >> >> policy grammar, > >> >> >>>> we're open to maintaining extensions to

these

...

> documents. > >> >> We already > >> >> >>>> implement a number of s3 extensions [1][2] that are > >> >> easily accessible > >> >> >>>> via python/boto and the aws cli. > >> >> >>>> > >> >> >>>> But a model where radosgw outsources authorization > >> >> entirely is a hard > >> >> >>>> sell, because it conflicts with feature development > >> >> going forward. One > >> >> >>>> example would be support for PublicAccessBlock [3], > >> >> where radosgw needs > >> >> >>>> full visibility into policy to detect cases > where public > >> >> access would be > >> >> >>>> granted. > >> >> >>>> > >> >> >>>> [1] > >> >> >>>> > >> >> >

https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions

...

> >> >> >>>> > >> >> >>>> [2] > >> >> >>>> > >> >> >

https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras...

...

> >> >> >>>> > >> >> >>>> [3]

https://github.com/ceph/ceph/pull/30033

...

> >> >> >>>> > >> >> >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: > >> >> >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> >> >> >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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 > >> >> <https://www.google.com/maps/search/%C2%A0?entry=gmail&source=g 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@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > >> >> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > >> >> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> > <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> > >> >> <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> > <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > >> >> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > >> >> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> > <mailto:dev@ceph.io <mailto:dev@ceph.io>> > >> >> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> > <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> > >> >> >>>> > >>>> > To unsubscribe send an email to > >> >> dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> > >> >> >>>> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> > >> >> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > _______________________________________________ > >> >> >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> > <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> > >> >> >>>> > To unsubscribe send an email to > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> > >> >> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> > >> >> >>>> _______________________________________________ > >> >> >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> > <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> > >> >> >>>> To unsubscribe send an email to > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> > >> >> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 > >> >> > >> >> _______________________________________________ > >> >> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> > >> >> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> > <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >

I'm confused by your references to AWS IAM. Are you talking about radosgw user policy? Or are you trying to implement IAM policy inside of OPA? On 2/5/20 8:54 AM, Seena Fallah wrote:

Hi all.

Any updates here? :)

On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote:

I should also mention that if we get access to bucket via bucket policy and reject it via AWS IAM, the request will reject so I think we should make a new behavior at what we should do with this two source of truth?

On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote:

Yes but the main problem is when the policy isn't set in AWS IAM for example a user has only AmazonS3ReadOnlyAccess and we give PutObject policy via bucket policy, user can put object to that bucket but in radosgw, OPA will deny this process because there is only ReadOnlyAccess to that bucket for user and radosgw will not check bucket policy that gave access to user. I think we should weight bucket policy over OPA so if bucket policy accept that request it doesn't need to be checked with OPA BUT if there is no policy according to that request it should check by OPA because if the policy according to that request isn't set bucket policy will reject that request so it against failed!

On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

On 1/30/20 2:18 PM, Seena Fallah wrote: > Hi Casey, > > The main problem now is when OPA integration is enabled bucket > policies aren’t work! > I have checked AWS S3 that what is doing when both bucket policy and > IAM policy (the policy is set with AWS panel in IAM section) is set it > will OR between two of them so now in radosgw S3 we don’t have this > feature and bucket policies won’t work when OPA integration is enabled. > > So I think it’s better to active this feature and enabled bucket > policy when OpA integration is enabled. > > There is two solutions here in this discussion for enabling bucket > policy on OPA integration: > 1. Send bucket policy on set/del actions to OPA server to be apply on > OPA policy rules so in this case the source of truth will be OPA (the > state that we have now in OPA integration) and so these policies that > sent from bucket policy will be applied. > 2. OR between bucket policy and OPA policy like AWS S3. So there is > two source of truth in this case and if any of them deny the request, > the request will be denied.

What you described here in 2. is exactly how it currently works.

> > Do have any other solutions we have here and which of these solutions > do you prefer to have? > > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > >     Hi Seena, > >     I think it would probably help if you could describe your use case >     here, >     and what role you want OPA to play in the interpretation of these >     bucket >     policies. In other words, what is it that your OPA policy is doing >     with >     these bucket policy documents that shouldn't be done within radosgw? > >     On 1/30/20 1:09 AM, Seena Fallah wrote: >     > So Matt what should we have done with bucket policy if we enable >     OPA >     > integration? >     > >     > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin >     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> wrote: >     > >     >     I think we should not be introducing new special case >     behavior, nor >     >     sending policy documents to OPA, which from what we have >     heard and >     >     read, intends to make no use of them. >     > >     >     Matt >     > >     >     On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >     > >     >     > I think it’s better to OR between two of the bucket >     policies and >     >     OPA policies. So if one of them reject certain access the >     request >     >     will reject as AWS do on its IAM and bucket policy. >     >     > Are you okay with this idea? >     >     > >     >     > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley >     >     <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: >     >     >> >     >     >> >     >     >> On 1/28/20 2:45 PM, Matthias Muench wrote: >     >     >> > Hi, >     >     >> > I think making Ceph special to what the rest of the clients >     >     in the >     >     >> > world would expect would be a bit off the idea of providing >     >     S3 like >     >     >> > service. >     >     >> > To my understanding, setting OPA to be the source of >     truth would >     >     >> > introduce latency (based on Casey’s comments) and will not >     >     allow to >     >     >> > set policies (based on Seena). >     >     >> > The first one brings us towards harder latency and >     especially >     >     >> > depending on extern systems resource capability (assume >     central >     >     >> > resource as the idea is and therefor not necessarily really >     >     “in reach” >     >     >> > within an acceptable latency, routing in addition, >     etc.). The >     >     second >     >     >> > one says simply that this would break any existing >     >     compatibility with >     >     >> > clients and use cases. To me it looks not that good to >     loose >     >     on both ends. >     >     >> >     >     >> Agreed. Even if one has to opt-in to this broken s3 >     >     compatiblity, I'm >     >     >> skeptical that users will find this to be a compelling target >     >     for their >     >     >> applications. >     >     >> >     >     >> The existing prototype of OPA integration sends this >     authorization >     >     >> request to OPA -in addition to- radosgw's own authorization >     >     logic, where >     >     >> we consult any of our user/bucket policies or ACLs that >     apply. >     >     In this >     >     >> model, OPA is not the only source of truth. It just has the >     >     opportunity >     >     >> to deny access that we would otherwise grant, so it doesn't >     >     require that >     >     >> we break compatibility with any S3 features that conflict >     with >     >     OPA's >     >     >> view of policy. >     >     >> >     >     >> Were we to change this so that OPA was the only source of >     >     truth, then >     >     >> we'd be left with two bad options: either reject all requests >     >     to modify >     >     >> policy and break existing applications, or send all >     policy/ACL >     >     >> information to OPA and require every OPA policy script to >     implement >     >     >> s3-compatible enforcement of them. I also don't see any >     benefit >     >     to this >     >     >> model - why, if an client wants to use s3 policy to >     restrict a >     >     certain >     >     >> access, would OPA want to override that and grant access >     instead? >     >     >> >     >     >> > I could live more with the latency issue but wouldn’t >     like it. >     >     >> > For the second, I can understand the idea of having >     >     simplification for >     >     >> > auditing the access but I’m not that convinced to take the >     >     burden of >     >     >> > being “the special” one that nobody wants to work with. >     So, I >     >     would >     >     >> > love to see the full fledged support of setting the >     policy by >     >     clients, >     >     >> > no matter what the result would be in terms of >     implementing it to >     >     >> > interact with OPA. Instead, having an additional >     requirement to >     >     >> > implement additional handling to set policies different >     from >     >     what S3 >     >     >> > actually provides would require special clients first and >     >     secondly an >     >     >> > additional path to OPA with all the additional burden >     to tweak >     >     >> > security to allow this path to OPA. I feel that the first >     >     wouldn’t >     >     >> > happen (special clients) and the second in practice not >     >     either because >     >     >> > of security constraints by the OPA admin folks. >     >     >> > >     >     >> > G, >     >     >> > -matt >     >     >> > >     >     >> > —————————————————— >     >     >> > Matthias Muench >     >     >> > Senior Specialist Solution Architect >     >     >> > EMEA Storage Specialist >     >     >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >     >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> >     >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>> >     >     >> > Phone: +49-160-92654111 <tel:+49-160-92654111> >     >     >> > >     >     >> > Red Hat GmbH >     >     >> > Werner-von-Siemens-Ring 14 <x-apple-data-detectors://2/1> >     >     >> > 85630 Grasbrunn <x-apple-data-detectors://2/1> >     >     >> > Germany <x-apple-data-detectors://2/1> >     >     >> > >     > >   _______________________________________________________________________ >     >     >> > Red Hat GmbH, http://www.de.redhat.com >     <http://de.redhat.com/> · >     >     >> > Registered seat: Grasbrunn, Commercial register: >     Amtsgericht >     >     Muenchen >     >     >> > HRB 153243 · Managing Directors: Charles Cachera, Michael >     >     O'Neill, Tom >     >     >> > Savage, Eric Shander >     >     >> > >     >     >> >> On Jan 28, 2020, at 15:02, Seena Fallah >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     >     >> >> >     >     >> >>  >     >     >> >> Amazon AWS S3 has two type of policies. One from bucket >     >     policy and >     >     >> >> one form IAM. I think it could be better to have two >     >     policies models >     >     >> >> in Ceph one from bucket policy and one form OPA if its >     enable. >     >     >> >> So if you are okay we can change the PR to make bucket >     >     policy enabled >     >     >> >> when OPA is enabled, too. Because now bucket policies not >     >     working >     >     >> >> when OPA integration is enabled. >     >     >> >> >     >     >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >     >     >> >> >     >     >> >>     Matt When OPA integration is enabled S3 policies >     doesn’t >     >     work! If >     >     >> >>     you want them to be worked we should bypass S3 >     policies >     >     to OPA >     >     >> >>     for being applied and worked. >     >     >> >>     Here we have conflict in OPA integration with S3 >     policies! >     >     >> >> >     >     >> >>     On Tue, Jan 28, 2020 at 2:52 AM Matt Benjamin >     >     >> >>     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> wrote: >     >     >> >> >     >     >> >>         My take so far is that this is not a bug, and I'd >     >     like not to >     >     >> >>         introduce special-case logic to override or >     suppress >     >     >> >>         processing of >     >     >> >>         native policy. >     >     >> >> >     >     >> >>         Matt >     >     >> >> >     >     >> >>         On Mon, Jan 27, 2020 at 5:24 PM Seena Fallah >     >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >     >     >> >>         > >     >     >> >>         > I think it's very good that Ceph export its >     >     authorization >     >     >> >>         and we could have external source of truth >     with it. S3 >     >     >> >>         policies can transport to OPA and updates by users >     >     set/del >     >     >> >>         policies. >     >     >> >>         > But now we have conflict with OPA >     integration and S3 >     >     >> >>         policies which is set when OPA integration is >     >     enabled, aren't >     >     >> >>         work. >     >     >> >>         > >     >     >> >>         > Can you all please help to fix this bug? >     >     >> >>         > >     >     >> >>         > On Fri, Jan 24, 2020 at 1:05 PM Seena Fallah >     >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >     >     >> >>         >> >     >     >> >>         >> Hi all. >     >     >> >>         >> >     >     >> >>         >> Any updates here? >     >     >> >>         >> >     >     >> >>         >> On Tue, Jan 21, 2020 at 2:50 AM Seena Fallah >     >     >> >>         <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >     >     >> >>  >>> >     >     >> >>  >>> OPA can be used in companies that uses many >     >     services like >     >     >> >>         k8s, Ceph,... and want to have one central >     point for >     >     >> >>  authorizing users so they can maintenance their >     >     access for >     >     >> >>         each user on each service for example and etc. >     It’s >     >     just a >     >     >> >>         use case and so it’s really good to have it. I >     think >     >     this is >     >     >> >>         the biggest use case for having OPA in >     products that >     >     gets an >     >     >> >>         option to centralize authorizing for all types of >     >     services. >     >     >> >>  >>> >     >     >> >>  >>> Performance for this model is issue like >     having >     >     keystone >     >     >> >>         with Ceph. So I think it’s based on users that >     >     active this >     >     >> >>  integrations at all. >     >     >> >>  >>> >     >     >> >>  >>> The model for writing policies to radosgw >     isn’t >     >     really >     >     >> >>         good I think because of the reason above if >     this accrued >     >     >> >>         there is always two copies of policies and it >     >     doesn’t sounds >     >     >> >>         good for maintaining. >     >     >> >>  >>> >     >     >> >>  >>> If bucket policy disable, s3 clients like >     boto3 >     >     and etc >     >     >> >>         will not work for setting polices but I think when >     >     someone is >     >     >> >>         enabling OPA for authorizing it will also have an >     >     API for >     >     >> >>         his/her OPA server to set/del policies and >     they can call >     >     >> >>         these APIs to set/del policies. >     >     >> >>  >>> And for extensions like PublicAccessBlock, >     it will >     >     >> >>         disable because OPA is just authorizing >     requests and >     >     Ceph >     >     >> >>         doesn’t authorize any request when OPA integration >     >     is enabled >     >     >> >>         so OPA should handle any incoming policies >     were made >     >     by S3 >     >     >> >>         policies. So it doesn’t make conflicts and if OPA >     >     integration >     >     >> >>         is enabled it won’t work as we return 405 on each >     >     set/del >     >     >> >>         policies requests and if OPA is disabled users can >     >     use this >     >     >> >>         policies. >     >     >> >>  >>> >     >     >> >>  >>> >     >     >> >>  >>> On Tue, Jan 21, 2020 at 2:05 AM Casey Bodley >     >     >> >>         <cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >     >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> wrote: >     >     >> >>  >>>> >     >     >> >>  >>>> I am a big fan of the IAM policy documents, >     >     both because >     >     >> >>         of the >     >     >> >>  >>>> flexibility and expressiveness they provide, >     >     and because >     >     >> >>         they're in a >     >     >> >>  >>>> format that all of our s3 clients understand. >     >     >> >>  >>>> >     >     >> >>  >>>> I'm not familiar enough with OPA to know >     what extra >     >     >> >>  capabilities it >     >     >> >>  >>>> offers that IAM policy cannot, but I have >     serious >     >     >> >>         concerns about the >     >     >> >>  >>>> performance and scalability of a model where >     >     radosgw has >     >     >> >>         to send >     >     >> >>  >>>> blocking RPCs to OPA in order to >     authorize each and >     >     >> >>         every request. >     >     >> >>  >>>> >     >     >> >>  >>>> On the other hand, consider a model where a >     >     Policy Agent >     >     >> >>         exercises its >     >     >> >>  >>>> control over authorization by writing IAM >     >     documents to >     >     >> >>         radosgw, which we >     >     >> >>  >>>> use to cheaply authorize requests out of our >     >     metadata >     >     >> >>         cache. I would >     >     >> >>  >>>> imagine that this model could cover a lot of >     >     interesting >     >     >> >>         use cases, >     >     >> >>  >>>> without breaking support for existing s3 >     >     applications >     >     >> >>         that rely on >     >     >> >>  >>>> bucket policy - as the proposal to reject >     >     >> >>  PutBucketPolicy requests would. >     >     >> >>  >>>> >     >     >> >>  >>>> Is this something that OPA could feasibly do? >     >     >> >>  >>>> >     >     >> >>  >>>> For use cases that aren't supported by >     the existing >     >     >> >>         policy grammar, >     >     >> >>  >>>> we're open to maintaining extensions to these >     >     documents. >     >     >> >>         We already >     >     >> >>  >>>> implement a number of s3 extensions >     [1][2] that are >     >     >> >>         easily accessible >     >     >> >>  >>>> via python/boto and the aws cli. >     >     >> >>  >>>> >     >     >> >>  >>>> But a model where radosgw outsources >     authorization >     >     >> >>         entirely is a hard >     >     >> >>  >>>> sell, because it conflicts with feature >     development >     >     >> >>         going forward. One >     >     >> >>  >>>> example would be support for >     PublicAccessBlock [3], >     >     >> >>         where radosgw needs >     >     >> >>  >>>> full visibility into policy to detect cases >     >     where public >     >     >> >>         access would be >     >     >> >>  >>>> granted. >     >     >> >>  >>>> >     >     >> >>  >>>> [1] >     >     >> >>  >>>> >     >     >> >> >     > > https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >     >     >> >>  >>>> >     >     >> >>  >>>> [2] >     >     >> >>  >>>> >     >     >> >> >     > > https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >     >     >> >>  >>>> >     >     >> >>  >>>> [3] https://github.com/ceph/ceph/pull/30033 >     >     >> >>  >>>> >     >     >> >>  >>>> On 1/20/20 12:21 PM, Seena Fallah wrote: >     >     >> >>  >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >     >> >>  >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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 >     >     >> >> >     <https://www.google.com/maps/search/%C2%A0?entry=gmail&source=g>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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> >     >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>>> >     >     >> >>  <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> >     >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     >     >> >>  <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>> >     >     >> >>  >>>> >  >>>> > To unsubscribe send an email to >     >     >> >> dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >     >     >> >>  >>>> >  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >     >     >> >>  >>>> > >     >     >> >>  >>>> > >     >     >> >>  >>>> > >  _______________________________________________ >     >     >> >>  >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >     >     >> >>  >>>> > To unsubscribe send an email to >     > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >     >     >> >>  >>>> >  _______________________________________________ >     >     >> >>  >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> >     <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >     >     >> >>  >>>> To unsubscribe send an email to >     > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >     >     >> >> >     >     >> >> _______________________________________________ >     >     >> >> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >     >     >> >> To unsubscribe send an email to dev-leave@ceph.io <mailto:dev-leave@ceph.io> >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >     > >

Is there an advantage to doing this in OPA over radosgw? Have you looked at using our PutUserPolicy[1] APIs instead? We support both user and bucket policy, and (as far as I know) handle the intersection of the two as you'd expect. https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html On 2/5/20 9:55 AM, Seena Fallah wrote:

I'm trying to implement AWS IAM with OPA so I can have external authorization for my S3 service and also have an active bucket ACL and bucket policy.

On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

I'm confused by your references to AWS IAM. Are you talking about radosgw user policy? Or are you trying to implement IAM policy inside of OPA?

On 2/5/20 8:54 AM, Seena Fallah wrote: > Hi all. > > Any updates here? :) > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: > >     I should also mention that if we get access to bucket via bucket >     policy and reject it via AWS IAM, the request will reject so I >     think we should make a new behavior at what we should do with this >     two source of truth? > >     On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> wrote: > >         Yes but the main problem is when the policy isn't set in AWS >         IAM for example a user has only AmazonS3ReadOnlyAccess and we >         give PutObject policy via bucket policy, user can put object >         to that bucket but in radosgw, OPA will deny this process >         because there is only ReadOnlyAccess to that bucket for user >         and radosgw will not check bucket policy that gave access to >         user. >         I think we should weight bucket policy over OPA so if bucket >         policy accept that request it doesn't need to be checked with >         OPA BUT if there is no policy according to that request it >         should check by OPA because if the policy according to that >         request isn't set bucket policy will reject that request so it >         against failed! > >         On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >         <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > > >             On 1/30/20 2:18 PM, Seena Fallah wrote: >             > Hi Casey, >             > >             > The main problem now is when OPA integration is enabled >             bucket >             > policies aren’t work! >             > I have checked AWS S3 that what is doing when both >             bucket policy and >             > IAM policy (the policy is set with AWS panel in IAM >             section) is set it >             > will OR between two of them so now in radosgw S3 we >             don’t have this >             > feature and bucket policies won’t work when OPA >             integration is enabled. >             > >             > So I think it’s better to active this feature and >             enabled bucket >             > policy when OpA integration is enabled. >             > >             > There is two solutions here in this discussion for >             enabling bucket >             > policy on OPA integration: >             > 1. Send bucket policy on set/del actions to OPA server >             to be apply on >             > OPA policy rules so in this case the source of truth >             will be OPA (the >             > state that we have now in OPA integration) and so these >             policies that >             > sent from bucket policy will be applied. >             > 2. OR between bucket policy and OPA policy like AWS S3. >             So there is >             > two source of truth in this case and if any of them deny >             the request, >             > the request will be denied. > >             What you described here in 2. is exactly how it currently >             works. > >             > >             > Do have any other solutions we have here and which of >             these solutions >             > do you prefer to have? >             > >             > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley >             <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >             > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >             wrote: >             > >             >     Hi Seena, >             > >             >     I think it would probably help if you could describe >             your use case >             >     here, >             >     and what role you want OPA to play in the >             interpretation of these >             >     bucket >             >     policies. In other words, what is it that your OPA >             policy is doing >             >     with >             >     these bucket policy documents that shouldn't be done >             within radosgw? >             > >             >     On 1/30/20 1:09 AM, Seena Fallah wrote: >             >     > So Matt what should we have done with bucket >             policy if we enable >             >     OPA >             >     > integration? >             >     > >             >     > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin >             >     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> wrote: >             >     > >             >     >     I think we should not be introducing new >             special case >             >     behavior, nor >             >     >     sending policy documents to OPA, which from >             what we have >             >     heard and >             >     >     read, intends to make no use of them. >             >     > >             >     >     Matt >             >     > >             >     >     On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >             >     >     > >             >     >     > I think it’s better to OR between two of the >             bucket >             >     policies and >             >     >     OPA policies. So if one of them reject certain >             access the >             >     request >             >     >     will reject as AWS do on its IAM and bucket >             policy. >             >     >     > Are you okay with this idea? >             >     >     > >             >     >     > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley >             >     >     <cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> wrote: >             >     >     >> >             >     >     >> >             >     >     >> On 1/28/20 2:45 PM, Matthias Muench wrote: >             >     >     >> > Hi, >             >     >     >> > I think making Ceph special to what the >             rest of the clients >             >     >     in the >             >     >     >> > world would expect would be a bit off the >             idea of providing >             >     >     S3 like >             >     >     >> > service. >             >     >     >> > To my understanding, setting OPA to be >             the source of >             >     truth would >             >     >     >> > introduce latency (based on Casey’s >             comments) and will not >             >     >     allow to >             >     >     >> > set policies (based on Seena). >             >     >     >> > The first one brings us towards harder >             latency and >             >     especially >             >     >     >> > depending on extern systems resource >             capability (assume >             >     central >             >     >     >> > resource as the idea is and therefor not >             necessarily really >             >     >     “in reach” >             >     >     >> > within an acceptable latency, routing in >             addition, >             >     etc.). The >             >     >     second >             >     >     >> > one says simply that this would break any >             existing >             >     >     compatibility with >             >     >     >> > clients and use cases. To me it looks not >             that good to >             >     loose >             >     >     on both ends. >             >     >     >> >             >     >     >> Agreed. Even if one has to opt-in to this >             broken s3 >             >     >     compatiblity, I'm >             >     >     >> skeptical that users will find this to be a >             compelling target >             >     >     for their >             >     >     >> applications. >             >     >     >> >             >     >     >> The existing prototype of OPA integration >             sends this >             >     authorization >             >     >     >> request to OPA -in addition to- radosgw's >             own authorization >             >     >     logic, where >             >     >     >> we consult any of our user/bucket policies >             or ACLs that >             >     apply. >             >     >     In this >             >     >     >> model, OPA is not the only source of truth. >             It just has the >             >     >     opportunity >             >     >     >> to deny access that we would otherwise >             grant, so it doesn't >             >     >     require that >             >     >     >> we break compatibility with any S3 features >             that conflict >             >     with >             >     >     OPA's >             >     >     >> view of policy. >             >     >     >> >             >     >     >> Were we to change this so that OPA was the >             only source of >             >     >     truth, then >             >     >     >> we'd be left with two bad options: either >             reject all requests >             >     >     to modify >             >     >     >> policy and break existing applications, or >             send all >             >     policy/ACL >             >     >     >> information to OPA and require every OPA >             policy script to >             >     implement >             >     >     >> s3-compatible enforcement of them. I also >             don't see any >             >     benefit >             >     >     to this >             >     >     >> model - why, if an client wants to use s3 >             policy to >             >     restrict a >             >     >     certain >             >     >     >> access, would OPA want to override that and >             grant access >             >     instead? >             >     >     >> >             >     >     >> > I could live more with the latency issue >             but wouldn’t >             >     like it. >             >     >     >> > For the second, I can understand the idea >             of having >             >     >     simplification for >             >     >     >> > auditing the access but I’m not that >             convinced to take the >             >     >     burden of >             >     >     >> > being “the special” one that nobody wants >             to work with. >             >     So, I >             >     >     would >             >     >     >> > love to see the full fledged support of >             setting the >             >     policy by >             >     >     clients, >             >     >     >> > no matter what the result would be in >             terms of >             >     implementing it to >             >     >     >> > interact with OPA. Instead, having an >             additional >             >     requirement to >             >     >     >> > implement additional handling to set >             policies different >             >     from >             >     >     what S3 >             >     >     >> > actually provides would require special >             clients first and >             >     >     secondly an >             >     >     >> > additional path to OPA with all the >             additional burden >             >     to tweak >             >     >     >> > security to allow this path to OPA. I >             feel that the first >             >     >     wouldn’t >             >     >     >> > happen (special clients) and the second >             in practice not >             >     >     either because >             >     >     >> > of security constraints by the OPA admin >             folks. >             >     >     >> > >             >     >     >> > G, >             >     >     >> > -matt >             >     >     >> > >             >     >     >> > —————————————————— >             >     >     >> > Matthias Muench >             >     >     >> > Senior Specialist Solution Architect >             >     >     >> > EMEA Storage Specialist >             >     >     >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >             >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> >             >     >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >             >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>> >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> >             >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> >             >     >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>>> >             >     >     >> > Phone: +49-160-92654111 >             <tel:+49-160-92654111> >             >     >     >> > >             >     >     >> > Red Hat GmbH >             >     >     >> > Werner-von-Siemens-Ring 14 >             <x-apple-data-detectors://2/1> >             >     >     >> > 85630 Grasbrunn >             <x-apple-data-detectors://2/1> >             >     >     >> > Germany <x-apple-data-detectors://2/1> >             >     >     >> > >             >     > >             > >    _______________________________________________________________________ >             >     >     >> > Red Hat GmbH, http://www.de.redhat.com >             >     <http://de.redhat.com/> · >             >     >     >> > Registered seat: Grasbrunn, Commercial >             register: >             >     Amtsgericht >             >     >     Muenchen >             >     >     >> > HRB 153243 · Managing Directors: Charles >             Cachera, Michael >             >     >     O'Neill, Tom >             >     >     >> > Savage, Eric Shander >             >     >     >> > >             >     >     >> >> On Jan 28, 2020, at 15:02, Seena Fallah >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> wrote: >             >     >     >> >> >             >     >     >> >>  >             >     >     >> >> Amazon AWS S3 has two type of policies. >             One from bucket >             >     >     policy and >             >     >     >> >> one form IAM. I think it could be better >             to have two >             >     >     policies models >             >     >     >> >> in Ceph one from bucket policy and one >             form OPA if its >             >     enable. >             >     >     >> >> So if you are okay we can change the PR >             to make bucket >             >     >     policy enabled >             >     >     >> >> when OPA is enabled, too. Because now >             bucket policies not >             >     >     working >             >     >     >> >> when OPA integration is enabled. >             >     >     >> >> >             >     >     >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >             >     >     >> >> >             >     >     >> >>     Matt When OPA integration is enabled >             S3 policies >             >     doesn’t >             >     >     work! If >             >     >     >> >>     you want them to be worked we should >             bypass S3 >             >     policies >             >     >     to OPA >             >     >     >> >>     for being applied and worked. >             >     >     >> >>     Here we have conflict in OPA >             integration with S3 >             >     policies! >             >     >     >> >> >             >     >     >> >>     On Tue, Jan 28, 2020 at 2:52 AM Matt >             Benjamin >             >     >     >> >>     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>> wrote: >             >     >     >> >> >             >     >     >> >>  My take so far is that this is >             not a bug, and I'd >             >     >     like not to >             >     >     >> >>  introduce special-case logic to >             override or >             >     suppress >             >     >     >> >>  processing of >             >     >     >> >>  native policy. >             >     >     >> >> >             >     >     >> >>  Matt >             >     >     >> >> >             >     >     >> >>  On Mon, Jan 27, 2020 at 5:24 PM >             Seena Fallah >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >             >     >     >> >>  > >             >     >     >> >>  > I think it's very good that >             Ceph export its >             >     >     authorization >             >     >     >> >>  and we could have external >             source of truth >             >     with it. S3 >             >     >     >> >>  policies can transport to OPA >             and updates by users >             >     >     set/del >             >     >     >> >>  policies. >             >     >     >> >>  > But now we have conflict with OPA >             >     integration and S3 >             >     >     >> >>  policies which is set when OPA >             integration is >             >     >     enabled, aren't >             >     >     >> >>  work. >             >     >     >> >>  > >             >     >     >> >>  > Can you all please help to fix >             this bug? >             >     >     >> >>  > >             >     >     >> >>  > On Fri, Jan 24, 2020 at 1:05 >             PM Seena Fallah >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >             >     >     >> >>  >> >             >     >     >> >>  >> Hi all. >             >     >     >> >>  >> >             >     >     >> >>  >> Any updates here? >             >     >     >> >>  >> >             >     >     >> >>  >> On Tue, Jan 21, 2020 at 2:50 >             AM Seena Fallah >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >             >     >     >> >>  >>> >             >     >     >> >>  >>> OPA can be used in companies that >             uses many >             >     >     services like >             >     >     >> >>  k8s, Ceph,... and want to have >             one central >             >     point for >             >     >     >> >>  authorizing users so they can >             maintenance their >             >     >     access for >             >     >     >> >>  each user on each service for >             example and etc. >             >     It’s >             >     >     just a >             >     >     >> >>  use case and so it’s really good >             to have it. I >             >     think >             >     >     this is >             >     >     >> >>  the biggest use case for having >             OPA in >             >     products that >             >     >     gets an >             >     >     >> >>  option to centralize authorizing >             for all types of >             >     >     services. >             >     >     >> >>  >>> >             >     >     >> >>  >>> Performance for this model is issue >             like >             >     having >             >     >     keystone >             >     >     >> >>  with Ceph. So I think it’s based >             on users that >             >     >     active this >             >     >     >> >>  integrations at all. >             >     >     >> >>  >>> >             >     >     >> >>  >>> The model for writing policies to >             radosgw >             >     isn’t >             >     >     really >             >     >     >> >>  good I think because of the >             reason above if >             >     this accrued >             >     >     >> >>  there is always two copies of >             policies and it >             >     >     doesn’t sounds >             >     >     >> >>  good for maintaining. >             >     >     >> >>  >>> >             >     >     >> >>  >>> If bucket policy disable, s3 >             clients like >             >     boto3 >             >     >     and etc >             >     >     >> >>  will not work for setting >             polices but I think when >             >     >     someone is >             >     >     >> >>  enabling OPA for authorizing it >             will also have an >             >     >     API for >             >     >     >> >>  his/her OPA server to set/del >             policies and >             >     they can call >             >     >     >> >>  these APIs to set/del policies. >             >     >     >> >>  >>> And for extensions like >             PublicAccessBlock, >             >     it will >             >     >     >> >>  disable because OPA is just >             authorizing >             >     requests and >             >     >     Ceph >             >     >     >> >>  doesn’t authorize any request >             when OPA integration >             >     >     is enabled >             >     >     >> >>  so OPA should handle any >             incoming policies >             >     were made >             >     >     by S3 >             >     >     >> >>  policies. So it doesn’t make >             conflicts and if OPA >             >     >     integration >             >     >     >> >>  is enabled it won’t work as we >             return 405 on each >             >     >     set/del >             >     >     >> >>  policies requests and if OPA is >             disabled users can >             >     >     use this >             >     >     >> >>  policies. >             >     >     >> >>  >>> >             >     >     >> >>  >>> >             >     >     >> >>  >>> On Tue, Jan 21, 2020 at 2:05 AM >             Casey Bodley >             >     >     >> >>  <cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >             >     >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>>> wrote: >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> I am a big fan of the IAM policy >             documents, >             >     >     both because >             >     >     >> >>  of the >             >     >     >> >>  >>>> flexibility and expressiveness >             they provide, >             >     >     and because >             >     >     >> >>  they're in a >             >     >     >> >>  >>>> format that all of our s3 clients >             understand. >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> I'm not familiar enough with OPA >             to know >             >     what extra >             >     >     >> >>  capabilities it >             >     >     >> >>  >>>> offers that IAM policy cannot, but >             I have >             >     serious >             >     >     >> >>  concerns about the >             >     >     >> >>  >>>> performance and scalability of a >             model where >             >     >     radosgw has >             >     >     >> >>  to send >             >     >     >> >>  >>>> blocking RPCs to OPA in order to >             >     authorize each and >             >     >     >> >>  every request. >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> On the other hand, consider a >             model where a >             >     >     Policy Agent >             >     >     >> >>  exercises its >             >     >     >> >>  >>>> control over authorization by >             writing IAM >             >     >     documents to >             >     >     >> >>  radosgw, which we >             >     >     >> >>  >>>> use to cheaply authorize requests >             out of our >             >     >     metadata >             >     >     >> >>  cache. I would >             >     >     >> >>  >>>> imagine that this model could >             cover a lot of >             >     >     interesting >             >     >     >> >>  use cases, >             >     >     >> >>  >>>> without breaking support for >             existing s3 >             >     >     applications >             >     >     >> >>  that rely on >             >     >     >> >>  >>>> bucket policy - as the proposal to >             reject >             >     >     >> >>  PutBucketPolicy requests would. >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> Is this something that OPA could >             feasibly do? >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> For use cases that aren't supported by >             >     the existing >             >     >     >> >>  policy grammar, >             >     >     >> >>  >>>> we're open to maintaining >             extensions to these >             >     >     documents. >             >     >     >> >>  We already >             >     >     >> >>  >>>> implement a number of s3 extensions >             >     [1][2] that are >             >     >     >> >>  easily accessible >             >     >     >> >>  >>>> via python/boto and the aws cli. >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> But a model where radosgw outsources >             >     authorization >             >     >     >> >>  entirely is a hard >             >     >     >> >>  >>>> sell, because it conflicts with >             feature >             >     development >             >     >     >> >>  going forward. One >             >     >     >> >>  >>>> example would be support for >             >     PublicAccessBlock [3], >             >     >     >> >>  where radosgw needs >             >     >     >> >>  >>>> full visibility into policy to >             detect cases >             >     >     where public >             >     >     >> >>  access would be >             >     >     >> >>  >>>> granted. >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> [1] >             >     >     >> >>  >>>> >             >     >     >> >> >             >     > >             > > https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> [2] >             >     >     >> >>  >>>> >             >     >     >> >> >             >     > >             > > https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras... >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> [3] > https://github.com/ceph/ceph/pull/30033 >             >     >     >> >>  >>>> >             >     >     >> >>  >>>> On 1/20/20 12:21 PM, Seena Fallah >             wrote: >             >     >     >> >>  >>>> > 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@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >             >     >     >> >>  >>>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@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 >             >     >     >> >> >             > >              <https://www.google.com/maps/search/%C2%A0?entry=gmail&source=g>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@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >             >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >             >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@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@styra.com <mailto:ash@styra.com> >             <mailto:ash@styra.com <mailto:ash@styra.com>> <mailto:ash@styra.com <mailto:ash@styra.com> >             <mailto:ash@styra.com <mailto:ash@styra.com>>> >             >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>>> >             >     >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> >             >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>>>> >             >     >     >> >>  <mailto:ash@styra.com <mailto:ash@styra.com> >             <mailto:ash@styra.com <mailto:ash@styra.com>> <mailto:ash@styra.com <mailto:ash@styra.com> >             <mailto:ash@styra.com <mailto:ash@styra.com>>> >             >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>>> >             >     >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>>> >             >     <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@styra.com>> >             <mailto:ash@styra.com <mailto:ash@styra.com> <mailto:ash@styra.com <mailto:ash@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@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@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@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >             >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >             >     >     >> >>  <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >             <mailto:mbenjami@redhat.com <mailto:mbenjami@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@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >             >     >     >> >>  <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >             <mailto:seenafallah@gmail.com <mailto:seenafallah@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@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >             >     >     >> >>  <mailto:dev@ceph.io <mailto:dev@ceph.io> >             <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>> >             >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>>> >             >     >     >> >>  >>>> >  >>>> > To unsubscribe send an >             email to >             >     >     >> >> dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >             >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>> >             >     >     >> >>  >>>> >  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >             >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >             >     >     >> >>  >>>> > >             >     >     >> >>  >>>> > >             >     >     >> >>  >>>> > >             >  _______________________________________________ >             >     >     >> >>  >>>> > Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >             <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>> >             >     >     >> >>  >>>> > To unsubscribe send an email to >             >     > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >             >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>> >             >     >     >> >>  >>>> >             >  _______________________________________________ >             >     >     >> >>  >>>> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >             <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>> >             >     >     >> >>  >>>> To unsubscribe send an email to >             >     > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>> >             >     >     >> >>  <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >             >     >     >> >> >             >     >     >> >> >  _______________________________________________ >             >     >     >> >> Dev mailing list -- dev@ceph.io <mailto:dev@ceph.io> >             <mailto:dev@ceph.io <mailto:dev@ceph.io>> <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>> >             >     <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>> >             <mailto:dev@ceph.io <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>> >             >     >     >> >> To unsubscribe send an email to > dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> >             >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>> >             >     >     <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io> >             <mailto:dev-leave@ceph.io <mailto:dev-leave@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 >             >     > >             > >

On 2/6/20 11:58 AM, Seena Fallah wrote:

The main goal of using OPA like as AWS IAM is having an external authorization so we can have out own management on policies from external source of truth (OPA) too.

I think it’s better to handle bucket policy with OPA as well as AWS does so we can have a better S3 service :)

Can you expand on why that's better than the model I suggested earlier in the thread, where a centralized policy service uses radosgw's existing IAM APIs to manage policy instead of requiring radosgw to call out to an external service for every request? I'd also like to clarify what you mean when you say "handle bucket policy with OPA" - my understanding is that it's not something that OPA itself does, but something very specific to your own product's OPA policy script. Am I getting that right? If so, it sounds like you're trying to re-engineer our OPA integration in a way that a) is not useful to OPA users in general, and b) duplicates functionality that radosgw already provides. For OPA users that just want the ability to write simple scripts to customize authorization for their environment, I think our current level of OPA integration is sufficient.

On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Is there an advantage to doing this in OPA over radosgw? Have you looked at using our PutUserPolicy[1] APIs instead? We support both user and bucket policy, and (as far as I know) handle the intersection of the two as you'd expect.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html

On 2/5/20 9:55 AM, Seena Fallah wrote: > I'm trying to implement AWS IAM with OPA so I can have external > authorization for my S3 service and also have an active bucket ACL and > bucket policy. > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > >     I'm confused by your references to AWS IAM. Are you talking about >     radosgw user policy? Or are you trying to implement IAM policy >     inside of >     OPA? > >     On 2/5/20 8:54 AM, Seena Fallah wrote: >     > Hi all. >     > >     > Any updates here? :) >     > >     > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     wrote: >     > >     >     I should also mention that if we get access to bucket via bucket >     >     policy and reject it via AWS IAM, the request will reject so I >     >     think we should make a new behavior at what we should do >     with this >     >     two source of truth? >     > >     >     On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> wrote: >     > >     >         Yes but the main problem is when the policy isn't set in AWS >     >         IAM for example a user has only AmazonS3ReadOnlyAccess >     and we >     >         give PutObject policy via bucket policy, user can put object >     >         to that bucket but in radosgw, OPA will deny this process >     >         because there is only ReadOnlyAccess to that bucket for user >     >         and radosgw will not check bucket policy that gave access to >     >         user. >     >         I think we should weight bucket policy over OPA so if bucket >     >         policy accept that request it doesn't need to be checked >     with >     >         OPA BUT if there is no policy according to that request it >     >         should check by OPA because if the policy according to that >     >         request isn't set bucket policy will reject that request >     so it >     >         against failed! >     > >     >         On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >     >         <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: >     > >     > >     >             On 1/30/20 2:18 PM, Seena Fallah wrote: >     >             > Hi Casey, >     >             > >     >             > The main problem now is when OPA integration is >     enabled >     >             bucket >     >             > policies aren’t work! >     >             > I have checked AWS S3 that what is doing when both >     >             bucket policy and >     >             > IAM policy (the policy is set with AWS panel in IAM >     >             section) is set it >     >             > will OR between two of them so now in radosgw S3 we >     >             don’t have this >     >             > feature and bucket policies won’t work when OPA >     >             integration is enabled. >     >             > >     >             > So I think it’s better to active this feature and >     >             enabled bucket >     >             > policy when OpA integration is enabled. >     >             > >     >             > There is two solutions here in this discussion for >     >             enabling bucket >     >             > policy on OPA integration: >     >             > 1. Send bucket policy on set/del actions to OPA server >     >             to be apply on >     >             > OPA policy rules so in this case the source of truth >     >             will be OPA (the >     >             > state that we have now in OPA integration) and so >     these >     >             policies that >     >             > sent from bucket policy will be applied. >     >             > 2. OR between bucket policy and OPA policy like >     AWS S3. >     >             So there is >     >             > two source of truth in this case and if any of >     them deny >     >             the request, >     >             > the request will be denied. >     > >     >             What you described here in 2. is exactly how it >     currently >     >             works. >     > >     >             > >     >             > Do have any other solutions we have here and which of >     >             these solutions >     >             > do you prefer to have? >     >             > >     >             > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley >     >             <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >     >             > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> >     >             wrote: >     >             > >     >             >     Hi Seena, >     >             > >     >             >     I think it would probably help if you could >     describe >     >             your use case >     >             >     here, >     >             >     and what role you want OPA to play in the >     >             interpretation of these >     >             >     bucket >     >             >     policies. In other words, what is it that your OPA >     >             policy is doing >     >             >     with >     >             >     these bucket policy documents that shouldn't >     be done >     >             within radosgw? >     >             > >     >             >     On 1/30/20 1:09 AM, Seena Fallah wrote: >     >             >     > So Matt what should we have done with bucket >     >             policy if we enable >     >             >     OPA >     >             >     > integration? >     >             >     > >     >             >     > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin >     >             >     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >     >             >     > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>> wrote: >     >             >     > >     >             >     >     I think we should not be introducing new >     >             special case >     >             >     behavior, nor >     >             >     >     sending policy documents to OPA, which from >     >             what we have >     >             >     heard and >     >             >     >     read, intends to make no use of them. >     >             >     > >     >             >     >     Matt >     >             >     > >     >             >     >     On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah >     >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >     >             >     >     > >     >             >     >     > I think it’s better to OR between two >     of the >     >             bucket >     >             >     policies and >     >             >     >     OPA policies. So if one of them reject >     certain >     >             access the >     >             >     request >     >             >     >     will reject as AWS do on its IAM and bucket >     >             policy. >     >             >     >     > Are you okay with this idea? >     >             >     >     > >     >             >     >     > On Wed, Jan 29, 2020 at 11:13 PM Casey >     Bodley >     >             >     >     <cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >     >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>>> wrote: >     >             >     >     >> >     >             >     >     >> >     >             >     >     >> On 1/28/20 2:45 PM, Matthias Muench >     wrote: >     >             >     >     >> > Hi, >     >             >     >     >> > I think making Ceph special to what the >     >             rest of the clients >     >             >     >     in the >     >             >     >     >> > world would expect would be a bit >     off the >     >             idea of providing >     >             >     >     S3 like >     >             >     >     >> > service. >     >             >     >     >> > To my understanding, setting OPA to be >     >             the source of >     >             >     truth would >     >             >     >     >> > introduce latency (based on Casey’s >     >             comments) and will not >     >             >     >     allow to >     >             >     >     >> > set policies (based on Seena). >     >             >     >     >> > The first one brings us towards harder >     >             latency and >     >             >     especially >     >             >     >     >> > depending on extern systems resource >     >             capability (assume >     >             >     central >     >             >     >     >> > resource as the idea is and >     therefor not >     >             necessarily really >     >             >     >     “in reach” >     >             >     >     >> > within an acceptable latency, >     routing in >     >             addition, >     >             >     etc.). The >     >             >     >     second >     >             >     >     >> > one says simply that this would >     break any >     >             existing >     >             >     >     compatibility with >     >             >     >     >> > clients and use cases. To me it >     looks not >     >             that good to >     >             >     loose >     >             >     >     on both ends. >     >             >     >     >> >     >             >     >     >> Agreed. Even if one has to opt-in to this >     >             broken s3 >     >             >     >     compatiblity, I'm >     >             >     >     >> skeptical that users will find this >     to be a >     >             compelling target >     >             >     >     for their >     >             >     >     >> applications. >     >             >     >     >> >     >             >     >     >> The existing prototype of OPA integration >     >             sends this >     >             >     authorization >     >             >     >     >> request to OPA -in addition to- radosgw's >     >             own authorization >     >             >     >     logic, where >     >             >     >     >> we consult any of our user/bucket >     policies >     >             or ACLs that >     >             >     apply. >     >             >     >     In this >     >             >     >     >> model, OPA is not the only source of >     truth. >     >             It just has the >     >             >     >     opportunity >     >             >     >     >> to deny access that we would otherwise >     >             grant, so it doesn't >     >             >     >     require that >     >             >     >     >> we break compatibility with any S3 >     features >     >             that conflict >     >             >     with >     >             >     >     OPA's >     >             >     >     >> view of policy. >     >             >     >     >> >     >             >     >     >> Were we to change this so that OPA >     was the >     >             only source of >     >             >     >     truth, then >     >             >     >     >> we'd be left with two bad options: either >     >             reject all requests >     >             >     >     to modify >     >             >     >     >> policy and break existing >     applications, or >     >             send all >     >             >     policy/ACL >     >             >     >     >> information to OPA and require every OPA >     >             policy script to >     >             >     implement >     >             >     >     >> s3-compatible enforcement of them. I also >     >             don't see any >     >             >     benefit >     >             >     >     to this >     >             >     >     >> model - why, if an client wants to use s3 >     >             policy to >     >             >     restrict a >     >             >     >     certain >     >             >     >     >> access, would OPA want to override >     that and >     >             grant access >     >             >     instead? >     >             >     >     >> >     >             >     >     >> > I could live more with the latency >     issue >     >             but wouldn’t >     >             >     like it. >     >             >     >     >> > For the second, I can understand >     the idea >     >             of having >     >             >     >     simplification for >     >             >     >     >> > auditing the access but I’m not that >     >             convinced to take the >     >             >     >     burden of >     >             >     >     >> > being “the special” one that nobody >     wants >     >             to work with. >     >             >     So, I >     >             >     >     would >     >             >     >     >> > love to see the full fledged support of >     >             setting the >     >             >     policy by >     >             >     >     clients, >     >             >     >     >> > no matter what the result would be in >     >             terms of >     >             >     implementing it to >     >             >     >     >> > interact with OPA. Instead, having an >     >             additional >     >             >     requirement to >     >             >     >     >> > implement additional handling to set >     >             policies different >     >             >     from >     >             >     >     what S3 >     >             >     >     >> > actually provides would require special >     >             clients first and >     >             >     >     secondly an >     >             >     >     >> > additional path to OPA with all the >     >             additional burden >     >             >     to tweak >     >             >     >     >> > security to allow this path to OPA. I >     >             feel that the first >     >             >     >     wouldn’t >     >             >     >     >> > happen (special clients) and the second >     >             in practice not >     >             >     >     either because >     >             >     >     >> > of security constraints by the OPA >     admin >     >             folks. >     >             >     >     >> > >     >             >     >     >> > G, >     >             >     >     >> > -matt >     >             >     >     >> > >     >             >     >     >> > —————————————————— >     >             >     >     >> > Matthias Muench >     >             >     >     >> > Senior Specialist Solution Architect >     >             >     >     >> > EMEA Storage Specialist >     >             >     >     >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >     >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> >     >             >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >     >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>> >     >             >     >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >     >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> >     >             >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> >     >             <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> >     <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>>> >     >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> >     >             >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>> >     >             >     >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> >     >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> >     >             <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >     <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>>>> >     >             >     >     >> > Phone: +49-160-92654111 >     >             <tel:+49-160-92654111> >     >             >     >     >> > >     >             >     >     >> > Red Hat GmbH >     >             >     >     >> > Werner-von-Siemens-Ring 14 >     >  <x-apple-data-detectors://2/1> >     >             >     >     >> > 85630 Grasbrunn >     >  <x-apple-data-detectors://2/1> >     >             >     >     >> > Germany <x-apple-data-detectors://2/1> >     >             >     >     >> > >     >             >     > >     >             > >     > >     _______________________________________________________________________ >     >             >     >     >> > Red Hat GmbH, http://www.de.redhat.com >     >             >     <http://de.redhat.com/> · >     >             >     >     >> > Registered seat: Grasbrunn, Commercial >     >             register: >     >             >     Amtsgericht >     >             >     >     Muenchen >     >             >     >     >> > HRB 153243 · Managing Directors: >     Charles >     >             Cachera, Michael >     >             >     >     O'Neill, Tom >     >             >     >     >> > Savage, Eric Shander >     >             >     >     >> > >     >             >     >     >> >> On Jan 28, 2020, at 15:02, Seena >     Fallah >     >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: >     >             >     >     >> >> >     >             >     >     >> >>  >     >             >     >     >> >> Amazon AWS S3 has two type of >     policies. >     >             One from bucket >     >             >     >     policy and >     >             >     >     >> >> one form IAM. I think it could be >     better >     >             to have two >     >             >     >     policies models >     >             >     >     >> >> in Ceph one from bucket policy and one >     >             form OPA if its >     >             >     enable. >     >             >     >     >> >> So if you are okay we can change >     the PR >     >             to make bucket >     >             >     >     policy enabled >     >             >     >     >> >> when OPA is enabled, too. Because now >     >             bucket policies not >     >             >     >     working >     >             >     >     >> >> when OPA integration is enabled. >     >             >     >     >> >> >     >             >     >     >> >> On Tue, Jan 28, 2020 at 2:57 AM >     Seena Fallah >     >             >     >     <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >     >             >     >     >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: >     >             >     >     >> >> >     >             >     >     >> >>     Matt When OPA integration is >     enabled >     >             S3 policies >     >             >     doesn’t >     >             >     >     work! If >     >             >     >     >> >>     you want them to be worked we >     should >     >             bypass S3 >     >             >     policies >     >             >     >     to OPA >     >             >     >     >> >>     for being applied and worked. >     >             >     >     >> >>     Here we have conflict in OPA >     >             integration with S3 >     >             >     policies! >     >             >     >     >> >> >     >             >     >     >> >>     On Tue, Jan 28, 2020 at 2:52 >     AM Matt >     >             Benjamin >     >             >     >     >> >>     <mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >     >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> >     >             >     >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> >     >             >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> >     >             <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >     <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>>> wrote: >     >             >     >     >> >> >     >             >     >     >> >>  My take so far is that this is >     >             not a bug, and I'd >     >             >     >     like not to >     >             >     >     >> >>  introduce special-case logic to >     >             override or >     >             >     suppress >     >             >     >     >> >>  processing of >     >             >     >     >> >>  native policy. >     >             >     >     >> >> >     >             >     >     >> >>  Matt >     >             >     >     >> >> >     >             >     >     >> >>  On Mon, Jan 27, 2020 at 5:24 PM >     >             Seena Fallah >     >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: >     >             >     >     >> >>  > >     >             >     >     >> >>  > I think it's very good that >     >             Ceph export its >     >             >     >     authorization >     >             >     >     >> >>  and we could have external >     >             source of truth >     >             >     with it. S3 >     >             >     >     >> >>  policies can transport to OPA >     >             and updates by users >     >             >     >     set/del >     >             >     >     >> >>  policies. >     >             >     >     >> >>  > But now we have conflict with OPA >     >             >     integration and S3 >     >             >     >     >> >>  policies which is set when OPA >     >             integration is >     >             >     >     enabled, aren't >     >             >     >     >> >>  work. >     >             >     >     >> >>  > >     >             >     >     >> >>  > Can you all please help to fix >     >             this bug? >     >             >     >     >> >>  > >     >             >     >     >> >>  > On Fri, Jan 24, 2020 at 1:05 >     >             PM Seena Fallah >     >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: >     >             >     >     >> >>  >> >     >             >     >     >> >>  >> Hi all. >     >             >     >     >> >>  >> >     >             >     >     >> >>  >> Any updates here? >     >             >     >     >> >>  >> >     >             >     >     >> >>  >> On Tue, Jan 21, 2020 at 2:50 >     >             AM Seena Fallah >     >             >     >     >> >>  <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >     >             >     >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> >     >             >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> >     >             <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >     <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> OPA can be used in companies that >     >             uses many >     >             >     >     services like >     >             >     >     >> >>  k8s, Ceph,... and want to have >     >             one central >     >             >     point for >     >             >     >     >> >>  authorizing users so they can >     >             maintenance their >     >             >     >     access for >     >             >     >     >> >>  each user on each service for >     >             example and etc. >     >             >     It’s >     >             >     >     just a >     >             >     >     >> >>  use case and so it’s really good >     >             to have it. I >     >             >     think >     >             >     >     this is >     >             >     >     >> >>  the biggest use case for having >     >             OPA in >     >             >     products that >     >             >     >     gets an >     >             >     >     >> >>  option to centralize authorizing >     >             for all types of >     >             >     >     services. >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> Performance for this model is >     issue >     >             like >     >             >     having >     >             >     >     keystone >     >             >     >     >> >>  with Ceph. So I think it’s based >     >             on users that >     >             >     >     active this >     >             >     >     >> >>  integrations at all. >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> The model for writing policies to >     >             radosgw >     >             >     isn’t >     >             >     >     really >     >             >     >     >> >>  good I think because of the >     >             reason above if >     >             >     this accrued >     >             >     >     >> >>  there is always two copies of >     >             policies and it >     >             >     >     doesn’t sounds >     >             >     >     >> >>  good for maintaining. >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> If bucket policy disable, s3 >     >             clients like >     >             >     boto3 >     >             >     >     and etc >     >             >     >     >> >>  will not work for setting >     >             polices but I think when >     >             >     >     someone is >     >             >     >     >> >>  enabling OPA for authorizing it >     >             will also have an >     >             >     >     API for >     >             >     >     >> >>  his/her OPA server to set/del >     >             policies and >     >             >     they can call >     >             >     >     >> >>  these APIs to set/del policies. >     >             >     >     >> >>  >>> And for extensions like >     >             PublicAccessBlock, >     >             >     it will >     >             >     >     >> >>  disable because OPA is just >     >             authorizing >     >             >     requests and >     >             >     >     Ceph >     >             >     >     >> >>  doesn’t authorize any request >     >             when OPA integration >     >             >     >     is enabled >     >             >     >     >> >>  so OPA should handle any >     >             incoming policies >     >             >     were made >     >             >     >     by S3 >     >             >     >     >> >>  policies. So it doesn’t make >     >             conflicts and if OPA >     >             >     >     integration >     >             >     >     >> >>  is enabled it won’t work as we >     >             return 405 on each >     >             >     >     set/del >     >             >     >     >> >>  policies requests and if OPA is >     >             disabled users can >     >             >     >     use this >     >             >     >     >> >>  policies. >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> >     >             >     >     >> >>  >>> On Tue, Jan 21, 2020 at 2:05 AM >     >             Casey Bodley >     >             >     >     >> >>  <cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >     >             >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >     >             <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >     <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >

In organizations that has many services and want to have a centralized authorization server this will be a good solution to have. I mean that when we just authorize user ReadOnly in OPA but give write access via bucket policy, the user can’t write because OPA is rejecting. I think we can just weight bucket policy upper that OPA so bucket policies that apply policies specific than OPA policies can accept and reject at first then OPA would authorize that request. I mean bucket policy specify policy more specific (On bucket or on object) than OPA (OPA can set policy globally too like giving ReadOnly to all buckets) so it's better to first check bucket policy then check for OPA. this could be easy solve this problem. On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> wrote:

On 2/6/20 11:58 AM, Seena Fallah wrote:

...

The main goal of using OPA like as AWS IAM is having an external authorization so we can have out own management on policies from external source of truth (OPA) too.

I think it’s better to handle bucket policy with OPA as well as AWS does so we can have a better S3 service :)

Can you expand on why that's better than the model I suggested earlier in the thread, where a centralized policy service uses radosgw's existing IAM APIs to manage policy instead of requiring radosgw to call out to an external service for every request?

I'd also like to clarify what you mean when you say "handle bucket policy with OPA" - my understanding is that it's not something that OPA itself does, but something very specific to your own product's OPA policy script. Am I getting that right? If so, it sounds like you're trying to re-engineer our OPA integration in a way that a) is not useful to OPA users in general, and b) duplicates functionality that radosgw already provides.

For OPA users that just want the ability to write simple scripts to customize authorization for their environment, I think our current level of OPA integration is sufficient.

...

On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Is there an advantage to doing this in OPA over radosgw? Have you looked at using our PutUserPolicy[1] APIs instead? We support both user and bucket policy, and (as far as I know) handle the intersection of the two as you'd expect.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html

...

On 2/5/20 9:55 AM, Seena Fallah wrote: > I'm trying to implement AWS IAM with OPA so I can have external > authorization for my S3 service and also have an active bucket ACL and > bucket policy. > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > > I'm confused by your references to AWS IAM. Are you talking about > radosgw user policy? Or are you trying to implement IAM policy > inside of > OPA? > > On 2/5/20 8:54 AM, Seena Fallah wrote: > > Hi all. > > > > Any updates here? :) > > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> > wrote: > > > > I should also mention that if we get access to bucket via bucket > > policy and reject it via AWS IAM, the request will reject so I > > think we should make a new behavior at what we should do > with this > > two source of truth? > > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>

wrote:

...

> > > > Yes but the main problem is when the policy isn't set in AWS > > IAM for example a user has

only AmazonS3ReadOnlyAccess

...

> and we > > give PutObject policy via bucket policy, user can put object > > to that bucket but in radosgw, OPA will deny this process > > because there is only ReadOnlyAccess to that bucket for user > > and radosgw will not check bucket policy that gave access to > > user. > > I think we should weight bucket policy over OPA so if bucket > > policy accept that request it doesn't need to be checked > with > > OPA BUT if there is no policy according to that request it > > should check by OPA because if the policy according to that > > request isn't set bucket policy will reject that request > so it > > against failed! > > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley > > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: > > > > > > On 1/30/20 2:18 PM, Seena Fallah wrote: > > > Hi Casey, > > > > > > The main problem now is when OPA integration is > enabled > > bucket > > > policies aren’t work! > > > I have checked AWS S3 that what is doing when both > > bucket policy and > > > IAM policy (the policy is set with AWS panel in IAM > > section) is set it > > > will OR between two of them so now in radosgw S3 we > > don’t have this > > > feature and bucket policies won’t work when OPA > > integration is enabled. > > > > > > So I think it’s better to active this feature and > > enabled bucket > > > policy when OpA integration is enabled. > > > > > > There is two solutions here in this discussion for > > enabling bucket > > > policy on OPA integration: > > > 1. Send bucket policy on set/del actions to OPA server > > to be apply on > > > OPA policy rules so in this case the source of truth > > will be OPA (the > > > state that we have now in OPA integration) and so > these > > policies that > > > sent from bucket policy will be applied. > > > 2. OR between bucket policy and OPA policy like > AWS S3. > > So there is > > > two source of truth in this case and if any of > them deny > > the request, > > > the request will be denied. > > > > What you described here in 2. is exactly how it > currently > > works. > > > > > > > > Do have any other solutions we have here and which of > > these solutions > > > do you prefer to have? > > > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley > > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> > > wrote: > > > > > > Hi Seena, > > > > > > I think it would probably help if you could > describe > > your use case > > > here, > > > and what role you want OPA to play in the > > interpretation of these > > > bucket > > > policies. In other words, what is it that your OPA > > policy is doing > > > with > > > these bucket policy documents that

shouldn't

...

> be done > > within radosgw? > > > > > > On 1/30/20 1:09 AM, Seena Fallah wrote: > > > > So Matt what should we have done with bucket > > policy if we enable > > > OPA > > > > integration? > > > > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin > > > <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>> wrote: > > > > > > > > I think we should not be introducing new > > special case > > > behavior, nor > > > > sending policy documents to OPA, which from > > what we have > > > heard and > > > > read, intends to make no use of them. > > > > > > > > Matt > > > > > > > > On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > > > > > > > I think it’s better to OR between two > of the > > bucket > > > policies and > > > > OPA policies. So if one of them

reject

...

> certain > > access the > > > request > > > > will reject as AWS do on its IAM and bucket > > policy. > > > > > Are you okay with this idea? > > > > > > > > > > On Wed, Jan 29, 2020 at 11:13 PM Casey > Bodley > > > > <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>>> wrote: > > > > >> > > > > >> > > > > >> On 1/28/20 2:45 PM, Matthias

Muench

...

> wrote: > > > > >> > Hi, > > > > >> > I think making Ceph special to what the > > rest of the clients > > > > in the > > > > >> > world would expect would be a

bit

...

> off the > > idea of providing > > > > S3 like > > > > >> > service. > > > > >> > To my understanding, setting OPA to be > > the source of > > > truth would > > > > >> > introduce latency (based on Casey’s > > comments) and will not > > > > allow to > > > > >> > set policies (based on Seena). > > > > >> > The first one brings us towards harder > > latency and > > > especially > > > > >> > depending on extern systems resource > > capability (assume > > > central > > > > >> > resource as the idea is and > therefor not > > necessarily really > > > > “in reach” > > > > >> > within an acceptable latency, > routing in > > addition, > > > etc.). The > > > > second > > > > >> > one says simply that this would > break any > > existing > > > > compatibility with > > > > >> > clients and use cases. To me it > looks not > > that good to > > > loose > > > > on both ends. > > > > >> > > > > >> Agreed. Even if one has to opt-in to this > > broken s3 > > > > compatiblity, I'm > > > > >> skeptical that users will find

this

...

> to be a > > compelling target > > > > for their > > > > >> applications. > > > > >> > > > > >> The existing prototype of OPA integration > > sends this > > > authorization > > > > >> request to OPA -in addition to- radosgw's > > own authorization > > > > logic, where > > > > >> we consult any of our user/bucket > policies > > or ACLs that > > > apply. > > > > In this > > > > >> model, OPA is not the only source of > truth. > > It just has the > > > > opportunity > > > > >> to deny access that we would otherwise > > grant, so it doesn't > > > > require that > > > > >> we break compatibility with any S3 > features > > that conflict > > > with > > > > OPA's > > > > >> view of policy. > > > > >> > > > > >> Were we to change this so that OPA > was the > > only source of > > > > truth, then > > > > >> we'd be left with two bad options: either > > reject all requests > > > > to modify > > > > >> policy and break existing > applications, or > > send all > > > policy/ACL > > > > >> information to OPA and require every OPA > > policy script to > > > implement > > > > >> s3-compatible enforcement of them. I also > > don't see any > > > benefit > > > > to this > > > > >> model - why, if an client wants to use s3 > > policy to > > > restrict a > > > > certain > > > > >> access, would OPA want to override > that and > > grant access > > > instead? > > > > >> > > > > >> > I could live more with the latency > issue > > but wouldn’t > > > like it. > > > > >> > For the second, I can understand > the idea > > of having > > > > simplification for > > > > >> > auditing the access but I’m not that > > convinced to take the > > > > burden of > > > > >> > being “the special” one that nobody > wants > > to work with. > > > So, I > > > > would > > > > >> > love to see the full fledged support of > > setting the > > > policy by > > > > clients, > > > > >> > no matter what the result would be in > > terms of > > > implementing it to > > > > >> > interact with OPA. Instead, having an > > additional > > > requirement to > > > > >> > implement additional handling to set > > policies different > > > from > > > > what S3 > > > > >> > actually provides would require special > > clients first and > > > > secondly an > > > > >> > additional path to OPA with all the > > additional burden > > > to tweak > > > > >> > security to allow this path to OPA. I > > feel that the first > > > > wouldn’t > > > > >> > happen (special clients) and the second > > in practice not > > > > either because > > > > >> > of security constraints by the OPA > admin > > folks. > > > > >> > > > > > >> > G, > > > > >> > -matt > > > > >> > > > > > >> > —————————————————— > > > > >> > Matthias Muench > > > > >> > Senior Specialist Solution Architect > > > > >> > EMEA Storage Specialist > > > > >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>> > > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>> > > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>>>> > > > > >> > Phone: +49-160-92654111 > > <tel:+49-160-92654111> > > > > >> > > > > > >> > Red Hat GmbH > > > > >> > Werner-von-Siemens-Ring 14 > > <x-apple-data-detectors://2/1> > > > > >> > 85630 Grasbrunn > > <x-apple-data-detectors://2/1> > > > > >> > Germany <x-apple-data-detectors://2/1> > > > > >> > > > > > > > > > > >

_______________________________________________________________________

...

> > > > >> > Red Hat GmbH, http://www.de.redhat.com > > > <http://de.redhat.com/> · > > > > >> > Registered seat: Grasbrunn, Commercial > > register: > > > Amtsgericht > > > > Muenchen > > > > >> > HRB 153243 · Managing Directors: > Charles > > Cachera, Michael > > > > O'Neill, Tom > > > > >> > Savage, Eric Shander > > > > >> > > > > > >> >> On Jan 28, 2020, at 15:02,

Seena

...

> Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > >> >> > > > > >> >>  > > > > >> >> Amazon AWS S3 has two type of > policies. > > One from bucket > > > > policy and > > > > >> >> one form IAM. I think it could be > better > > to have two > > > > policies models > > > > >> >> in Ceph one from bucket policy and one > > form OPA if its > > > enable. > > > > >> >> So if you are okay we can

change

...

> the PR > > to make bucket > > > > policy enabled > > > > >> >> when OPA is enabled, too. Because now > > bucket policies not > > > > working > > > > >> >> when OPA integration is

enabled.

...

> > > > >> >> > > > > >> >> On Tue, Jan 28, 2020 at 2:57 AM > Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > > > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: > > > > >> >> > > > > >> >> Matt When OPA integration

is

...

> enabled > > S3 policies > > > doesn’t > > > > work! If > > > > >> >> you want them to be worked we > should > > bypass S3 > > > policies > > > > to OPA > > > > >> >> for being applied and worked. > > > > >> >> Here we have conflict in

OPA

...

> > integration with S3 > > > policies! > > > > >> >> > > > > >> >> On Tue, Jan 28, 2020 at

2:52

...

> AM Matt > > Benjamin > > > > >> >> <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>

Also we can add bucket policy result field to OPA request so in OPA policies we can act based on bucket policy results. Are you agree with it? On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah <seenafallah@gmail.com> wrote:

In bucket policy we have an Effect::Pass in validation result so if we just put OPA authorization in case of Effect::Pass I think it will be close to what AWS do.

On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In organizations that has many services and want to have a centralized authorization server this will be a good solution to have.

I mean that when we just authorize user ReadOnly in OPA but give write access via bucket policy, the user can’t write because OPA is rejecting.

I think we can just weight bucket policy upper that OPA so bucket policies that apply policies specific than OPA policies can accept and reject at first then OPA would authorize that request. I mean bucket policy specify policy more specific (On bucket or on object) than OPA (OPA can set policy globally too like giving ReadOnly to all buckets) so it's better to first check bucket policy then check for OPA. this could be easy solve this problem.

On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> wrote:

...

On 2/6/20 11:58 AM, Seena Fallah wrote:

...

The main goal of using OPA like as AWS IAM is having an external authorization so we can have out own management on policies from external source of truth (OPA) too.

I think it’s better to handle bucket policy with OPA as well as AWS does so we can have a better S3 service :)

Can you expand on why that's better than the model I suggested earlier in the thread, where a centralized policy service uses radosgw's existing IAM APIs to manage policy instead of requiring radosgw to call out to an external service for every request?

I'd also like to clarify what you mean when you say "handle bucket policy with OPA" - my understanding is that it's not something that OPA itself does, but something very specific to your own product's OPA policy script. Am I getting that right? If so, it sounds like you're trying to re-engineer our OPA integration in a way that a) is not useful to OPA users in general, and b) duplicates functionality that radosgw already provides.

For OPA users that just want the ability to write simple scripts to customize authorization for their environment, I think our current level of OPA integration is sufficient.

...

On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Is there an advantage to doing this in OPA over radosgw? Have you looked at using our PutUserPolicy[1] APIs instead? We support both user

and

...

bucket policy, and (as far as I know) handle the intersection of the two as you'd expect.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html

...

On 2/5/20 9:55 AM, Seena Fallah wrote: > I'm trying to implement AWS IAM with OPA so I can have external > authorization for my S3 service and also have an active bucket ACL and > bucket policy. > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> wrote: > > I'm confused by your references to AWS IAM. Are you talking about > radosgw user policy? Or are you trying to implement IAM

policy

...

> inside of > OPA? > > On 2/5/20 8:54 AM, Seena Fallah wrote: > > Hi all. > > > > Any updates here? :) > > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> > wrote: > > > > I should also mention that if we get access to bucket via bucket > > policy and reject it via AWS IAM, the request will reject so I > > think we should make a new behavior at what we should

do

...

> with this > > two source of truth? > > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>

wrote:

...

> > > > Yes but the main problem is when the policy isn't set in AWS > > IAM for example a user has

only AmazonS3ReadOnlyAccess

...

> and we > > give PutObject policy via bucket policy, user can put object > > to that bucket but in radosgw, OPA will deny this process > > because there is only ReadOnlyAccess to that bucket for user > > and radosgw will not check bucket policy that gave access to > > user. > > I think we should weight bucket policy over OPA so if bucket > > policy accept that request it doesn't need to be checked > with > > OPA BUT if there is no policy according to that request it > > should check by OPA because if the policy according to that > > request isn't set bucket policy will reject that request > so it > > against failed! > > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley > > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: > > > > > > On 1/30/20 2:18 PM, Seena Fallah wrote: > > > Hi Casey, > > > > > > The main problem now is when OPA integration

is

...

> enabled > > bucket > > > policies aren’t work! > > > I have checked AWS S3 that what is doing when both > > bucket policy and > > > IAM policy (the policy is set with AWS panel in IAM > > section) is set it > > > will OR between two of them so now in radosgw S3 we > > don’t have this > > > feature and bucket policies won’t work when

OPA

...

> > integration is enabled. > > > > > > So I think it’s better to active this feature and > > enabled bucket > > > policy when OpA integration is enabled. > > > > > > There is two solutions here in this discussion for > > enabling bucket > > > policy on OPA integration: > > > 1. Send bucket policy on set/del actions to OPA server > > to be apply on > > > OPA policy rules so in this case the source of truth > > will be OPA (the > > > state that we have now in OPA integration) and so > these > > policies that > > > sent from bucket policy will be applied. > > > 2. OR between bucket policy and OPA policy

like

...

> AWS S3. > > So there is > > > two source of truth in this case and if any

of

...

> them deny > > the request, > > > the request will be denied. > > > > What you described here in 2. is exactly how it > currently > > works. > > > > > > > > Do have any other solutions we have here and which of > > these solutions > > > do you prefer to have? > > > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley > > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> > > wrote: > > > > > > Hi Seena, > > > > > > I think it would probably help if you

could

...

> describe > > your use case > > > here, > > > and what role you want OPA to play in the > > interpretation of these > > > bucket > > > policies. In other words, what is it that your OPA > > policy is doing > > > with > > > these bucket policy documents that

shouldn't

...

> be done > > within radosgw? > > > > > > On 1/30/20 1:09 AM, Seena Fallah wrote: > > > > So Matt what should we have done with bucket > > policy if we enable > > > OPA > > > > integration? > > > > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin > > > <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>> wrote: > > > > > > > > I think we should not be introducing new > > special case > > > behavior, nor > > > > sending policy documents to OPA, which from > > what we have > > > heard and > > > > read, intends to make no use of

them.

...

> > > > > > > > Matt > > > > > > > > On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > > > > > > > I think it’s better to OR between two > of the > > bucket > > > policies and > > > > OPA policies. So if one of them

reject

...

> certain > > access the > > > request > > > > will reject as AWS do on its IAM and bucket > > policy. > > > > > Are you okay with this idea? > > > > > > > > > > On Wed, Jan 29, 2020 at 11:13 PM Casey > Bodley > > > > <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>>> wrote: > > > > >> > > > > >> > > > > >> On 1/28/20 2:45 PM, Matthias

Muench

...

> wrote: > > > > >> > Hi, > > > > >> > I think making Ceph special to what the > > rest of the clients > > > > in the > > > > >> > world would expect would be a

bit

...

> off the > > idea of providing > > > > S3 like > > > > >> > service. > > > > >> > To my understanding, setting OPA to be > > the source of > > > truth would > > > > >> > introduce latency (based on Casey’s > > comments) and will not > > > > allow to > > > > >> > set policies (based on Seena). > > > > >> > The first one brings us towards harder > > latency and > > > especially > > > > >> > depending on extern systems resource > > capability (assume > > > central > > > > >> > resource as the idea is and > therefor not > > necessarily really > > > > “in reach” > > > > >> > within an acceptable latency, > routing in > > addition, > > > etc.). The > > > > second > > > > >> > one says simply that this

would

...

> break any > > existing > > > > compatibility with > > > > >> > clients and use cases. To me

it

...

> looks not > > that good to > > > loose > > > > on both ends. > > > > >> > > > > >> Agreed. Even if one has to opt-in to this > > broken s3 > > > > compatiblity, I'm > > > > >> skeptical that users will find

this

...

> to be a > > compelling target > > > > for their > > > > >> applications. > > > > >> > > > > >> The existing prototype of OPA integration > > sends this > > > authorization > > > > >> request to OPA -in addition to- radosgw's > > own authorization > > > > logic, where > > > > >> we consult any of our

user/bucket

...

> policies > > or ACLs that > > > apply. > > > > In this > > > > >> model, OPA is not the only source of > truth. > > It just has the > > > > opportunity > > > > >> to deny access that we would otherwise > > grant, so it doesn't > > > > require that > > > > >> we break compatibility with any

S3

...

> features > > that conflict > > > with > > > > OPA's > > > > >> view of policy. > > > > >> > > > > >> Were we to change this so that

OPA

...

> was the > > only source of > > > > truth, then > > > > >> we'd be left with two bad options: either > > reject all requests > > > > to modify > > > > >> policy and break existing > applications, or > > send all > > > policy/ACL > > > > >> information to OPA and require every OPA > > policy script to > > > implement > > > > >> s3-compatible enforcement of them. I also > > don't see any > > > benefit > > > > to this > > > > >> model - why, if an client wants to use s3 > > policy to > > > restrict a > > > > certain > > > > >> access, would OPA want to

override

...

> that and > > grant access > > > instead? > > > > >> > > > > >> > I could live more with the latency > issue > > but wouldn’t > > > like it. > > > > >> > For the second, I can

understand

...

> the idea > > of having > > > > simplification for > > > > >> > auditing the access but I’m not that > > convinced to take the > > > > burden of > > > > >> > being “the special” one that nobody > wants > > to work with. > > > So, I > > > > would > > > > >> > love to see the full fledged support of > > setting the > > > policy by > > > > clients, > > > > >> > no matter what the result would be in > > terms of > > > implementing it to > > > > >> > interact with OPA. Instead, having an > > additional > > > requirement to > > > > >> > implement additional handling to set > > policies different > > > from > > > > what S3 > > > > >> > actually provides would require special > > clients first and > > > > secondly an > > > > >> > additional path to OPA with all the > > additional burden > > > to tweak > > > > >> > security to allow this path to OPA. I > > feel that the first > > > > wouldn’t > > > > >> > happen (special clients) and the second > > in practice not > > > > either because > > > > >> > of security constraints by the OPA > admin > > folks. > > > > >> > > > > > >> > G, > > > > >> > -matt > > > > >> > > > > > >> > —————————————————— > > > > >> > Matthias Muench > > > > >> > Senior Specialist Solution Architect > > > > >> > EMEA Storage Specialist > > > > >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>> > > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>> > > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>>>> > > > > >> > Phone: +49-160-92654111 > > <tel:+49-160-92654111> > > > > >> > > > > > >> > Red Hat GmbH > > > > >> > Werner-von-Siemens-Ring 14 > > <x-apple-data-detectors://2/1> > > > > >> > 85630 Grasbrunn > > <x-apple-data-detectors://2/1> > > > > >> > Germany <x-apple-data-detectors://2/1> > > > > >> > > > > > > > > > > >

_______________________________________________________________________

...

> > > > >> > Red Hat GmbH, http://www.de.redhat.com > > > <http://de.redhat.com/> · > > > > >> > Registered seat: Grasbrunn, Commercial > > register: > > > Amtsgericht > > > > Muenchen > > > > >> > HRB 153243 · Managing

Directors:

...

> Charles > > Cachera, Michael > > > > O'Neill, Tom > > > > >> > Savage, Eric Shander > > > > >> > > > > > >> >> On Jan 28, 2020, at 15:02,

Seena

...

> Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > >> >> > > > > >> >>  > > > > >> >> Amazon AWS S3 has two type of > policies. > > One from bucket > > > > policy and > > > > >> >> one form IAM. I think it could be > better > > to have two > > > > policies models > > > > >> >> in Ceph one from bucket policy and one > > form OPA if its > > > enable. > > > > >> >> So if you are okay we can

change

...

> the PR > > to make bucket > > > > policy enabled > > > > >> >> when OPA is enabled, too. Because now > > bucket policies not > > > > working > > > > >> >> when OPA integration is

enabled.

...

> > > > >> >> > > > > >> >> On Tue, Jan 28, 2020 at 2:57

AM

...

> Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

>> > > > > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: > > > > >> >> > > > > >> >> Matt When OPA

integration is

...

> enabled > > S3 policies > > > doesn’t > > > > work! If > > > > >> >> you want them to be worked we > should > > bypass S3 > > > policies > > > > to OPA > > > > >> >> for being applied and worked. > > > > >> >> Here we have conflict in

OPA

...

> > integration with S3 > > > policies! > > > > >> >> > > > > >> >> On Tue, Jan 28, 2020 at

2:52

...

> AM Matt > > Benjamin > > > > >> >> <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>

I have seen another bad scenario that we have two source of truth. If we get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES and so in rgw_process_authenticated function rgw_opa_authorize will not check! I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized. Do you have any other suggestion? On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

I have changed the PR for sending bucket policy, bucket acl, iam policy and user acl as a field to OPA request so OPA can decision based on this parameters and we can have a external authorization for our organization like AWS IAM. So we can have an S3 service that authorize based on bucket policy and organizations IAM. https://github.com/ceph/ceph/pull/32294 Could you please review this?

On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Also we can add bucket policy result field to OPA request so in OPA policies we can act based on bucket policy results.

Are you agree with it?

On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In bucket policy we have an Effect::Pass in validation result so if we just put OPA authorization in case of Effect::Pass I think it will be close to what AWS do.

On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In organizations that has many services and want to have a centralized authorization server this will be a good solution to have.

I mean that when we just authorize user ReadOnly in OPA but give write access via bucket policy, the user can’t write because OPA is rejecting.

I think we can just weight bucket policy upper that OPA so bucket policies that apply policies specific than OPA policies can accept and reject at first then OPA would authorize that request. I mean bucket policy specify policy more specific (On bucket or on object) than OPA (OPA can set policy globally too like giving ReadOnly to all buckets) so it's better to first check bucket policy then check for OPA. this could be easy solve this problem.

On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> wrote:

...

On 2/6/20 11:58 AM, Seena Fallah wrote:

...

The main goal of using OPA like as AWS IAM is having an external authorization so we can have out own management on policies from external source of truth (OPA) too.

I think it’s better to handle bucket policy with OPA as well as AWS does so we can have a better S3 service :)

Can you expand on why that's better than the model I suggested earlier in the thread, where a centralized policy service uses radosgw's existing IAM APIs to manage policy instead of requiring radosgw to call out to an external service for every request?

I'd also like to clarify what you mean when you say "handle bucket policy with OPA" - my understanding is that it's not something that OPA itself does, but something very specific to your own product's OPA policy script. Am I getting that right? If so, it sounds like you're trying to re-engineer our OPA integration in a way that a) is not useful to OPA users in general, and b) duplicates functionality that radosgw already provides.

For OPA users that just want the ability to write simple scripts to customize authorization for their environment, I think our current level of OPA integration is sufficient.

...

On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:

Is there an advantage to doing this in OPA over radosgw? Have you looked at using our PutUserPolicy[1] APIs instead? We support both user

and

...

bucket policy, and (as far as I know) handle the intersection of the two as you'd expect.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html

...

On 2/5/20 9:55 AM, Seena Fallah wrote: > I'm trying to implement AWS IAM with OPA so I can have external > authorization for my S3 service and also have an active bucket ACL and > bucket policy. > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley <

cbodley@redhat.com

...

<mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>

wrote:

...

> > I'm confused by your references to AWS IAM. Are you talking about > radosgw user policy? Or are you trying to implement IAM

policy

...

> inside of > OPA? > > On 2/5/20 8:54 AM, Seena Fallah wrote: > > Hi all. > > > > Any updates here? :) > > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> > wrote: > > > > I should also mention that if we get access to bucket via bucket > > policy and reject it via AWS IAM, the request will reject so I > > think we should make a new behavior at what we

should do

...

> with this > > two source of truth? > > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com

<mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>

...

<mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>

wrote:

...

> > > > Yes but the main problem is when the policy isn't set in AWS > > IAM for example a user has

only AmazonS3ReadOnlyAccess

...

> and we > > give PutObject policy via bucket policy, user can put object > > to that bucket but in radosgw, OPA will deny this process > > because there is only ReadOnlyAccess to that bucket for user > > and radosgw will not check bucket policy that

gave

...

access to > > user. > > I think we should weight bucket policy over OPA

so

...

if bucket > > policy accept that request it doesn't need to be checked > with > > OPA BUT if there is no policy according to that request it > > should check by OPA because if the policy according to that > > request isn't set bucket policy will reject that request > so it > > against failed! > > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley > > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> wrote: > > > > > > On 1/30/20 2:18 PM, Seena Fallah wrote: > > > Hi Casey, > > > > > > The main problem now is when OPA

integration is

...

> enabled > > bucket > > > policies aren’t work! > > > I have checked AWS S3 that what is doing when both > > bucket policy and > > > IAM policy (the policy is set with AWS

panel

...

in IAM > > section) is set it > > > will OR between two of them so now in radosgw S3 we > > don’t have this > > > feature and bucket policies won’t work

when OPA

...

> > integration is enabled. > > > > > > So I think it’s better to active this feature and > > enabled bucket > > > policy when OpA integration is enabled. > > > > > > There is two solutions here in this discussion for > > enabling bucket > > > policy on OPA integration: > > > 1. Send bucket policy on set/del actions to OPA server > > to be apply on > > > OPA policy rules so in this case the source of truth > > will be OPA (the > > > state that we have now in OPA integration) and so > these > > policies that > > > sent from bucket policy will be applied. > > > 2. OR between bucket policy and OPA policy

like

...

> AWS S3. > > So there is > > > two source of truth in this case and if

any of

...

> them deny > > the request, > > > the request will be denied. > > > > What you described here in 2. is exactly how

it

...

> currently > > works. > > > > > > > > Do have any other solutions we have here

and

...

which of > > these solutions > > > do you prefer to have? > > > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey

Bodley

...

> > <cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>>> > > wrote: > > > > > > Hi Seena, > > > > > > I think it would probably help if you

could

...

> describe > > your use case > > > here, > > > and what role you want OPA to play in

the

...

> > interpretation of these > > > bucket > > > policies. In other words, what is it that your OPA > > policy is doing > > > with > > > these bucket policy documents that

shouldn't

...

> be done > > within radosgw? > > > > > > On 1/30/20 1:09 AM, Seena Fallah wrote: > > > > So Matt what should we have done with bucket > > policy if we enable > > > OPA > > > > integration? > > > > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin > > > <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com >>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>>>>> wrote: > > > > > > > > I think we should not be introducing new > > special case > > > behavior, nor > > > > sending policy documents to OPA, which from > > what we have > > > heard and > > > > read, intends to make no use of

them.

...

> > > > > > > > Matt > > > > > > > > On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>>

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > > > > > > > I think it’s better to OR between two > of the > > bucket > > > policies and > > > > OPA policies. So if one of them

reject

...

> certain > > access the > > > request > > > > will reject as AWS do on its IAM and bucket > > policy. > > > > > Are you okay with this idea? > > > > > > > > > > On Wed, Jan 29, 2020 at 11:13

PM

...

Casey > Bodley > > > > <cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>>>> wrote: > > > > >> > > > > >> > > > > >> On 1/28/20 2:45 PM, Matthias

Muench

...

> wrote: > > > > >> > Hi, > > > > >> > I think making Ceph special to what the > > rest of the clients > > > > in the > > > > >> > world would expect would be

a bit

...

> off the > > idea of providing > > > > S3 like > > > > >> > service. > > > > >> > To my understanding, setting OPA to be > > the source of > > > truth would > > > > >> > introduce latency (based on Casey’s > > comments) and will not > > > > allow to > > > > >> > set policies (based on

Seena).

...

> > > > >> > The first one brings us towards harder > > latency and > > > especially > > > > >> > depending on extern systems resource > > capability (assume > > > central > > > > >> > resource as the idea is and > therefor not > > necessarily really > > > > “in reach” > > > > >> > within an acceptable

latency,

...

> routing in > > addition, > > > etc.). The > > > > second > > > > >> > one says simply that this

would

...

> break any > > existing > > > > compatibility with > > > > >> > clients and use cases. To

me it

...

> looks not > > that good to > > > loose > > > > on both ends. > > > > >> > > > > >> Agreed. Even if one has to opt-in to this > > broken s3 > > > > compatiblity, I'm > > > > >> skeptical that users will

find this

...

> to be a > > compelling target > > > > for their > > > > >> applications. > > > > >> > > > > >> The existing prototype of OPA integration > > sends this > > > authorization > > > > >> request to OPA -in addition

to-

...

radosgw's > > own authorization > > > > logic, where > > > > >> we consult any of our

user/bucket

...

> policies > > or ACLs that > > > apply. > > > > In this > > > > >> model, OPA is not the only source of > truth. > > It just has the > > > > opportunity > > > > >> to deny access that we would otherwise > > grant, so it doesn't > > > > require that > > > > >> we break compatibility with

any S3

...

> features > > that conflict > > > with > > > > OPA's > > > > >> view of policy. > > > > >> > > > > >> Were we to change this so

that OPA

...

> was the > > only source of > > > > truth, then > > > > >> we'd be left with two bad options: either > > reject all requests > > > > to modify > > > > >> policy and break existing > applications, or > > send all > > > policy/ACL > > > > >> information to OPA and require every OPA > > policy script to > > > implement > > > > >> s3-compatible enforcement of them. I also > > don't see any > > > benefit > > > > to this > > > > >> model - why, if an client

wants

...

to use s3 > > policy to > > > restrict a > > > > certain > > > > >> access, would OPA want to

override

...

> that and > > grant access > > > instead? > > > > >> > > > > >> > I could live more with the latency > issue > > but wouldn’t > > > like it. > > > > >> > For the second, I can

understand

...

> the idea > > of having > > > > simplification for > > > > >> > auditing the access but I’m not that > > convinced to take the > > > > burden of > > > > >> > being “the special” one that nobody > wants > > to work with. > > > So, I > > > > would > > > > >> > love to see the full fledged support of > > setting the > > > policy by > > > > clients, > > > > >> > no matter what the result would be in > > terms of > > > implementing it to > > > > >> > interact with OPA. Instead, having an > > additional > > > requirement to > > > > >> > implement additional

handling

...

to set > > policies different > > > from > > > > what S3 > > > > >> > actually provides would require special > > clients first and > > > > secondly an > > > > >> > additional path to OPA with all the > > additional burden > > > to tweak > > > > >> > security to allow this path to OPA. I > > feel that the first > > > > wouldn’t > > > > >> > happen (special clients) and the second > > in practice not > > > > either because > > > > >> > of security constraints by the OPA > admin > > folks. > > > > >> > > > > > >> > G, > > > > >> > -matt > > > > >> > > > > > >> > —————————————————— > > > > >> > Matthias Muench > > > > >> > Senior Specialist Solution Architect > > > > >> > EMEA Storage Specialist > > > > >> > matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>> > > > > <mailto:

matthias.muench@redhat.com

...

<mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>> > > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>> > > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com> > <mailto:matthias.muench@redhat.com <mailto:matthias.muench@redhat.com>>>>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>>> > > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>>>> > > > > >> > Phone: +49-160-92654111 > > <tel:+49-160-92654111> > > > > >> > > > > > >> > Red Hat GmbH > > > > >> > Werner-von-Siemens-Ring 14 > > <x-apple-data-detectors://2/1> > > > > >> > 85630 Grasbrunn > > <x-apple-data-detectors://2/1> > > > > >> > Germany <x-apple-data-detectors://2/1> > > > > >> > > > > > > > > > > >

_______________________________________________________________________

...

> > > > >> > Red Hat GmbH, http://www.de.redhat.com > > > <http://de.redhat.com/> · > > > > >> > Registered seat: Grasbrunn, Commercial > > register: > > > Amtsgericht > > > > Muenchen > > > > >> > HRB 153243 · Managing

Directors:

...

> Charles > > Cachera, Michael > > > > O'Neill, Tom > > > > >> > Savage, Eric Shander > > > > >> > > > > > >> >> On Jan 28, 2020, at 15:02,

Seena

...

> Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>>

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > >> >> > > > > >> >>  > > > > >> >> Amazon AWS S3 has two type

of

...

> policies. > > One from bucket > > > > policy and > > > > >> >> one form IAM. I think it could be > better > > to have two > > > > policies models > > > > >> >> in Ceph one from bucket policy and one > > form OPA if its > > > enable. > > > > >> >> So if you are okay we can

change

...

> the PR > > to make bucket > > > > policy enabled > > > > >> >> when OPA is enabled, too. Because now > > bucket policies not > > > > working > > > > >> >> when OPA integration is

enabled.

...

> > > > >> >> > > > > >> >> On Tue, Jan 28, 2020 at

2:57 AM

...

> Seena Fallah > > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>>

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>>>

...

> > > > >> >> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>>

...

> > > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>>

...

> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:

seenafallah@gmail.com>>

...

> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>>>>> wrote: > > > > >> >> > > > > >> >> Matt When OPA

integration is

...

> enabled > > S3 policies > > > doesn’t > > > > work! If > > > > >> >> you want them to be worked we > should > > bypass S3 > > > policies > > > > to OPA > > > > >> >> for being applied and worked. > > > > >> >> Here we have conflict

in OPA

...

> > integration with S3 > > > policies! > > > > >> >> > > > > >> >> On Tue, Jan 28, 2020

at 2:52

...

> AM Matt > > Benjamin > > > > >> >> <mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com >>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com >>>> > > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com >>> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>

In a simple way I should say that OPA can't get access to something that radosgw isn't allowing. For example if I want to get access to user A for my bucket in OPA policies it will reject because radosgw doesn't have this policy and will reject. OPA can just reject requests and it's BUG. Can you please fix this bug with this PR? :) On Thu, Feb 20, 2020 at 11:43 AM Seena Fallah <seenafallah@gmail.com> wrote:

I have make this PR to make OPA single source of truth so OPA can get access to not owned bucket for user. And also in OPA request we send bucket policy, acl, ... to OPA so we can support them when OPA integration is enabled. We will authorized user based on bucket policy, acl, ... and OPA policies in OPA server. Can you please take a look at here? https://github.com/ceph/ceph/pull/32294

On Tue, Feb 18, 2020 at 9:52 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have seen another bad scenario that we have two source of truth. If we get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES and so in rgw_process_authenticated function rgw_opa_authorize will not check!

I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized.

Do you have any other suggestion?

On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have changed the PR for sending bucket policy, bucket acl, iam policy and user acl as a field to OPA request so OPA can decision based on this parameters and we can have a external authorization for our organization like AWS IAM. So we can have an S3 service that authorize based on bucket policy and organizations IAM. https://github.com/ceph/ceph/pull/32294 Could you please review this?

On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Also we can add bucket policy result field to OPA request so in OPA policies we can act based on bucket policy results.

Are you agree with it?

On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In bucket policy we have an Effect::Pass in validation result so if we just put OPA authorization in case of Effect::Pass I think it will be close to what AWS do.

On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In organizations that has many services and want to have a centralized authorization server this will be a good solution to have.

I mean that when we just authorize user ReadOnly in OPA but give write access via bucket policy, the user can’t write because OPA is rejecting.

I think we can just weight bucket policy upper that OPA so bucket policies that apply policies specific than OPA policies can accept and reject at first then OPA would authorize that request. I mean bucket policy specify policy more specific (On bucket or on object) than OPA (OPA can set policy globally too like giving ReadOnly to all buckets) so it's better to first check bucket policy then check for OPA. this could be easy solve this problem.

On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> wrote:

> > On 2/6/20 11:58 AM, Seena Fallah wrote: > > The main goal of using OPA like as AWS IAM is having an external > > authorization so we can have out own management on policies from > > external source of truth (OPA) too. > > > > I think it’s better to handle bucket policy with OPA as well as > AWS > > does so we can have a better S3 service :) > > Can you expand on why that's better than the model I suggested > earlier > in the thread, where a centralized policy service uses radosgw's > existing IAM APIs to manage policy instead of requiring radosgw to > call > out to an external service for every request? > > I'd also like to clarify what you mean when you say "handle bucket > policy with OPA" - my understanding is that it's not something that > OPA > itself does, but something very specific to your own product's OPA > policy script. Am I getting that right? If so, it sounds like you're > trying to re-engineer our OPA integration in a way that a) is not > useful > to OPA users in general, and b) duplicates functionality that > radosgw > already provides. > > For OPA users that just want the ability to write simple scripts to > customize authorization for their environment, I think our current > level > of OPA integration is sufficient. > > > > > On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com > > <mailto:cbodley@redhat.com>> wrote: > > > > Is there an advantage to doing this in OPA over radosgw? Have > you > > looked > > at using our PutUserPolicy[1] APIs instead? We support both > user and > > bucket policy, and (as far as I know) handle the intersection > of > > the two > > as you'd expect. > > > > > https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html > > > > On 2/5/20 9:55 AM, Seena Fallah wrote: > > > I'm trying to implement AWS IAM with OPA so I can have > external > > > authorization for my S3 service and also have an active > bucket > > ACL and > > > bucket policy. > > > > > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley < > cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > wrote: > > > > > > I'm confused by your references to AWS IAM. Are you > talking > > about > > > radosgw user policy? Or are you trying to implement IAM > policy > > > inside of > > > OPA? > > > > > > On 2/5/20 8:54 AM, Seena Fallah wrote: > > > > Hi all. > > > > > > > > Any updates here? :) > > > > > > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah > > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>>>> > > > wrote: > > > > > > > > I should also mention that if we get access to > bucket > > via bucket > > > > policy and reject it via AWS IAM, the request will > > reject so I > > > > think we should make a new behavior at what we > should do > > > with this > > > > two source of truth? > > > > > > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah > > > > <seenafallah@gmail.com <mailto: > seenafallah@gmail.com> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> > wrote: > > > > > > > > Yes but the main problem is when the policy > isn't > > set in AWS > > > > IAM for example a user has > only AmazonS3ReadOnlyAccess > > > and we > > > > give PutObject policy via bucket policy, user > can > > put object > > > > to that bucket but in radosgw, OPA will deny > this > > process > > > > because there is only ReadOnlyAccess to that > > bucket for user > > > > and radosgw will not check bucket policy that > gave > > access to > > > > user. > > > > I think we should weight bucket policy over > OPA so > > if bucket > > > > policy accept that request it doesn't need to > be > > checked > > > with > > > > OPA BUT if there is no policy according to that > > request it > > > > should check by OPA because if the policy > > according to that > > > > request isn't set bucket policy will reject > that > > request > > > so it > > > > against failed! > > > > > > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley > > > > <cbodley@redhat.com <mailto:cbodley@redhat.com > > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> > wrote: > > > > > > > > > > > > On 1/30/20 2:18 PM, Seena Fallah wrote: > > > > > Hi Casey, > > > > > > > > > > The main problem now is when OPA > integration is > > > enabled > > > > bucket > > > > > policies aren’t work! > > > > > I have checked AWS S3 that what is doing > > when both > > > > bucket policy and > > > > > IAM policy (the policy is set with AWS > panel > > in IAM > > > > section) is set it > > > > > will OR between two of them so now in > > radosgw S3 we > > > > don’t have this > > > > > feature and bucket policies won’t work > when OPA > > > > integration is enabled. > > > > > > > > > > So I think it’s better to active this > > feature and > > > > enabled bucket > > > > > policy when OpA integration is enabled. > > > > > > > > > > There is two solutions here in this > > discussion for > > > > enabling bucket > > > > > policy on OPA integration: > > > > > 1. Send bucket policy on set/del actions > to > > OPA server > > > > to be apply on > > > > > OPA policy rules so in this case the > source > > of truth > > > > will be OPA (the > > > > > state that we have now in OPA > integration) > > and so > > > these > > > > policies that > > > > > sent from bucket policy will be applied. > > > > > 2. OR between bucket policy and OPA > policy like > > > AWS S3. > > > > So there is > > > > > two source of truth in this case and if > any of > > > them deny > > > > the request, > > > > > the request will be denied. > > > > > > > > What you described here in 2. is exactly > how it > > > currently > > > > works. > > > > > > > > > > > > > > Do have any other solutions we have here > and > > which of > > > > these solutions > > > > > do you prefer to have? > > > > > > > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey > Bodley > > > > <cbodley@redhat.com > > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com>> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com > >>>>> > > > > wrote: > > > > > > > > > > Hi Seena, > > > > > > > > > > I think it would probably help if > you could > > > describe > > > > your use case > > > > > here, > > > > > and what role you want OPA to play > in the > > > > interpretation of these > > > > > bucket > > > > > policies. In other words, what is it > > that your OPA > > > > policy is doing > > > > > with > > > > > these bucket policy documents that > shouldn't > > > be done > > > > within radosgw? > > > > > > > > > > On 1/30/20 1:09 AM, Seena Fallah > wrote: > > > > > > So Matt what should we have done > with > > bucket > > > > policy if we enable > > > > > OPA > > > > > > integration? > > > > > > > > > > > > On Thu, Jan 30, 2020 at 1:45 AM > Matt > > Benjamin > > > > > <mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>>> > > > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com>>>>>> wrote: > > > > > > > > > > > > I think we should not be > > introducing new > > > > special case > > > > > behavior, nor > > > > > > sending policy documents to > OPA, > > which from > > > > what we have > > > > > heard and > > > > > > read, intends to make no use > of them. > > > > > > > > > > > > Matt > > > > > > > > > > > > On Wed, Jan 29, 2020 at 4:45 PM > > Seena Fallah > > > > > > <seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>>> > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > > > > > > > > > > > I think it’s better to OR > > between two > > > of the > > > > bucket > > > > > policies and > > > > > > OPA policies. So if one of > them reject > > > certain > > > > access the > > > > > request > > > > > > will reject as AWS do on its > IAM > > and bucket > > > > policy. > > > > > > > Are you okay with this idea? > > > > > > > > > > > > > > On Wed, Jan 29, 2020 at > 11:13 PM > > Casey > > > Bodley > > > > > > <cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com>>>> > > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> > > > > <mailto:cbodley@redhat.com > > <mailto:cbodley@redhat.com> > > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com > >>>>>> > > wrote: > > > > > > >> > > > > > > >> > > > > > > >> On 1/28/20 2:45 PM, > Matthias Muench > > > wrote: > > > > > > >> > Hi, > > > > > > >> > I think making Ceph > special > > to what the > > > > rest of the clients > > > > > > in the > > > > > > >> > world would expect would > be a bit > > > off the > > > > idea of providing > > > > > > S3 like > > > > > > >> > service. > > > > > > >> > To my understanding, > setting > > OPA to be > > > > the source of > > > > > truth would > > > > > > >> > introduce latency (based > on > > Casey’s > > > > comments) and will not > > > > > > allow to > > > > > > >> > set policies (based on > Seena). > > > > > > >> > The first one brings us > > towards harder > > > > latency and > > > > > especially > > > > > > >> > depending on extern > systems > > resource > > > > capability (assume > > > > > central > > > > > > >> > resource as the idea is > and > > > therefor not > > > > necessarily really > > > > > > “in reach” > > > > > > >> > within an acceptable > latency, > > > routing in > > > > addition, > > > > > etc.). The > > > > > > second > > > > > > >> > one says simply that this > would > > > break any > > > > existing > > > > > > compatibility with > > > > > > >> > clients and use cases. To > me it > > > looks not > > > > that good to > > > > > loose > > > > > > on both ends. > > > > > > >> > > > > > > >> Agreed. Even if one has to > > opt-in to this > > > > broken s3 > > > > > > compatiblity, I'm > > > > > > >> skeptical that users will > find this > > > to be a > > > > compelling target > > > > > > for their > > > > > > >> applications. > > > > > > >> > > > > > > >> The existing prototype of > OPA > > integration > > > > sends this > > > > > authorization > > > > > > >> request to OPA -in addition > to- > > radosgw's > > > > own authorization > > > > > > logic, where > > > > > > >> we consult any of our > user/bucket > > > policies > > > > or ACLs that > > > > > apply. > > > > > > In this > > > > > > >> model, OPA is not the only > > source of > > > truth. > > > > It just has the > > > > > > opportunity > > > > > > >> to deny access that we would > > otherwise > > > > grant, so it doesn't > > > > > > require that > > > > > > >> we break compatibility with > any S3 > > > features > > > > that conflict > > > > > with > > > > > > OPA's > > > > > > >> view of policy. > > > > > > >> > > > > > > >> Were we to change this so > that OPA > > > was the > > > > only source of > > > > > > truth, then > > > > > > >> we'd be left with two bad > > options: either > > > > reject all requests > > > > > > to modify > > > > > > >> policy and break existing > > > applications, or > > > > send all > > > > > policy/ACL > > > > > > >> information to OPA and > require > > every OPA > > > > policy script to > > > > > implement > > > > > > >> s3-compatible enforcement of > > them. I also > > > > don't see any > > > > > benefit > > > > > > to this > > > > > > >> model - why, if an client > wants > > to use s3 > > > > policy to > > > > > restrict a > > > > > > certain > > > > > > >> access, would OPA want to > override > > > that and > > > > grant access > > > > > instead? > > > > > > >> > > > > > > >> > I could live more with the > > latency > > > issue > > > > but wouldn’t > > > > > like it. > > > > > > >> > For the second, I can > understand > > > the idea > > > > of having > > > > > > simplification for > > > > > > >> > auditing the access but > I’m > > not that > > > > convinced to take the > > > > > > burden of > > > > > > >> > being “the special” one > that > > nobody > > > wants > > > > to work with. > > > > > So, I > > > > > > would > > > > > > >> > love to see the full > fledged > > support of > > > > setting the > > > > > policy by > > > > > > clients, > > > > > > >> > no matter what the result > > would be in > > > > terms of > > > > > implementing it to > > > > > > >> > interact with OPA. > Instead, > > having an > > > > additional > > > > > requirement to > > > > > > >> > implement additional > handling > > to set > > > > policies different > > > > > from > > > > > > what S3 > > > > > > >> > actually provides would > > require special > > > > clients first and > > > > > > secondly an > > > > > > >> > additional path to OPA > with > > all the > > > > additional burden > > > > > to tweak > > > > > > >> > security to allow this > path > > to OPA. I > > > > feel that the first > > > > > > wouldn’t > > > > > > >> > happen (special clients) > and > > the second > > > > in practice not > > > > > > either because > > > > > > >> > of security constraints by > > the OPA > > > admin > > > > folks. > > > > > > >> > > > > > > > >> > G, > > > > > > >> > -matt > > > > > > >> > > > > > > > >> > —————————————————— > > > > > > >> > Matthias Muench > > > > > > >> > Senior Specialist Solution > > Architect > > > > > > >> > EMEA Storage Specialist > > > > > > >> > > matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>> > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>>> > > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>> > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>>>> > > > > > > <mailto: > matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>> > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>>> > > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>> > > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com> > > > <mailto:matthias.muench@redhat.com > > <mailto:matthias.muench@redhat.com>>>>> > > > > <mailto:mmuench@redhat.com > > <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > > > > > <mailto:mmuench@redhat.com > > <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com > >>>> > > > > > > <mailto:mmuench@redhat.com > > <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > > > <mailto:mmuench@redhat.com > > <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>> > > > > <mailto:mmuench@redhat.com > > <mailto:mmuench@redhat.com> > > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com > >>>>>> > > > > > > >> > Phone: +49-160-92654111 > > > > <tel:+49-160-92654111> > > > > > > >> > > > > > > > >> > Red Hat GmbH > > > > > > >> > Werner-von-Siemens-Ring 14 > > > > <x-apple-data-detectors://2/1> > > > > > > >> > 85630 Grasbrunn > > > > <x-apple-data-detectors://2/1> > > > > > > >> > Germany > > <x-apple-data-detectors://2/1> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > _______________________________________________________________________ > > > > > > >> > Red Hat GmbH, > > http://www.de.redhat.com > > > > > <http://de.redhat.com/> · > > > > > > >> > Registered seat: > Grasbrunn, > > Commercial > > > > register: > > > > > Amtsgericht > > > > > > Muenchen > > > > > > >> > HRB 153243 · Managing > Directors: > > > Charles > > > > Cachera, Michael > > > > > > O'Neill, Tom > > > > > > >> > Savage, Eric Shander > > > > > > >> > > > > > > > >> >> On Jan 28, 2020, at > 15:02, Seena > > > Fallah > > > > > > <seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>>> > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>>>>>> wrote: > > > > > > >> >> > > > > > > >> >>  > > > > > > >> >> Amazon AWS S3 has two > type of > > > policies. > > > > One from bucket > > > > > > policy and > > > > > > >> >> one form IAM. I think it > > could be > > > better > > > > to have two > > > > > > policies models > > > > > > >> >> in Ceph one from bucket > > policy and one > > > > form OPA if its > > > > > enable. > > > > > > >> >> So if you are okay we > can change > > > the PR > > > > to make bucket > > > > > > policy enabled > > > > > > >> >> when OPA is enabled, too. > > Because now > > > > bucket policies not > > > > > > working > > > > > > >> >> when OPA integration is > enabled. > > > > > > >> >> > > > > > > >> >> On Tue, Jan 28, 2020 at > 2:57 AM > > > Seena Fallah > > > > > > <seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>>> > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>> <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>>>> > > > > > > >> >> > > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>>> > > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>>> > > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com <mailto: > seenafallah@gmail.com>> > > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com> > > > <mailto:seenafallah@gmail.com > > <mailto:seenafallah@gmail.com>>>>>>> wrote: > > > > > > >> >> > > > > > > >> >> Matt When OPA > integration is > > > enabled > > > > S3 policies > > > > > doesn’t > > > > > > work! If > > > > > > >> >> you want them to be > > worked we > > > should > > > > bypass S3 > > > > > policies > > > > > > to OPA > > > > > > >> >> for being applied and > > worked. > > > > > > >> >> Here we have > conflict in OPA > > > > integration with S3 > > > > > policies! > > > > > > >> >> > > > > > > >> >> On Tue, Jan 28, 2020 > at 2:52 > > > AM Matt > > > > Benjamin > > > > > > >> >> <mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>>> > > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>>>> > > > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>>> > > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >>> > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> > > > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com > >> > > > > <mailto:mbenjami@redhat.com > > <mailto:mbenjami@redhat.com> > >

I don’t think so because the main problem is when OPA integration is enabled we have two source of truth one is radosgw and one is OPA and in a code base when OPA authorize a request after that radosgw authorize it so if user doesn’t own a bucket but we get access to it via OPA will be reject! I think it will be better to have one source of truth when OPA integration is enabled. On Fri, Feb 21, 2020 at 2:30 AM Kyle Bader <kyle.bader@gmail.com> wrote:

Could AssumeRoleWithOPA become a thing?

On Thu, Feb 20, 2020 at 12:17 Seena Fallah <seenafallah@gmail.com> wrote:

...

In a simple way I should say that OPA can't get access to something that radosgw isn't allowing. For example if I want to get access to user A for my bucket in OPA policies it will reject because radosgw doesn't have this policy and will reject. OPA can just reject requests and it's BUG. Can you please fix this bug with this PR? :)

On Thu, Feb 20, 2020 at 11:43 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have make this PR to make OPA single source of truth so OPA can get access to not owned bucket for user. And also in OPA request we send bucket policy, acl, ... to OPA so we can support them when OPA integration is enabled. We will authorized user based on bucket policy, acl, ... and OPA policies in OPA server. Can you please take a look at here? https://github.com/ceph/ceph/pull/32294

On Tue, Feb 18, 2020 at 9:52 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have seen another bad scenario that we have two source of truth. If we get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES and so in rgw_process_authenticated function rgw_opa_authorize will not check!

I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized.

Do you have any other suggestion?

On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have changed the PR for sending bucket policy, bucket acl, iam policy and user acl as a field to OPA request so OPA can decision based on this parameters and we can have a external authorization for our organization like AWS IAM. So we can have an S3 service that authorize based on bucket policy and organizations IAM. https://github.com/ceph/ceph/pull/32294 Could you please review this?

On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Also we can add bucket policy result field to OPA request so in OPA policies we can act based on bucket policy results.

Are you agree with it?

On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah <seenafallah@gmail.com> wrote:

> In bucket policy we have an Effect::Pass in validation result so if > we just put OPA authorization in case of Effect::Pass I think it will be > close to what AWS do. > > On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com> > wrote: > >> In organizations that has many services and want to have a >> centralized authorization server this will be a good solution to have. >> >> I mean that when we just authorize user ReadOnly in OPA but give >> write access via bucket policy, the user can’t write because OPA is >> rejecting. >> >> I think we can just weight bucket policy upper that OPA so bucket >> policies that apply policies specific than OPA policies can accept and >> reject at first then OPA would authorize that request. I mean bucket policy >> specify policy more specific (On bucket or on object) than OPA (OPA can set >> policy globally too like giving ReadOnly to all buckets) so it's better to >> first check bucket policy then check for OPA. this could be easy solve this >> problem. >> >> On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> >> wrote: >> >>> >>> On 2/6/20 11:58 AM, Seena Fallah wrote: >>> > The main goal of using OPA like as AWS IAM is having an external >>> > authorization so we can have out own management on policies from >>> > external source of truth (OPA) too. >>> > >>> > I think it’s better to handle bucket policy with OPA as well as >>> AWS >>> > does so we can have a better S3 service :) >>> >>> Can you expand on why that's better than the model I suggested >>> earlier >>> in the thread, where a centralized policy service uses radosgw's >>> existing IAM APIs to manage policy instead of requiring radosgw to >>> call >>> out to an external service for every request? >>> >>> I'd also like to clarify what you mean when you say "handle bucket >>> policy with OPA" - my understanding is that it's not something >>> that OPA >>> itself does, but something very specific to your own product's OPA >>> policy script. Am I getting that right? If so, it sounds like >>> you're >>> trying to re-engineer our OPA integration in a way that a) is not >>> useful >>> to OPA users in general, and b) duplicates functionality that >>> radosgw >>> already provides. >>> >>> For OPA users that just want the ability to write simple scripts >>> to >>> customize authorization for their environment, I think our current >>> level >>> of OPA integration is sufficient. >>> >>> > >>> > On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com >>> > <mailto:cbodley@redhat.com>> wrote: >>> > >>> > Is there an advantage to doing this in OPA over radosgw? >>> Have you >>> > looked >>> > at using our PutUserPolicy[1] APIs instead? We support both >>> user and >>> > bucket policy, and (as far as I know) handle the >>> intersection of >>> > the two >>> > as you'd expect. >>> > >>> > >>> https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html >>> > >>> > On 2/5/20 9:55 AM, Seena Fallah wrote: >>> > > I'm trying to implement AWS IAM with OPA so I can have >>> external >>> > > authorization for my S3 service and also have an active >>> bucket >>> > ACL and >>> > > bucket policy. >>> > > >>> > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley < >>> cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >>> wrote: >>> > > >>> > > I'm confused by your references to AWS IAM. Are you >>> talking >>> > about >>> > > radosgw user policy? Or are you trying to implement >>> IAM policy >>> > > inside of >>> > > OPA? >>> > > >>> > > On 2/5/20 8:54 AM, Seena Fallah wrote: >>> > > > Hi all. >>> > > > >>> > > > Any updates here? :) >>> > > > >>> > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah >>> > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com >>> >> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>>>> >>> > > wrote: >>> > > > >>> > > > I should also mention that if we get access to >>> bucket >>> > via bucket >>> > > > policy and reject it via AWS IAM, the request >>> will >>> > reject so I >>> > > > think we should make a new behavior at what we >>> should do >>> > > with this >>> > > > two source of truth? >>> > > > >>> > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >>> > > > <seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com> >>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com >>> >> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com> >>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>> >>> wrote: >>> > > > >>> > > > Yes but the main problem is when the policy >>> isn't >>> > set in AWS >>> > > > IAM for example a user has >>> only AmazonS3ReadOnlyAccess >>> > > and we >>> > > > give PutObject policy via bucket policy, >>> user can >>> > put object >>> > > > to that bucket but in radosgw, OPA will deny >>> this >>> > process >>> > > > because there is only ReadOnlyAccess to that >>> > bucket for user >>> > > > and radosgw will not check bucket policy >>> that gave >>> > access to >>> > > > user. >>> > > > I think we should weight bucket policy over >>> OPA so >>> > if bucket >>> > > > policy accept that request it doesn't need >>> to be >>> > checked >>> > > with >>> > > > OPA BUT if there is no policy according to >>> that >>> > request it >>> > > > should check by OPA because if the policy >>> > according to that >>> > > > request isn't set bucket policy will reject >>> that >>> > request >>> > > so it >>> > > > against failed! >>> > > > >>> > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >>> > > > <cbodley@redhat.com <mailto: >>> cbodley@redhat.com> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >>> wrote: >>> > > > >>> > > > >>> > > > On 1/30/20 2:18 PM, Seena Fallah wrote: >>> > > > > Hi Casey, >>> > > > > >>> > > > > The main problem now is when OPA >>> integration is >>> > > enabled >>> > > > bucket >>> > > > > policies aren’t work! >>> > > > > I have checked AWS S3 that what is >>> doing >>> > when both >>> > > > bucket policy and >>> > > > > IAM policy (the policy is set with AWS >>> panel >>> > in IAM >>> > > > section) is set it >>> > > > > will OR between two of them so now in >>> > radosgw S3 we >>> > > > don’t have this >>> > > > > feature and bucket policies won’t work >>> when OPA >>> > > > integration is enabled. >>> > > > > >>> > > > > So I think it’s better to active this >>> > feature and >>> > > > enabled bucket >>> > > > > policy when OpA integration is enabled. >>> > > > > >>> > > > > There is two solutions here in this >>> > discussion for >>> > > > enabling bucket >>> > > > > policy on OPA integration: >>> > > > > 1. Send bucket policy on set/del >>> actions to >>> > OPA server >>> > > > to be apply on >>> > > > > OPA policy rules so in this case the >>> source >>> > of truth >>> > > > will be OPA (the >>> > > > > state that we have now in OPA >>> integration) >>> > and so >>> > > these >>> > > > policies that >>> > > > > sent from bucket policy will be >>> applied. >>> > > > > 2. OR between bucket policy and OPA >>> policy like >>> > > AWS S3. >>> > > > So there is >>> > > > > two source of truth in this case and >>> if any of >>> > > them deny >>> > > > the request, >>> > > > > the request will be denied. >>> > > > >>> > > > What you described here in 2. is exactly >>> how it >>> > > currently >>> > > > works. >>> > > > >>> > > > > >>> > > > > Do have any other solutions we have >>> here and >>> > which of >>> > > > these solutions >>> > > > > do you prefer to have? >>> > > > > >>> > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey >>> Bodley >>> > > > <cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com>> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >>> > > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >>>>> >>> > > > wrote: >>> > > > > >>> > > > > Hi Seena, >>> > > > > >>> > > > > I think it would probably help if >>> you could >>> > > describe >>> > > > your use case >>> > > > > here, >>> > > > > and what role you want OPA to play >>> in the >>> > > > interpretation of these >>> > > > > bucket >>> > > > > policies. In other words, what is >>> it >>> > that your OPA >>> > > > policy is doing >>> > > > > with >>> > > > > these bucket policy documents that >>> shouldn't >>> > > be done >>> > > > within radosgw? >>> > > > > >>> > > > > On 1/30/20 1:09 AM, Seena Fallah >>> wrote: >>> > > > > > So Matt what should we have done >>> with >>> > bucket >>> > > > policy if we enable >>> > > > > OPA >>> > > > > > integration? >>> > > > > > >>> > > > > > On Thu, Jan 30, 2020 at 1:45 AM >>> Matt >>> > Benjamin >>> > > > > <mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>>> >>> > > > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com>>>>>> wrote: >>> > > > > > >>> > > > > > I think we should not be >>> > introducing new >>> > > > special case >>> > > > > behavior, nor >>> > > > > > sending policy documents to >>> OPA, >>> > which from >>> > > > what we have >>> > > > > heard and >>> > > > > > read, intends to make no use >>> of them. >>> > > > > > >>> > > > > > Matt >>> > > > > > >>> > > > > > On Wed, Jan 29, 2020 at 4:45 >>> PM >>> > Seena Fallah >>> > > > > > <seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>> <mailto: >>> seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>>> >>> > > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>> > > > > > > >>> > > > > > > I think it’s better to OR >>> > between two >>> > > of the >>> > > > bucket >>> > > > > policies and >>> > > > > > OPA policies. So if one of >>> them reject >>> > > certain >>> > > > access the >>> > > > > request >>> > > > > > will reject as AWS do on its >>> IAM >>> > and bucket >>> > > > policy. >>> > > > > > > Are you okay with this >>> idea? >>> > > > > > > >>> > > > > > > On Wed, Jan 29, 2020 at >>> 11:13 PM >>> > Casey >>> > > Bodley >>> > > > > > <cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >> >>> > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >>> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >> >>> > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com>>>> >>> > > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >> >>> > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >>> >>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >> >>> > > > <mailto:cbodley@redhat.com >>> > <mailto:cbodley@redhat.com> >>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >>> >>>>>> >>> > wrote: >>> > > > > > >> >>> > > > > > >> >>> > > > > > >> On 1/28/20 2:45 PM, >>> Matthias Muench >>> > > wrote: >>> > > > > > >> > Hi, >>> > > > > > >> > I think making Ceph >>> special >>> > to what the >>> > > > rest of the clients >>> > > > > > in the >>> > > > > > >> > world would expect >>> would be a bit >>> > > off the >>> > > > idea of providing >>> > > > > > S3 like >>> > > > > > >> > service. >>> > > > > > >> > To my understanding, >>> setting >>> > OPA to be >>> > > > the source of >>> > > > > truth would >>> > > > > > >> > introduce latency >>> (based on >>> > Casey’s >>> > > > comments) and will not >>> > > > > > allow to >>> > > > > > >> > set policies (based on >>> Seena). >>> > > > > > >> > The first one brings us >>> > towards harder >>> > > > latency and >>> > > > > especially >>> > > > > > >> > depending on extern >>> systems >>> > resource >>> > > > capability (assume >>> > > > > central >>> > > > > > >> > resource as the idea is >>> and >>> > > therefor not >>> > > > necessarily really >>> > > > > > “in reach” >>> > > > > > >> > within an acceptable >>> latency, >>> > > routing in >>> > > > addition, >>> > > > > etc.). The >>> > > > > > second >>> > > > > > >> > one says simply that >>> this would >>> > > break any >>> > > > existing >>> > > > > > compatibility with >>> > > > > > >> > clients and use cases. >>> To me it >>> > > looks not >>> > > > that good to >>> > > > > loose >>> > > > > > on both ends. >>> > > > > > >> >>> > > > > > >> Agreed. Even if one has to >>> > opt-in to this >>> > > > broken s3 >>> > > > > > compatiblity, I'm >>> > > > > > >> skeptical that users will >>> find this >>> > > to be a >>> > > > compelling target >>> > > > > > for their >>> > > > > > >> applications. >>> > > > > > >> >>> > > > > > >> The existing prototype of >>> OPA >>> > integration >>> > > > sends this >>> > > > > authorization >>> > > > > > >> request to OPA -in >>> addition to- >>> > radosgw's >>> > > > own authorization >>> > > > > > logic, where >>> > > > > > >> we consult any of our >>> user/bucket >>> > > policies >>> > > > or ACLs that >>> > > > > apply. >>> > > > > > In this >>> > > > > > >> model, OPA is not the only >>> > source of >>> > > truth. >>> > > > It just has the >>> > > > > > opportunity >>> > > > > > >> to deny access that we >>> would >>> > otherwise >>> > > > grant, so it doesn't >>> > > > > > require that >>> > > > > > >> we break compatibility >>> with any S3 >>> > > features >>> > > > that conflict >>> > > > > with >>> > > > > > OPA's >>> > > > > > >> view of policy. >>> > > > > > >> >>> > > > > > >> Were we to change this so >>> that OPA >>> > > was the >>> > > > only source of >>> > > > > > truth, then >>> > > > > > >> we'd be left with two bad >>> > options: either >>> > > > reject all requests >>> > > > > > to modify >>> > > > > > >> policy and break existing >>> > > applications, or >>> > > > send all >>> > > > > policy/ACL >>> > > > > > >> information to OPA and >>> require >>> > every OPA >>> > > > policy script to >>> > > > > implement >>> > > > > > >> s3-compatible enforcement >>> of >>> > them. I also >>> > > > don't see any >>> > > > > benefit >>> > > > > > to this >>> > > > > > >> model - why, if an client >>> wants >>> > to use s3 >>> > > > policy to >>> > > > > restrict a >>> > > > > > certain >>> > > > > > >> access, would OPA want to >>> override >>> > > that and >>> > > > grant access >>> > > > > instead? >>> > > > > > >> >>> > > > > > >> > I could live more with >>> the >>> > latency >>> > > issue >>> > > > but wouldn’t >>> > > > > like it. >>> > > > > > >> > For the second, I can >>> understand >>> > > the idea >>> > > > of having >>> > > > > > simplification for >>> > > > > > >> > auditing the access but >>> I’m >>> > not that >>> > > > convinced to take the >>> > > > > > burden of >>> > > > > > >> > being “the special” one >>> that >>> > nobody >>> > > wants >>> > > > to work with. >>> > > > > So, I >>> > > > > > would >>> > > > > > >> > love to see the full >>> fledged >>> > support of >>> > > > setting the >>> > > > > policy by >>> > > > > > clients, >>> > > > > > >> > no matter what the >>> result >>> > would be in >>> > > > terms of >>> > > > > implementing it to >>> > > > > > >> > interact with OPA. >>> Instead, >>> > having an >>> > > > additional >>> > > > > requirement to >>> > > > > > >> > implement additional >>> handling >>> > to set >>> > > > policies different >>> > > > > from >>> > > > > > what S3 >>> > > > > > >> > actually provides would >>> > require special >>> > > > clients first and >>> > > > > > secondly an >>> > > > > > >> > additional path to OPA >>> with >>> > all the >>> > > > additional burden >>> > > > > to tweak >>> > > > > > >> > security to allow this >>> path >>> > to OPA. I >>> > > > feel that the first >>> > > > > > wouldn’t >>> > > > > > >> > happen (special >>> clients) and >>> > the second >>> > > > in practice not >>> > > > > > either because >>> > > > > > >> > of security constraints >>> by >>> > the OPA >>> > > admin >>> > > > folks. >>> > > > > > >> > >>> > > > > > >> > G, >>> > > > > > >> > -matt >>> > > > > > >> > >>> > > > > > >> > —————————————————— >>> > > > > > >> > Matthias Muench >>> > > > > > >> > Senior Specialist >>> Solution >>> > Architect >>> > > > > > >> > EMEA Storage Specialist >>> > > > > > >> > >>> matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>> >>> > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>>> >>> > > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>> >>> > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>>>> >>> > > > > > <mailto: >>> matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>> >>> > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>>> >>> > > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>> >>> > > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com> >>> > > <mailto:matthias.muench@redhat.com >>> > <mailto:matthias.muench@redhat.com>>>>> >>> > > > <mailto:mmuench@redhat.com >>> > <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >> >>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >>> >>> > > > > <mailto:mmuench@redhat.com >>> > <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >> >>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >>>> >>> > > > > > <mailto:mmuench@redhat.com >>> > <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >> >>> > > > <mailto:mmuench@redhat.com >>> > <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >>> >>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >> >>> > > > <mailto:mmuench@redhat.com >>> > <mailto:mmuench@redhat.com> >>> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >>> >>>>>> >>> > > > > > >> > Phone: +49-160-92654111 >>> > > > <tel:+49-160-92654111> >>> > > > > > >> > >>> > > > > > >> > Red Hat GmbH >>> > > > > > >> > Werner-von-Siemens-Ring >>> 14 >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g> >>> >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g> >>> > >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g> >>> > >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g>> >>> >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g> >>> <x >>> <https://www.google.com/maps/search/Werner-von-Siemens-Ring+14+%0D%0A+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+x?entry=gmail&source=g> >>> -apple-data-detectors://2/1> >>> > > > > > >> > 85630 Grasbrunn >>> > > > <x-apple-data-detectors://2/1> >>> > > > > > >> > Germany >>> > <x-apple-data-detectors://2/1> >>> > > > > > >> > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> _______________________________________________________________________ >>> > > > > > >> > Red Hat GmbH, >>> > http://www.de.redhat.com >>> > > > > <http://de.redhat.com/> · >>> > > > > > >> > Registered seat: >>> Grasbrunn, >>> > Commercial >>> > > > register: >>> > > > > Amtsgericht >>> > > > > > Muenchen >>> > > > > > >> > HRB 153243 · Managing >>> Directors: >>> > > Charles >>> > > > Cachera, Michael >>> > > > > > O'Neill, Tom >>> > > > > > >> > Savage, Eric Shander >>> > > > > > >> > >>> > > > > > >> >> On Jan 28, 2020, at >>> 15:02, Seena >>> > > Fallah >>> > > > > > <seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>> <mailto: >>> seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>>> >>> > > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>> > > > > > >> >> >>> > > > > > >> >>  >>> > > > > > >> >> Amazon AWS S3 has two >>> type of >>> > > policies. >>> > > > One from bucket >>> > > > > > policy and >>> > > > > > >> >> one form IAM. I think >>> it >>> > could be >>> > > better >>> > > > to have two >>> > > > > > policies models >>> > > > > > >> >> in Ceph one from bucket >>> > policy and one >>> > > > form OPA if its >>> > > > > enable. >>> > > > > > >> >> So if you are okay we >>> can change >>> > > the PR >>> > > > to make bucket >>> > > > > > policy enabled >>> > > > > > >> >> when OPA is enabled, >>> too. >>> > Because now >>> > > > bucket policies not >>> > > > > > working >>> > > > > > >> >> when OPA integration >>> is enabled. >>> > > > > > >> >> >>> > > > > > >> >> On Tue, Jan 28, 2020 >>> at 2:57 AM >>> > > Seena Fallah >>> > > > > > <seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>> <mailto: >>> seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>>> >>> > > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>> <mailto: >>> seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>>>> >>> > > > > > >> >> >>> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>>> >>> > > > > > <mailto: >>> seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>>> >>> > > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com <mailto: >>> seenafallah@gmail.com>> >>> > > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com> >>> > > <mailto:seenafallah@gmail.com >>> > <mailto:seenafallah@gmail.com>>>>>>> wrote: >>> > > > > > >> >> >>> > > > > > >> >> Matt When OPA >>> integration is >>> > > enabled >>> > > > S3 policies >>> > > > > doesn’t >>> > > > > > work! If >>> > > > > > >> >> you want them to be >>> > worked we >>> > > should >>> > > > bypass S3 >>> > > > > policies >>> > > > > > to OPA >>> > > > > > >> >> for being applied >>> and >>> > worked. >>> > > > > > >> >> Here we have >>> conflict in OPA >>> > > > integration with S3 >>> > > > > policies! >>> > > > > > >> >> >>> > > > > > >> >> On Tue, Jan 28, >>> 2020 at 2:52 >>> > > AM Matt >>> > > > Benjamin >>> > > > > > >> >> < >>> mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>>> >>> > > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>>>> >>> > > > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>>> >>> > > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>>> >>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>> > > <mailto:mbenjami@redhat.com <mailto: >>> mbenjami@redhat.com>> >>> > > > <mailto:mbenjami@redhat.com >>> > <mailto:mbenjami@redhat.com> >>> > >> >> _______________________________________________

...

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

In a code base ( https://github.com/ceph/ceph/pull/32294/files#diff-bb1cc6889525611b45d6af6d5...) in rgw_process_authenticated function we have an IF that check for OPA authorization result after that if it was OK (200) it will call verify_permission() that check with radosgw policies like bucket policy, bucket acl, user acl, .... Now if I create a policy in OPA that user A can access user B's bucket so OPA return OK (200) to radosgw and radosgw will call verify_permission() but in radosgw policies we don't have a policy that user A has access to user B so the request will be reject. So OPA can just reject requests and if OPA accept a request radosgw should also has that policy for being accept to execute. I think it's better to make OPA single source of truth and send bucket policy, acl, ... to OPA in OPA request to be authorized. On Fri, Feb 21, 2020 at 2:09 PM Abhishek Lekshmanan <abhishek@suse.com> wrote:

Seena Fallah <seenafallah@gmail.com> writes:

...

I have make this PR to make OPA single source of truth so OPA can get access to not owned bucket for user. And also in OPA request we send bucket policy, acl, ... to OPA so we can support them when OPA integration is enabled. We will authorized user based on bucket policy, acl, ... and OPA policies in OPA server. Can you please take a look at here? https://github.com/ceph/ceph/pull/32294

How does OPA decide on S3 conditionals wrt Policy here, we already support a few bucket attribute or Object based conditionals

https://docs.ceph.com/docs/master/radosgw/bucketpolicy/#bucket-related-opera...

which can only be evaluated after reading the object in question for eg. These allow for eg. Bucket A would have access to User B to download object iff the object tag has an attribute openaccess = true. Additionally for buckets that are public https://github.com/ceph/ceph/pull/30033 would prevent access when IgnorePublicAcls are true.

...

On Tue, Feb 18, 2020 at 9:52 AM Seena Fallah <seenafallah@gmail.com>

wrote:

...

...

I have seen another bad scenario that we have two source of truth. If we get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES

...

...

so in rgw_process_authenticated function rgw_opa_authorize will not check!

I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized.

Do you have any other suggestion?

On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have changed the PR for sending bucket policy, bucket acl, iam policy and user acl as a field to OPA request so OPA can decision based on

...

...

...

parameters and we can have a external authorization for our organization like AWS IAM. So we can have an S3 service that authorize based on bucket policy and organizations IAM. https://github.com/ceph/ceph/pull/32294 Could you please review this?

On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

Also we can add bucket policy result field to OPA request so in OPA policies we can act based on bucket policy results.

Are you agree with it?

On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In bucket policy we have an Effect::Pass in validation result so if we just put OPA authorization in case of Effect::Pass I think it will be close to what AWS do.

On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com> wrote:

> In organizations that has many services and want to have a centralized > authorization server this will be a good solution to have. > > I mean that when we just authorize user ReadOnly in OPA but give write > access via bucket policy, the user can’t write because OPA is rejecting. > > I think we can just weight bucket policy upper that OPA so bucket > policies that apply policies specific than OPA policies can accept and > reject at first then OPA would authorize that request. I mean bucket policy > specify policy more specific (On bucket or on object) than OPA (OPA can set > policy globally too like giving ReadOnly to all buckets) so it's better to > first check bucket policy then check for OPA. this could be easy solve this > problem. > > On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> > wrote: > >> >> On 2/6/20 11:58 AM, Seena Fallah wrote: >> > The main goal of using OPA like as AWS IAM is having an external >> > authorization so we can have out own management on policies from >> > external source of truth (OPA) too. >> > >> > I think it’s better to handle bucket policy with OPA as well as AWS >> > does so we can have a better S3 service :) >> >> Can you expand on why that's better than the model I suggested >> earlier >> in the thread, where a centralized policy service uses radosgw's >> existing IAM APIs to manage policy instead of requiring radosgw to >> call >> out to an external service for every request? >> >> I'd also like to clarify what you mean when you say "handle bucket >> policy with OPA" - my understanding is that it's not something that >> OPA >> itself does, but something very specific to your own product's OPA >> policy script. Am I getting that right? If so, it sounds like you're >> trying to re-engineer our OPA integration in a way that a) is not >> useful >> to OPA users in general, and b) duplicates functionality that radosgw >> already provides. >> >> For OPA users that just want the ability to write simple scripts to >> customize authorization for their environment, I think our current >> level >> of OPA integration is sufficient. >> >> > >> > On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley@redhat.com >> > <mailto:cbodley@redhat.com>> wrote: >> > >> > Is there an advantage to doing this in OPA over radosgw? Have >> you >> > looked >> > at using our PutUserPolicy[1] APIs instead? We support both >> user and >> > bucket policy, and (as far as I know) handle the intersection of >> > the two >> > as you'd expect. >> > >> > >> https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html >> > >> > On 2/5/20 9:55 AM, Seena Fallah wrote: >> > > I'm trying to implement AWS IAM with OPA so I can have >> external >> > > authorization for my S3 service and also have an active bucket >> > ACL and >> > > bucket policy. >> > > >> > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley < >> cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >> wrote: >> > > >> > > I'm confused by your references to AWS IAM. Are you >> talking >> > about >> > > radosgw user policy? Or are you trying to implement IAM >> policy >> > > inside of >> > > OPA? >> > > >> > > On 2/5/20 8:54 AM, Seena Fallah wrote: >> > > > Hi all. >> > > > >> > > > Any updates here? :) >> > > > >> > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah >> > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

...

>> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>>>> >> > > wrote: >> > > > >> > > > I should also mention that if we get access to >> bucket >> > via bucket >> > > > policy and reject it via AWS IAM, the request will >> > reject so I >> > > > think we should make a new behavior at what we >> should do >> > > with this >> > > > two source of truth? >> > > > >> > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >> > > > <seenafallah@gmail.com <mailto: >> seenafallah@gmail.com> >> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

...

>> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com> >> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

>> wrote: >> > > > >> > > > Yes but the main problem is when the policy >> isn't >> > set in AWS >> > > > IAM for example a user has >> only AmazonS3ReadOnlyAccess >> > > and we >> > > > give PutObject policy via bucket policy, user >> can >> > put object >> > > > to that bucket but in radosgw, OPA will deny >> this >> > process >> > > > because there is only ReadOnlyAccess to that >> > bucket for user >> > > > and radosgw will not check bucket policy that >> gave >> > access to >> > > > user. >> > > > I think we should weight bucket policy over OPA >> so >> > if bucket >> > > > policy accept that request it doesn't need to be >> > checked >> > > with >> > > > OPA BUT if there is no policy according to

...

...

...

...

...

>> > request it >> > > > should check by OPA because if the policy >> > according to that >> > > > request isn't set bucket policy will reject

...

...

...

...

...

>> > request >> > > so it >> > > > against failed! >> > > > >> > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >> > > > <cbodley@redhat.com <mailto: cbodley@redhat.com> >> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >> wrote: >> > > > >> > > > >> > > > On 1/30/20 2:18 PM, Seena Fallah wrote: >> > > > > Hi Casey, >> > > > > >> > > > > The main problem now is when OPA >> integration is >> > > enabled >> > > > bucket >> > > > > policies aren’t work! >> > > > > I have checked AWS S3 that what is doing >> > when both >> > > > bucket policy and >> > > > > IAM policy (the policy is set with AWS >> panel >> > in IAM >> > > > section) is set it >> > > > > will OR between two of them so now in >> > radosgw S3 we >> > > > don’t have this >> > > > > feature and bucket policies won’t work >> when OPA >> > > > integration is enabled. >> > > > > >> > > > > So I think it’s better to active this >> > feature and >> > > > enabled bucket >> > > > > policy when OpA integration is enabled. >> > > > > >> > > > > There is two solutions here in this >> > discussion for >> > > > enabling bucket >> > > > > policy on OPA integration: >> > > > > 1. Send bucket policy on set/del actions >> to >> > OPA server >> > > > to be apply on >> > > > > OPA policy rules so in this case the >> source >> > of truth >> > > > will be OPA (the >> > > > > state that we have now in OPA integration) >> > and so >> > > these >> > > > policies that >> > > > > sent from bucket policy will be applied. >> > > > > 2. OR between bucket policy and OPA >> policy like >> > > AWS S3. >> > > > So there is >> > > > > two source of truth in this case and if >> any of >> > > them deny >> > > > the request, >> > > > > the request will be denied. >> > > > >> > > > What you described here in 2. is exactly >> how it >> > > currently >> > > > works. >> > > > >> > > > > >> > > > > Do have any other solutions we have here >> and >> > which of >> > > > these solutions >> > > > > do you prefer to have? >> > > > > >> > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey >> Bodley >> > > > <cbodley@redhat.com >> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com>> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >> > > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

...

>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >> >>>>> >> > > > wrote: >> > > > > >> > > > > Hi Seena, >> > > > > >> > > > > I think it would probably help if you >> could >> > > describe >> > > > your use case >> > > > > here, >> > > > > and what role you want OPA to play in >> the >> > > > interpretation of these >> > > > > bucket >> > > > > policies. In other words, what is it >> > that your OPA >> > > > policy is doing >> > > > > with >> > > > > these bucket policy documents that >> shouldn't >> > > be done >> > > > within radosgw? >> > > > > >> > > > > On 1/30/20 1:09 AM, Seena Fallah >> wrote: >> > > > > > So Matt what should we have done >> with >> > bucket >> > > > policy if we enable >> > > > > OPA >> > > > > > integration? >> > > > > > >> > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt >> > Benjamin >> > > > > <mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>>> >> > > > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com>>>>>> wrote: >> > > > > > >> > > > > > I think we should not be >> > introducing new >> > > > special case >> > > > > behavior, nor >> > > > > > sending policy documents to OPA, >> > which from >> > > > what we have >> > > > > heard and >> > > > > > read, intends to make no use of >> them. >> > > > > > >> > > > > > Matt >> > > > > > >> > > > > > On Wed, Jan 29, 2020 at 4:45 PM >> > Seena Fallah >> > > > > > <seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>>> >> > > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>>>>>> wrote: >> > > > > > > >> > > > > > > I think it’s better to OR >> > between two >> > > of the >> > > > bucket >> > > > > policies and >> > > > > > OPA policies. So if one of

...

...

...

...

...

>> reject >> > > certain >> > > > access the >> > > > > request >> > > > > > will reject as AWS do on its IAM >> > and bucket >> > > > policy. >> > > > > > > Are you okay with this idea? >> > > > > > > >> > > > > > > On Wed, Jan 29, 2020 at 11:13 >> PM >> > Casey >> > > Bodley >> > > > > > <cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

...

>> > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

...

>> > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com>>>> >> > > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

...

>> > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com

...

...

...

>> > > > <mailto:cbodley@redhat.com >> > <mailto:cbodley@redhat.com> >> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com >> >>>>>> >> > wrote: >> > > > > > >> >> > > > > > >> >> > > > > > >> On 1/28/20 2:45 PM, Matthias >> Muench >> > > wrote: >> > > > > > >> > Hi, >> > > > > > >> > I think making Ceph special >> > to what the >> > > > rest of the clients >> > > > > > in the >> > > > > > >> > world would expect would >> be a bit >> > > off the >> > > > idea of providing >> > > > > > S3 like >> > > > > > >> > service. >> > > > > > >> > To my understanding, >> setting >> > OPA to be >> > > > the source of >> > > > > truth would >> > > > > > >> > introduce latency (based on >> > Casey’s >> > > > comments) and will not >> > > > > > allow to >> > > > > > >> > set policies (based on >> Seena). >> > > > > > >> > The first one brings us >> > towards harder >> > > > latency and >> > > > > especially >> > > > > > >> > depending on extern systems >> > resource >> > > > capability (assume >> > > > > central >> > > > > > >> > resource as the idea is and >> > > therefor not >> > > > necessarily really >> > > > > > “in reach” >> > > > > > >> > within an acceptable >> latency, >> > > routing in >> > > > addition, >> > > > > etc.). The >> > > > > > second >> > > > > > >> > one says simply that

...

...

...

...

...

>> would >> > > break any >> > > > existing >> > > > > > compatibility with >> > > > > > >> > clients and use cases. To >> me it >> > > looks not >> > > > that good to >> > > > > loose >> > > > > > on both ends. >> > > > > > >> >> > > > > > >> Agreed. Even if one has to >> > opt-in to this >> > > > broken s3 >> > > > > > compatiblity, I'm >> > > > > > >> skeptical that users will >> find this >> > > to be a >> > > > compelling target >> > > > > > for their >> > > > > > >> applications. >> > > > > > >> >> > > > > > >> The existing prototype of OPA >> > integration >> > > > sends this >> > > > > authorization >> > > > > > >> request to OPA -in addition >> to- >> > radosgw's >> > > > own authorization >> > > > > > logic, where >> > > > > > >> we consult any of our >> user/bucket >> > > policies >> > > > or ACLs that >> > > > > apply. >> > > > > > In this >> > > > > > >> model, OPA is not the only >> > source of >> > > truth. >> > > > It just has the >> > > > > > opportunity >> > > > > > >> to deny access that we would >> > otherwise >> > > > grant, so it doesn't >> > > > > > require that >> > > > > > >> we break compatibility with >> any S3 >> > > features >> > > > that conflict >> > > > > with >> > > > > > OPA's >> > > > > > >> view of policy. >> > > > > > >> >> > > > > > >> Were we to change this so >> that OPA >> > > was the >> > > > only source of >> > > > > > truth, then >> > > > > > >> we'd be left with two bad >> > options: either >> > > > reject all requests >> > > > > > to modify >> > > > > > >> policy and break existing >> > > applications, or >> > > > send all >> > > > > policy/ACL >> > > > > > >> information to OPA and >> require >> > every OPA >> > > > policy script to >> > > > > implement >> > > > > > >> s3-compatible enforcement of >> > them. I also >> > > > don't see any >> > > > > benefit >> > > > > > to this >> > > > > > >> model - why, if an client >> wants >> > to use s3 >> > > > policy to >> > > > > restrict a >> > > > > > certain >> > > > > > >> access, would OPA want to >> override >> > > that and >> > > > grant access >> > > > > instead? >> > > > > > >> >> > > > > > >> > I could live more with

...

...

...

...

...

>> > latency >> > > issue >> > > > but wouldn’t >> > > > > like it. >> > > > > > >> > For the second, I can >> understand >> > > the idea >> > > > of having >> > > > > > simplification for >> > > > > > >> > auditing the access but I’m >> > not that >> > > > convinced to take the >> > > > > > burden of >> > > > > > >> > being “the special” one >> that >> > nobody >> > > wants >> > > > to work with. >> > > > > So, I >> > > > > > would >> > > > > > >> > love to see the full >> fledged >> > support of >> > > > setting the >> > > > > policy by >> > > > > > clients, >> > > > > > >> > no matter what the result >> > would be in >> > > > terms of >> > > > > implementing it to >> > > > > > >> > interact with OPA. Instead, >> > having an >> > > > additional >> > > > > requirement to >> > > > > > >> > implement additional >> handling >> > to set >> > > > policies different >> > > > > from >> > > > > > what S3 >> > > > > > >> > actually provides would >> > require special >> > > > clients first and >> > > > > > secondly an >> > > > > > >> > additional path to OPA with >> > all the >> > > > additional burden >> > > > > to tweak >> > > > > > >> > security to allow this

and this that that them this the path

...

...

...

...

...

>> > to OPA. I >> > > > feel that the first >> > > > > > wouldn’t >> > > > > > >> > happen (special clients) >> and >> > the second >> > > > in practice not >> > > > > > either because >> > > > > > >> > of security constraints by >> > the OPA >> > > admin >> > > > folks. >> > > > > > >> > >> > > > > > >> > G, >> > > > > > >> > -matt >> > > > > > >> > >> > > > > > >> > —————————————————— >> > > > > > >> > Matthias Muench >> > > > > > >> > Senior Specialist Solution >> > Architect >> > > > > > >> > EMEA Storage Specialist >> > > > > > >> > matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>> >> > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>>> >> > > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>> >> > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>>>> >> > > > > > <mailto: >> matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>> >> > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>>> >> > > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>> >> > > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com> >> > > <mailto:matthias.muench@redhat.com >> > <mailto:matthias.muench@redhat.com>>>>> >> > > > <mailto:mmuench@redhat.com >> > <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

...

>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

>> > > > > <mailto:mmuench@redhat.com >> > <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

...

>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

>> > > > > > <mailto:mmuench@redhat.com >> > <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

...

>> > > > <mailto:mmuench@redhat.com >> > <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com

...

...

...

>> > > > <mailto:mmuench@redhat.com >> > <mailto:mmuench@redhat.com> >> > > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com >> >>>>>> >> > > > > > >> > Phone: +49-160-92654111 >> > > > <tel:+49-160-92654111> >> > > > > > >> > >> > > > > > >> > Red Hat GmbH >> > > > > > >> > Werner-von-Siemens-Ring 14 >> > > > <x-apple-data-detectors://2/1> >> > > > > > >> > 85630 Grasbrunn >> > > > <x-apple-data-detectors://2/1> >> > > > > > >> > Germany >> > <x-apple-data-detectors://2/1> >> > > > > > >> > >> > > > > > >> > > > > >> > > > >> > > >> > >>

---

...

...

...

...

...

>> > > > > > >> > Red Hat GmbH, >> > http://www.de.redhat.com >> > > > > <http://de.redhat.com/> · >> > > > > > >> > Registered seat: Grasbrunn, >> > Commercial >> > > > register: >> > > > > Amtsgericht >> > > > > > Muenchen >> > > > > > >> > HRB 153243 · Managing >> Directors: >> > > Charles >> > > > Cachera, Michael >> > > > > > O'Neill, Tom >> > > > > > >> > Savage, Eric Shander >> > > > > > >> > >> > > > > > >> >> On Jan 28, 2020, at >> 15:02, Seena >> > > Fallah >> > > > > > <seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>>> >> > > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>>>>>> wrote: >> > > > > > >> >> >> > > > > > >> >>  >> > > > > > >> >> Amazon AWS S3 has two >> type of >> > > policies. >> > > > One from bucket >> > > > > > policy and >> > > > > > >> >> one form IAM. I think it >> > could be >> > > better >> > > > to have two >> > > > > > policies models >> > > > > > >> >> in Ceph one from bucket >> > policy and one >> > > > form OPA if its >> > > > > enable. >> > > > > > >> >> So if you are okay we can >> change >> > > the PR >> > > > to make bucket >> > > > > > policy enabled >> > > > > > >> >> when OPA is enabled, too. >> > Because now >> > > > bucket policies not >> > > > > > working >> > > > > > >> >> when OPA integration is >> enabled. >> > > > > > >> >> >> > > > > > >> >> On Tue, Jan 28, 2020 at >> 2:57 AM >> > > Seena Fallah >> > > > > > <seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>>> >> > > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>>>> >> > > > > > >> >> >> > <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>>> >> > > > > > <mailto: seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>>> >> > > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com <mailto: >> seenafallah@gmail.com>> >> > > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com> >> > > <mailto:seenafallah@gmail.com >> > <mailto:seenafallah@gmail.com>>>>>>> wrote: >> > > > > > >> >> >> > > > > > >> >> Matt When OPA >> integration is >> > > enabled >> > > > S3 policies >> > > > > doesn’t >> > > > > > work! If >> > > > > > >> >> you want them to be >> > worked we >> > > should >> > > > bypass S3 >> > > > > policies >> > > > > > to OPA >> > > > > > >> >> for being applied and >> > worked. >> > > > > > >> >> Here we have conflict >> in OPA >> > > > integration with S3 >> > > > > policies! >> > > > > > >> >> >> > > > > > >> >> On Tue, Jan 28, 2020 >> at 2:52 >> > > AM Matt >> > > > Benjamin >> > > > > > >> >> < mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>>> >> > > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>>>> >> > > > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>>> >> > > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >> >>> >> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >> > > > <mailto:mbenjami@redhat.com >> > <mailto:mbenjami@redhat.com> >> > > >

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

Sorry I get your point now. Yes that policies cant handle with OPA. Maybe it could better to ask for OPA when Policy::eval returns Effect::Pass so if we don't have any bucket policy according to that request we will ask for OPA. In this scenario bucket policy get weight like AWS S3 I think. What is your opinion about this? On Fri, Feb 21, 2020 at 2:28 PM Seena Fallah <seenafallah@gmail.com> wrote:

If we send bucket policy, acl, ... to OPA, in OPA server we can parse them and make decision based on our policies. So we don't break bucket policy, acl, ... support in OPA integration and OPA can gain access to requests based on its policies and bucket policy, acl, ....

On Fri, Feb 21, 2020 at 2:24 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In a code base ( https://github.com/ceph/ceph/pull/32294/files#diff-bb1cc6889525611b45d6af6d5...) in rgw_process_authenticated function we have an IF that check for OPA authorization result after that if it was OK (200) it will call verify_permission() that check with radosgw policies like bucket policy, bucket acl, user acl, .... Now if I create a policy in OPA that user A can access user B's bucket so OPA return OK (200) to radosgw and radosgw will call verify_permission() but in radosgw policies we don't have a policy that user A has access to user B so the request will be reject. So OPA can just reject requests and if OPA accept a request radosgw should also has that policy for being accept to execute.

I think it's better to make OPA single source of truth and send bucket policy, acl, ... to OPA in OPA request to be authorized.

On Fri, Feb 21, 2020 at 2:09 PM Abhishek Lekshmanan <abhishek@suse.com> wrote:

...

Seena Fallah <seenafallah@gmail.com> writes:

...

I have make this PR to make OPA single source of truth so OPA can get access to not owned bucket for user. And also in OPA request we send bucket policy, acl, ... to OPA so we can support them when OPA integration is enabled. We will authorized user based on bucket policy, acl, ... and OPA policies in OPA server. Can you please take a look at here? https://github.com/ceph/ceph/pull/32294

How does OPA decide on S3 conditionals wrt Policy here, we already support a few bucket attribute or Object based conditionals

https://docs.ceph.com/docs/master/radosgw/bucketpolicy/#bucket-related-opera...

which can only be evaluated after reading the object in question for eg. These allow for eg. Bucket A would have access to User B to download object iff the object tag has an attribute openaccess = true. Additionally for buckets that are public https://github.com/ceph/ceph/pull/30033 would prevent access when IgnorePublicAcls are true.

...

On Tue, Feb 18, 2020 at 9:52 AM Seena Fallah <seenafallah@gmail.com>

wrote:

...

...

I have seen another bad scenario that we have two source of truth. If

...

...

get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES and so in rgw_process_authenticated function rgw_opa_authorize will not check!

I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized.

Do you have any other suggestion?

On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

...

I have changed the PR for sending bucket policy, bucket acl, iam

...

...

...

and user acl as a field to OPA request so OPA can decision based on

...

...

...

parameters and we can have a external authorization for our organization like AWS IAM. So we can have an S3 service that authorize based on bucket policy and organizations IAM. https://github.com/ceph/ceph/pull/32294 Could you please review this?

On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com> wrote:

> Also we can add bucket policy result field to OPA request so in OPA > policies we can act based on bucket policy results. > > Are you agree with it? > > On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah < seenafallah@gmail.com> > wrote: > >> In bucket policy we have an Effect::Pass in validation result so if we >> just put OPA authorization in case of Effect::Pass I think it will be close >> to what AWS do. >> >> On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah <seenafallah@gmail.com

...

...

>> wrote: >> >>> In organizations that has many services and want to have a centralized >>> authorization server this will be a good solution to have. >>> >>> I mean that when we just authorize user ReadOnly in OPA but give write >>> access via bucket policy, the user can’t write because OPA is rejecting. >>> >>> I think we can just weight bucket policy upper that OPA so bucket >>> policies that apply policies specific than OPA policies can accept and >>> reject at first then OPA would authorize that request. I mean bucket policy >>> specify policy more specific (On bucket or on object) than OPA (OPA can set >>> policy globally too like giving ReadOnly to all buckets) so it's better to >>> first check bucket policy then check for OPA. this could be easy solve this >>> problem. >>> >>> On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com> >>> wrote: >>> >>>> >>>> On 2/6/20 11:58 AM, Seena Fallah wrote: >>>> > The main goal of using OPA like as AWS IAM is having an external >>>> > authorization so we can have out own management on policies from >>>> > external source of truth (OPA) too. >>>> > >>>> > I think it’s better to handle bucket policy with OPA as well as AWS >>>> > does so we can have a better S3 service :) >>>> >>>> Can you expand on why that's better than the model I suggested >>>> earlier >>>> in the thread, where a centralized policy service uses radosgw's >>>> existing IAM APIs to manage policy instead of requiring radosgw to >>>> call >>>> out to an external service for every request? >>>> >>>> I'd also like to clarify what you mean when you say "handle bucket >>>> policy with OPA" - my understanding is that it's not something

...

...

...

>>>> OPA >>>> itself does, but something very specific to your own product's OPA >>>> policy script. Am I getting that right? If so, it sounds like you're >>>> trying to re-engineer our OPA integration in a way that a) is not >>>> useful >>>> to OPA users in general, and b) duplicates functionality that radosgw >>>> already provides. >>>> >>>> For OPA users that just want the ability to write simple scripts to >>>> customize authorization for their environment, I think our current >>>> level >>>> of OPA integration is sufficient. >>>> >>>> > >>>> > On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley < cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com>> wrote: >>>> > >>>> > Is there an advantage to doing this in OPA over radosgw? Have >>>> you >>>> > looked >>>> > at using our PutUserPolicy[1] APIs instead? We support both >>>> user and >>>> > bucket policy, and (as far as I know) handle the intersection of >>>> > the two >>>> > as you'd expect. >>>> > >>>> > >>>> https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html >>>> > >>>> > On 2/5/20 9:55 AM, Seena Fallah wrote: >>>> > > I'm trying to implement AWS IAM with OPA so I can have >>>> external >>>> > > authorization for my S3 service and also have an active bucket >>>> > ACL and >>>> > > bucket policy. >>>> > > >>>> > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley < >>>> cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >>>> wrote: >>>> > > >>>> > > I'm confused by your references to AWS IAM. Are you >>>> talking >>>> > about >>>> > > radosgw user policy? Or are you trying to implement IAM >>>> policy >>>> > > inside of >>>> > > OPA? >>>> > > >>>> > > On 2/5/20 8:54 AM, Seena Fallah wrote: >>>> > > > Hi all. >>>> > > > >>>> > > > Any updates here? :) >>>> > > > >>>> > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah >>>> > > <seenafallah@gmail.com <mailto:seenafallah@gmail.com

...

...

>>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>>>> >>>> > > wrote: >>>> > > > >>>> > > > I should also mention that if we get access to >>>> bucket >>>> > via bucket >>>> > > > policy and reject it via AWS IAM, the request will >>>> > reject so I >>>> > > > think we should make a new behavior at what we >>>> should do >>>> > > with this >>>> > > > two source of truth? >>>> > > > >>>> > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >>>> > > > <seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com> >>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com> >>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>>>> >>>> wrote: >>>> > > > >>>> > > > Yes but the main problem is when the policy >>>> isn't >>>> > set in AWS >>>> > > > IAM for example a user has >>>> only AmazonS3ReadOnlyAccess >>>> > > and we >>>> > > > give PutObject policy via bucket policy, user >>>> can >>>> > put object >>>> > > > to that bucket but in radosgw, OPA will deny >>>> this >>>> > process >>>> > > > because there is only ReadOnlyAccess to

...

...

...

>>>> > bucket for user >>>> > > > and radosgw will not check bucket policy

...

...

...

>>>> gave >>>> > access to >>>> > > > user. >>>> > > > I think we should weight bucket policy over OPA >>>> so >>>> > if bucket >>>> > > > policy accept that request it doesn't need to be >>>> > checked >>>> > > with >>>> > > > OPA BUT if there is no policy according to

...

...

...

>>>> > request it >>>> > > > should check by OPA because if the policy >>>> > according to that >>>> > > > request isn't set bucket policy will reject that >>>> > request >>>> > > so it >>>> > > > against failed! >>>> > > > >>>> > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >>>> > > > <cbodley@redhat.com <mailto: cbodley@redhat.com> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >>>> wrote: >>>> > > > >>>> > > > >>>> > > > On 1/30/20 2:18 PM, Seena Fallah wrote: >>>> > > > > Hi Casey, >>>> > > > > >>>> > > > > The main problem now is when OPA >>>> integration is >>>> > > enabled >>>> > > > bucket >>>> > > > > policies aren’t work! >>>> > > > > I have checked AWS S3 that what is doing >>>> > when both >>>> > > > bucket policy and >>>> > > > > IAM policy (the policy is set with AWS >>>> panel >>>> > in IAM >>>> > > > section) is set it >>>> > > > > will OR between two of them so now in >>>> > radosgw S3 we >>>> > > > don’t have this >>>> > > > > feature and bucket policies won’t work >>>> when OPA >>>> > > > integration is enabled. >>>> > > > > >>>> > > > > So I think it’s better to active this >>>> > feature and >>>> > > > enabled bucket >>>> > > > > policy when OpA integration is enabled. >>>> > > > > >>>> > > > > There is two solutions here in this >>>> > discussion for >>>> > > > enabling bucket >>>> > > > > policy on OPA integration: >>>> > > > > 1. Send bucket policy on set/del actions >>>> to >>>> > OPA server >>>> > > > to be apply on >>>> > > > > OPA policy rules so in this case the >>>> source >>>> > of truth >>>> > > > will be OPA (the >>>> > > > > state that we have now in OPA integration) >>>> > and so >>>> > > these >>>> > > > policies that >>>> > > > > sent from bucket policy will be applied. >>>> > > > > 2. OR between bucket policy and OPA >>>> policy like >>>> > > AWS S3. >>>> > > > So there is >>>> > > > > two source of truth in this case and if >>>> any of >>>> > > them deny >>>> > > > the request, >>>> > > > > the request will be denied. >>>> > > > >>>> > > > What you described here in 2. is exactly >>>> how it >>>> > > currently >>>> > > > works. >>>> > > > >>>> > > > > >>>> > > > > Do have any other solutions we have here >>>> and >>>> > which of >>>> > > > these solutions >>>> > > > > do you prefer to have? >>>> > > > > >>>> > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey >>>> Bodley >>>> > > > <cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com>> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >>>> > > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com >>>> >>>>> >>>> > > > wrote: >>>> > > > > >>>> > > > > Hi Seena, >>>> > > > > >>>> > > > > I think it would probably help if you >>>> could >>>> > > describe >>>> > > > your use case >>>> > > > > here, >>>> > > > > and what role you want OPA to

...

...

...

>>>> the >>>> > > > interpretation of these >>>> > > > > bucket >>>> > > > > policies. In other words, what is it >>>> > that your OPA >>>> > > > policy is doing >>>> > > > > with >>>> > > > > these bucket policy documents

...

...

...

>>>> shouldn't >>>> > > be done >>>> > > > within radosgw? >>>> > > > > >>>> > > > > On 1/30/20 1:09 AM, Seena Fallah >>>> wrote: >>>> > > > > > So Matt what should we have done >>>> with >>>> > bucket >>>> > > > policy if we enable >>>> > > > > OPA >>>> > > > > > integration? >>>> > > > > > >>>> > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt >>>> > Benjamin >>>> > > > > <mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>>> >>>> > > > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com>>>>>> wrote: >>>> > > > > > >>>> > > > > > I think we should not be >>>> > introducing new >>>> > > > special case >>>> > > > > behavior, nor >>>> > > > > > sending policy documents to OPA, >>>> > which from >>>> > > > what we have >>>> > > > > heard and >>>> > > > > > read, intends to make no use of >>>> them. >>>> > > > > > >>>> > > > > > Matt >>>> > > > > > >>>> > > > > > On Wed, Jan 29, 2020 at 4:45 PM >>>> > Seena Fallah >>>> > > > > > <seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>>> >>>> > > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>>> > > > > > > >>>> > > > > > > I think it’s better to OR >>>> > between two >>>> > > of the >>>> > > > bucket >>>> > > > > policies and >>>> > > > > > OPA policies. So if one of

...

...

...

>>>> reject >>>> > > certain >>>> > > > access the >>>> > > > > request >>>> > > > > > will reject as AWS do on its IAM >>>> > and bucket >>>> > > > policy. >>>> > > > > > > Are you okay with this idea? >>>> > > > > > > >>>> > > > > > > On Wed, Jan 29, 2020 at 11:13 >>>> PM >>>> > Casey >>>> > > Bodley >>>> > > > > > <cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>> > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>>> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>> > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com>>>> >>>> > > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>> > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>>> >>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>> > > > <mailto:cbodley@redhat.com >>>> > <mailto:cbodley@redhat.com> >>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com >>>> >>>>>> >>>> > wrote: >>>> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> On 1/28/20 2:45 PM, Matthias >>>> Muench >>>> > > wrote: >>>> > > > > > >> > Hi, >>>> > > > > > >> > I think making Ceph special >>>> > to what the >>>> > > > rest of the clients >>>> > > > > > in the >>>> > > > > > >> > world would expect would >>>> be a bit >>>> > > off the >>>> > > > idea of providing >>>> > > > > > S3 like >>>> > > > > > >> > service. >>>> > > > > > >> > To my understanding, >>>> setting >>>> > OPA to be >>>> > > > the source of >>>> > > > > truth would >>>> > > > > > >> > introduce latency (based on >>>> > Casey’s >>>> > > > comments) and will not >>>> > > > > > allow to >>>> > > > > > >> > set policies (based on >>>> Seena). >>>> > > > > > >> > The first one brings us >>>> > towards harder >>>> > > > latency and >>>> > > > > especially >>>> > > > > > >> > depending on extern systems >>>> > resource >>>> > > > capability (assume >>>> > > > > central >>>> > > > > > >> > resource as the idea is and >>>> > > therefor not >>>> > > > necessarily really >>>> > > > > > “in reach” >>>> > > > > > >> > within an acceptable >>>> latency, >>>> > > routing in >>>> > > > addition, >>>> > > > > etc.). The >>>> > > > > > second >>>> > > > > > >> > one says simply that

...

...

...

>>>> would >>>> > > break any >>>> > > > existing >>>> > > > > > compatibility with >>>> > > > > > >> > clients and use cases. To >>>> me it >>>> > > looks not >>>> > > > that good to >>>> > > > > loose >>>> > > > > > on both ends. >>>> > > > > > >> >>>> > > > > > >> Agreed. Even if one has to >>>> > opt-in to this >>>> > > > broken s3 >>>> > > > > > compatiblity, I'm >>>> > > > > > >> skeptical that users will >>>> find this >>>> > > to be a >>>> > > > compelling target >>>> > > > > > for their >>>> > > > > > >> applications. >>>> > > > > > >> >>>> > > > > > >> The existing prototype of OPA >>>> > integration >>>> > > > sends this >>>> > > > > authorization >>>> > > > > > >> request to OPA -in addition >>>> to- >>>> > radosgw's >>>> > > > own authorization >>>> > > > > > logic, where >>>> > > > > > >> we consult any of our >>>> user/bucket >>>> > > policies >>>> > > > or ACLs that >>>> > > > > apply. >>>> > > > > > In this >>>> > > > > > >> model, OPA is not the only >>>> > source of >>>> > > truth. >>>> > > > It just has the >>>> > > > > > opportunity >>>> > > > > > >> to deny access that we would >>>> > otherwise >>>> > > > grant, so it doesn't >>>> > > > > > require that >>>> > > > > > >> we break compatibility with >>>> any S3 >>>> > > features >>>> > > > that conflict >>>> > > > > with >>>> > > > > > OPA's >>>> > > > > > >> view of policy. >>>> > > > > > >> >>>> > > > > > >> Were we to change this so >>>> that OPA >>>> > > was the >>>> > > > only source of >>>> > > > > > truth, then >>>> > > > > > >> we'd be left with two bad >>>> > options: either >>>> > > > reject all requests >>>> > > > > > to modify >>>> > > > > > >> policy and break existing >>>> > > applications, or >>>> > > > send all >>>> > > > > policy/ACL >>>> > > > > > >> information to OPA and >>>> require >>>> > every OPA >>>> > > > policy script to >>>> > > > > implement >>>> > > > > > >> s3-compatible enforcement of >>>> > them. I also >>>> > > > don't see any >>>> > > > > benefit >>>> > > > > > to this >>>> > > > > > >> model - why, if an client >>>> wants >>>> > to use s3 >>>> > > > policy to >>>> > > > > restrict a >>>> > > > > > certain >>>> > > > > > >> access, would OPA want to >>>> override >>>> > > that and >>>> > > > grant access >>>> > > > > instead? >>>> > > > > > >> >>>> > > > > > >> > I could live more with the >>>> > latency >>>> > > issue >>>> > > > but wouldn’t >>>> > > > > like it. >>>> > > > > > >> > For the second, I can >>>> understand >>>> > > the idea >>>> > > > of having >>>> > > > > > simplification for >>>> > > > > > >> > auditing the access but I’m >>>> > not that >>>> > > > convinced to take the >>>> > > > > > burden of >>>> > > > > > >> > being “the special” one >>>> that >>>> > nobody >>>> > > wants >>>> > > > to work with. >>>> > > > > So, I >>>> > > > > > would >>>> > > > > > >> > love to see the full >>>> fledged >>>> > support of >>>> > > > setting the >>>> > > > > policy by >>>> > > > > > clients, >>>> > > > > > >> > no matter what the result >>>> > would be in >>>> > > > terms of >>>> > > > > implementing it to >>>> > > > > > >> > interact with OPA. Instead, >>>> > having an >>>> > > > additional >>>> > > > > requirement to >>>> > > > > > >> > implement additional >>>> handling >>>> > to set >>>> > > > policies different >>>> > > > > from >>>> > > > > > what S3 >>>> > > > > > >> > actually provides would >>>> > require special >>>> > > > clients first and >>>> > > > > > secondly an >>>> > > > > > >> > additional path to OPA with >>>> > all the >>>> > > > additional burden >>>> > > > > to tweak >>>> > > > > > >> > security to allow

we policy this that that that that play in that them this this path

...

...

...

>>>> > to OPA. I >>>> > > > feel that the first >>>> > > > > > wouldn’t >>>> > > > > > >> > happen (special clients) >>>> and >>>> > the second >>>> > > > in practice not >>>> > > > > > either because >>>> > > > > > >> > of security constraints by >>>> > the OPA >>>> > > admin >>>> > > > folks. >>>> > > > > > >> > >>>> > > > > > >> > G, >>>> > > > > > >> > -matt >>>> > > > > > >> > >>>> > > > > > >> > —————————————————— >>>> > > > > > >> > Matthias Muench >>>> > > > > > >> > Senior Specialist Solution >>>> > Architect >>>> > > > > > >> > EMEA Storage Specialist >>>> > > > > > >> > matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>> >>>> > > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>>> >>>> > > > > <mailto: matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>> >>>> > > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>>>> >>>> > > > > > <mailto: >>>> matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>> >>>> > > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>>> >>>> > > > > <mailto: matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>> >>>> > > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com> >>>> > > <mailto:matthias.muench@redhat.com >>>> > <mailto:matthias.muench@redhat.com>>>>> >>>> > > > <mailto:mmuench@redhat.com >>>> > <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>> >>>> > > > > <mailto:mmuench@redhat.com >>>> > <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>>> >>>> > > > > > <mailto:mmuench@redhat.com >>>> > <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>> > > > <mailto:mmuench@redhat.com >>>> > <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>> >>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>> > > > <mailto:mmuench@redhat.com >>>> > <mailto:mmuench@redhat.com> >>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com >>>> >>>>>> >>>> > > > > > >> > Phone: +49-160-92654111 >>>> > > > <tel:+49-160-92654111> >>>> > > > > > >> > >>>> > > > > > >> > Red Hat GmbH >>>> > > > > > >> > Werner-von-Siemens-Ring 14 >>>> > > > <x-apple-data-detectors://2/1> >>>> > > > > > >> > 85630 Grasbrunn >>>> > > > <x-apple-data-detectors://2/1> >>>> > > > > > >> > Germany >>>> > <x-apple-data-detectors://2/1> >>>> > > > > > >> > >>>> > > > > > >>>> > > > > >>>> > > > >>>> > > >>>> > >>>>

---

...

...

...

>>>> > > > > > >> > Red Hat GmbH, >>>> > http://www.de.redhat.com >>>> > > > > <http://de.redhat.com/> · >>>> > > > > > >> > Registered seat: Grasbrunn, >>>> > Commercial >>>> > > > register: >>>> > > > > Amtsgericht >>>> > > > > > Muenchen >>>> > > > > > >> > HRB 153243 · Managing >>>> Directors: >>>> > > Charles >>>> > > > Cachera, Michael >>>> > > > > > O'Neill, Tom >>>> > > > > > >> > Savage, Eric Shander >>>> > > > > > >> > >>>> > > > > > >> >> On Jan 28, 2020, at >>>> 15:02, Seena >>>> > > Fallah >>>> > > > > > <seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>>> >>>> > > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>>> > > > > > >> >> >>>> > > > > > >> >>  >>>> > > > > > >> >> Amazon AWS S3 has two >>>> type of >>>> > > policies. >>>> > > > One from bucket >>>> > > > > > policy and >>>> > > > > > >> >> one form IAM. I think it >>>> > could be >>>> > > better >>>> > > > to have two >>>> > > > > > policies models >>>> > > > > > >> >> in Ceph one from bucket >>>> > policy and one >>>> > > > form OPA if its >>>> > > > > enable. >>>> > > > > > >> >> So if you are okay we can >>>> change >>>> > > the PR >>>> > > > to make bucket >>>> > > > > > policy enabled >>>> > > > > > >> >> when OPA is enabled, too. >>>> > Because now >>>> > > > bucket policies not >>>> > > > > > working >>>> > > > > > >> >> when OPA integration is >>>> enabled. >>>> > > > > > >> >> >>>> > > > > > >> >> On Tue, Jan 28, 2020 at >>>> 2:57 AM >>>> > > Seena Fallah >>>> > > > > > <seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>>> >>>> > > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>>>> >>>> > > > > > >> >> >>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>>> >>>> > > > > > <mailto: seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>>> >>>> > > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com <mailto: >>>> seenafallah@gmail.com>> >>>> > > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com> >>>> > > <mailto:seenafallah@gmail.com >>>> > <mailto:seenafallah@gmail.com>>>>>>> wrote: >>>> > > > > > >> >> >>>> > > > > > >> >> Matt When OPA >>>> integration is >>>> > > enabled >>>> > > > S3 policies >>>> > > > > doesn’t >>>> > > > > > work! If >>>> > > > > > >> >> you want them to be >>>> > worked we >>>> > > should >>>> > > > bypass S3 >>>> > > > > policies >>>> > > > > > to OPA >>>> > > > > > >> >> for being applied and >>>> > worked. >>>> > > > > > >> >> Here we have conflict >>>> in OPA >>>> > > > integration with S3 >>>> > > > > policies! >>>> > > > > > >> >> >>>> > > > > > >> >> On Tue, Jan 28, 2020 >>>> at 2:52 >>>> > > AM Matt >>>> > > > Benjamin >>>> > > > > > >> >> < mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>>> >>>> > > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>>>> >>>> > > > > > <mailto: mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>>> >>>> > > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>> >>> >>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>> > > > <mailto:mbenjami@redhat.com >>>> > <mailto:mbenjami@redhat.com> >>>> > >>> >>>

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

Are you okay with this balancing between OPA and bucket policy? On Fri, Feb 21, 2020 at 2:36 PM Seena Fallah <seenafallah@gmail.com> wrote:

Sorry I get your point now. Yes that policies cant handle with OPA. Maybe it could better to ask for OPA when Policy::eval returns Effect::Pass so if we don't have any bucket policy according to that request we will ask for OPA. In this scenario bucket policy get weight like AWS S3 I think.

What is your opinion about this?

On Fri, Feb 21, 2020 at 2:28 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

If we send bucket policy, acl, ... to OPA, in OPA server we can parse them and make decision based on our policies. So we don't break bucket policy, acl, ... support in OPA integration and OPA can gain access to requests based on its policies and bucket policy, acl, ....

On Fri, Feb 21, 2020 at 2:24 PM Seena Fallah <seenafallah@gmail.com> wrote:

...

In a code base ( https://github.com/ceph/ceph/pull/32294/files#diff-bb1cc6889525611b45d6af6d5...) in rgw_process_authenticated function we have an IF that check for OPA authorization result after that if it was OK (200) it will call verify_permission() that check with radosgw policies like bucket policy, bucket acl, user acl, .... Now if I create a policy in OPA that user A can access user B's bucket so OPA return OK (200) to radosgw and radosgw will call verify_permission() but in radosgw policies we don't have a policy that user A has access to user B so the request will be reject. So OPA can just reject requests and if OPA accept a request radosgw should also has that policy for being accept to execute.

I think it's better to make OPA single source of truth and send bucket policy, acl, ... to OPA in OPA request to be authorized.

On Fri, Feb 21, 2020 at 2:09 PM Abhishek Lekshmanan <abhishek@suse.com> wrote:

...

Seena Fallah <seenafallah@gmail.com> writes:

...

I have make this PR to make OPA single source of truth so OPA can get access to not owned bucket for user. And also in OPA request we send bucket policy, acl, ... to OPA so we can support them when OPA integration is enabled. We will authorized user based on bucket policy, acl, ... and OPA policies in OPA server. Can you please take a look at here? https://github.com/ceph/ceph/pull/32294

How does OPA decide on S3 conditionals wrt Policy here, we already support a few bucket attribute or Object based conditionals

https://docs.ceph.com/docs/master/radosgw/bucketpolicy/#bucket-related-opera...

which can only be evaluated after reading the object in question for eg. These allow for eg. Bucket A would have access to User B to download object iff the object tag has an attribute openaccess = true. Additionally for buckets that are public https://github.com/ceph/ceph/pull/30033 would prevent access when IgnorePublicAcls are true.

...

On Tue, Feb 18, 2020 at 9:52 AM Seena Fallah <seenafallah@gmail.com>

wrote:

...

...

I have seen another bad scenario that we have two source of truth.

...

...

get access to user for a bucket that he/she doesn't own it in OPA we can perform this action because op->verify_permission() will return -EACCES and so in rgw_process_authenticated function rgw_opa_authorize will not check!

I think it's better to have one source of truth when we enabled OPA integration so we can send bucket policy, acl, ... to OPA on each request to be authorized.

Do you have any other suggestion?

On Tue, Feb 18, 2020 at 1:01 AM Seena Fallah <seenafallah@gmail.com> wrote:

> I have changed the PR for sending bucket policy, bucket acl, iam

...

...

> and user acl as a field to OPA request so OPA can decision based on

...

...

> parameters and we can have a external authorization for our organization > like AWS IAM. So we can have an S3 service that authorize based on bucket > policy and organizations IAM. > https://github.com/ceph/ceph/pull/32294 > Could you please review this? > > On Mon, Feb 17, 2020 at 2:39 PM Seena Fallah <seenafallah@gmail.com

...

> wrote: > >> Also we can add bucket policy result field to OPA request so in OPA >> policies we can act based on bucket policy results. >> >> Are you agree with it? >> >> On Thu, Feb 13, 2020 at 12:17 PM Seena Fallah < seenafallah@gmail.com> >> wrote: >> >>> In bucket policy we have an Effect::Pass in validation result so if we >>> just put OPA authorization in case of Effect::Pass I think it will be close >>> to what AWS do. >>> >>> On Fri, Feb 7, 2020 at 1:37 PM Seena Fallah < seenafallah@gmail.com> >>> wrote: >>> >>>> In organizations that has many services and want to have a centralized >>>> authorization server this will be a good solution to have. >>>> >>>> I mean that when we just authorize user ReadOnly in OPA but give write >>>> access via bucket policy, the user can’t write because OPA is rejecting. >>>> >>>> I think we can just weight bucket policy upper that OPA so bucket >>>> policies that apply policies specific than OPA policies can accept and >>>> reject at first then OPA would authorize that request. I mean bucket policy >>>> specify policy more specific (On bucket or on object) than OPA (OPA can set >>>> policy globally too like giving ReadOnly to all buckets) so it's better to >>>> first check bucket policy then check for OPA. this could be easy solve this >>>> problem. >>>> >>>> On Thu, Feb 6, 2020 at 10:11 PM Casey Bodley <cbodley@redhat.com

...

>>>> wrote: >>>> >>>>> >>>>> On 2/6/20 11:58 AM, Seena Fallah wrote: >>>>> > The main goal of using OPA like as AWS IAM is having an external >>>>> > authorization so we can have out own management on policies from >>>>> > external source of truth (OPA) too. >>>>> > >>>>> > I think it’s better to handle bucket policy with OPA as well as AWS >>>>> > does so we can have a better S3 service :) >>>>> >>>>> Can you expand on why that's better than the model I suggested >>>>> earlier >>>>> in the thread, where a centralized policy service uses radosgw's >>>>> existing IAM APIs to manage policy instead of requiring radosgw to >>>>> call >>>>> out to an external service for every request? >>>>> >>>>> I'd also like to clarify what you mean when you say "handle bucket >>>>> policy with OPA" - my understanding is that it's not something

...

...

>>>>> OPA >>>>> itself does, but something very specific to your own product's OPA >>>>> policy script. Am I getting that right? If so, it sounds like you're >>>>> trying to re-engineer our OPA integration in a way that a) is not >>>>> useful >>>>> to OPA users in general, and b) duplicates functionality that radosgw >>>>> already provides. >>>>> >>>>> For OPA users that just want the ability to write simple

...

...

>>>>> customize authorization for their environment, I think our current >>>>> level >>>>> of OPA integration is sufficient. >>>>> >>>>> > >>>>> > On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley < cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com>> wrote: >>>>> > >>>>> > Is there an advantage to doing this in OPA over radosgw? Have >>>>> you >>>>> > looked >>>>> > at using our PutUserPolicy[1] APIs instead? We support both >>>>> user and >>>>> > bucket policy, and (as far as I know) handle the intersection of >>>>> > the two >>>>> > as you'd expect. >>>>> > >>>>> > >>>>> https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html >>>>> > >>>>> > On 2/5/20 9:55 AM, Seena Fallah wrote: >>>>> > > I'm trying to implement AWS IAM with OPA so I can have >>>>> external >>>>> > > authorization for my S3 service and also have an active bucket >>>>> > ACL and >>>>> > > bucket policy. >>>>> > > >>>>> > > On Wed, Feb 5, 2020 at 6:11 PM Casey Bodley < >>>>> cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com > >>>>> wrote: >>>>> > > >>>>> > > I'm confused by your references to AWS IAM. Are you >>>>> talking >>>>> > about >>>>> > > radosgw user policy? Or are you trying to implement IAM >>>>> policy >>>>> > > inside of >>>>> > > OPA? >>>>> > > >>>>> > > On 2/5/20 8:54 AM, Seena Fallah wrote: >>>>> > > > Hi all. >>>>> > > > >>>>> > > > Any updates here? :) >>>>> > > > >>>>> > > > On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah >>>>> > > <seenafallah@gmail.com <mailto: seenafallah@gmail.com> >>>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>>>> >>>>> > > wrote: >>>>> > > > >>>>> > > > I should also mention that if we get access to >>>>> bucket >>>>> > via bucket >>>>> > > > policy and reject it via AWS IAM, the request will >>>>> > reject so I >>>>> > > > think we should make a new behavior at what we >>>>> should do >>>>> > > with this >>>>> > > > two source of truth? >>>>> > > > >>>>> > > > On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah >>>>> > > > <seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com> >>>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com> >>>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com>>>> >>>>> wrote: >>>>> > > > >>>>> > > > Yes but the main problem is when the

...

...

>>>>> isn't >>>>> > set in AWS >>>>> > > > IAM for example a user has >>>>> only AmazonS3ReadOnlyAccess >>>>> > > and we >>>>> > > > give PutObject policy via bucket policy, user >>>>> can >>>>> > put object >>>>> > > > to that bucket but in radosgw, OPA will deny >>>>> this >>>>> > process >>>>> > > > because there is only ReadOnlyAccess to

...

...

>>>>> > bucket for user >>>>> > > > and radosgw will not check bucket policy

...

...

>>>>> gave >>>>> > access to >>>>> > > > user. >>>>> > > > I think we should weight bucket policy over OPA >>>>> so >>>>> > if bucket >>>>> > > > policy accept that request it doesn't need to be >>>>> > checked >>>>> > > with >>>>> > > > OPA BUT if there is no policy according to that >>>>> > request it >>>>> > > > should check by OPA because if the policy >>>>> > according to that >>>>> > > > request isn't set bucket policy will reject that >>>>> > request >>>>> > > so it >>>>> > > > against failed! >>>>> > > > >>>>> > > > On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley >>>>> > > > <cbodley@redhat.com <mailto: cbodley@redhat.com> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>> >>>>> wrote: >>>>> > > > >>>>> > > > >>>>> > > > On 1/30/20 2:18 PM, Seena Fallah wrote: >>>>> > > > > Hi Casey, >>>>> > > > > >>>>> > > > > The main problem now is when OPA >>>>> integration is >>>>> > > enabled >>>>> > > > bucket >>>>> > > > > policies aren’t work! >>>>> > > > > I have checked AWS S3 that what is doing >>>>> > when both >>>>> > > > bucket policy and >>>>> > > > > IAM policy (the policy is set with AWS >>>>> panel >>>>> > in IAM >>>>> > > > section) is set it >>>>> > > > > will OR between two of them so now in >>>>> > radosgw S3 we >>>>> > > > don’t have this >>>>> > > > > feature and bucket policies won’t work >>>>> when OPA >>>>> > > > integration is enabled. >>>>> > > > > >>>>> > > > > So I think it’s better to active

...

...

>>>>> > feature and >>>>> > > > enabled bucket >>>>> > > > > policy when OpA integration is enabled. >>>>> > > > > >>>>> > > > > There is two solutions here in this >>>>> > discussion for >>>>> > > > enabling bucket >>>>> > > > > policy on OPA integration: >>>>> > > > > 1. Send bucket policy on set/del actions >>>>> to >>>>> > OPA server >>>>> > > > to be apply on >>>>> > > > > OPA policy rules so in this case the >>>>> source >>>>> > of truth >>>>> > > > will be OPA (the >>>>> > > > > state that we have now in OPA integration) >>>>> > and so >>>>> > > these >>>>> > > > policies that >>>>> > > > > sent from bucket policy will be applied. >>>>> > > > > 2. OR between bucket policy and OPA >>>>> policy like >>>>> > > AWS S3. >>>>> > > > So there is >>>>> > > > > two source of truth in this case and if >>>>> any of >>>>> > > them deny >>>>> > > > the request, >>>>> > > > > the request will be denied. >>>>> > > > >>>>> > > > What you described here in 2. is exactly >>>>> how it >>>>> > > currently >>>>> > > > works. >>>>> > > > >>>>> > > > > >>>>> > > > > Do have any other solutions we have here >>>>> and >>>>> > which of >>>>> > > > these solutions >>>>> > > > > do you prefer to have? >>>>> > > > > >>>>> > > > > On Thu, Jan 30, 2020 at 10:21 PM Casey >>>>> Bodley >>>>> > > > <cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com>> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>> >>>>> > > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com >>>>> >>>>> >>>>> > > > wrote: >>>>> > > > > >>>>> > > > > Hi Seena, >>>>> > > > > >>>>> > > > > I think it would probably help if you >>>>> could >>>>> > > describe >>>>> > > > your use case >>>>> > > > > here, >>>>> > > > > and what role you want OPA to

...

...

>>>>> the >>>>> > > > interpretation of these >>>>> > > > > bucket >>>>> > > > > policies. In other words, what is it >>>>> > that your OPA >>>>> > > > policy is doing >>>>> > > > > with >>>>> > > > > these bucket policy documents

...

...

>>>>> shouldn't >>>>> > > be done >>>>> > > > within radosgw? >>>>> > > > > >>>>> > > > > On 1/30/20 1:09 AM, Seena Fallah >>>>> wrote: >>>>> > > > > > So Matt what should we have done >>>>> with >>>>> > bucket >>>>> > > > policy if we enable >>>>> > > > > OPA >>>>> > > > > > integration? >>>>> > > > > > >>>>> > > > > > On Thu, Jan 30, 2020 at 1:45 AM Matt >>>>> > Benjamin >>>>> > > > > <mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>>> >>>>> > > > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com>>>>>> wrote: >>>>> > > > > > >>>>> > > > > > I think we should not be >>>>> > introducing new >>>>> > > > special case >>>>> > > > > behavior, nor >>>>> > > > > > sending policy documents to OPA, >>>>> > which from >>>>> > > > what we have >>>>> > > > > heard and >>>>> > > > > > read, intends to make no use of >>>>> them. >>>>> > > > > > >>>>> > > > > > Matt >>>>> > > > > > >>>>> > > > > > On Wed, Jan 29, 2020 at 4:45 PM >>>>> > Seena Fallah >>>>> > > > > > <seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>>> >>>>> > > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>>>> > > > > > > >>>>> > > > > > > I think it’s better to OR >>>>> > between two >>>>> > > of the >>>>> > > > bucket >>>>> > > > > policies and >>>>> > > > > > OPA policies. So if one of them >>>>> reject >>>>> > > certain >>>>> > > > access the >>>>> > > > > request >>>>> > > > > > will reject as AWS do on its IAM >>>>> > and bucket >>>>> > > > policy. >>>>> > > > > > > Are you okay with this idea? >>>>> > > > > > > >>>>> > > > > > > On Wed, Jan 29, 2020 at 11:13 >>>>> PM >>>>> > Casey >>>>> > > Bodley >>>>> > > > > > <cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>>> > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>>> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>>> > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com>>>> >>>>> > > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>>> > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>>> >>>>> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com>> >>>>> > > > <mailto:cbodley@redhat.com >>>>> > <mailto:cbodley@redhat.com> >>>>> > > <mailto:cbodley@redhat.com <mailto: cbodley@redhat.com >>>>> >>>>>> >>>>> > wrote: >>>>> > > > > > >> >>>>> > > > > > >> >>>>> > > > > > >> On 1/28/20 2:45 PM, Matthias >>>>> Muench >>>>> > > wrote: >>>>> > > > > > >> > Hi, >>>>> > > > > > >> > I think making Ceph special >>>>> > to what the >>>>> > > > rest of the clients >>>>> > > > > > in the >>>>> > > > > > >> > world would expect would >>>>> be a bit >>>>> > > off the >>>>> > > > idea of providing >>>>> > > > > > S3 like >>>>> > > > > > >> > service. >>>>> > > > > > >> > To my understanding, >>>>> setting >>>>> > OPA to be >>>>> > > > the source of >>>>> > > > > truth would >>>>> > > > > > >> > introduce latency (based on >>>>> > Casey’s >>>>> > > > comments) and will not >>>>> > > > > > allow to >>>>> > > > > > >> > set policies (based on >>>>> Seena). >>>>> > > > > > >> > The first one brings us >>>>> > towards harder >>>>> > > > latency and >>>>> > > > > especially >>>>> > > > > > >> > depending on extern systems >>>>> > resource >>>>> > > > capability (assume >>>>> > > > > central >>>>> > > > > > >> > resource as the idea is and >>>>> > > therefor not >>>>> > > > necessarily really >>>>> > > > > > “in reach” >>>>> > > > > > >> > within an acceptable >>>>> latency, >>>>> > > routing in >>>>> > > > addition, >>>>> > > > > etc.). The >>>>> > > > > > second >>>>> > > > > > >> > one says simply that

...

...

>>>>> would >>>>> > > break any >>>>> > > > existing >>>>> > > > > > compatibility with >>>>> > > > > > >> > clients and use cases. To >>>>> me it >>>>> > > looks not >>>>> > > > that good to >>>>> > > > > loose >>>>> > > > > > on both ends. >>>>> > > > > > >> >>>>> > > > > > >> Agreed. Even if one has to >>>>> > opt-in to this >>>>> > > > broken s3 >>>>> > > > > > compatiblity, I'm >>>>> > > > > > >> skeptical that users will >>>>> find this >>>>> > > to be a >>>>> > > > compelling target >>>>> > > > > > for their >>>>> > > > > > >> applications. >>>>> > > > > > >> >>>>> > > > > > >> The existing prototype of OPA >>>>> > integration >>>>> > > > sends this >>>>> > > > > authorization >>>>> > > > > > >> request to OPA -in addition >>>>> to- >>>>> > radosgw's >>>>> > > > own authorization >>>>> > > > > > logic, where >>>>> > > > > > >> we consult any of our >>>>> user/bucket >>>>> > > policies >>>>> > > > or ACLs that >>>>> > > > > apply. >>>>> > > > > > In this >>>>> > > > > > >> model, OPA is not the only >>>>> > source of >>>>> > > truth. >>>>> > > > It just has the >>>>> > > > > > opportunity >>>>> > > > > > >> to deny access that we would >>>>> > otherwise >>>>> > > > grant, so it doesn't >>>>> > > > > > require that >>>>> > > > > > >> we break compatibility with >>>>> any S3 >>>>> > > features >>>>> > > > that conflict >>>>> > > > > with >>>>> > > > > > OPA's >>>>> > > > > > >> view of policy. >>>>> > > > > > >> >>>>> > > > > > >> Were we to change this so >>>>> that OPA >>>>> > > was the >>>>> > > > only source of >>>>> > > > > > truth, then >>>>> > > > > > >> we'd be left with two bad >>>>> > options: either >>>>> > > > reject all requests >>>>> > > > > > to modify >>>>> > > > > > >> policy and break existing >>>>> > > applications, or >>>>> > > > send all >>>>> > > > > policy/ACL >>>>> > > > > > >> information to OPA and >>>>> require >>>>> > every OPA >>>>> > > > policy script to >>>>> > > > > implement >>>>> > > > > > >> s3-compatible enforcement of >>>>> > them. I also >>>>> > > > don't see any >>>>> > > > > benefit >>>>> > > > > > to this >>>>> > > > > > >> model - why, if an client >>>>> wants >>>>> > to use s3 >>>>> > > > policy to >>>>> > > > > restrict a >>>>> > > > > > certain >>>>> > > > > > >> access, would OPA want to >>>>> override >>>>> > > that and >>>>> > > > grant access >>>>> > > > > instead? >>>>> > > > > > >> >>>>> > > > > > >> > I could live more with the >>>>> > latency >>>>> > > issue >>>>> > > > but wouldn’t >>>>> > > > > like it. >>>>> > > > > > >> > For the second, I can >>>>> understand >>>>> > > the idea >>>>> > > > of having >>>>> > > > > > simplification for >>>>> > > > > > >> > auditing the access but I’m >>>>> > not that >>>>> > > > convinced to take the >>>>> > > > > > burden of >>>>> > > > > > >> > being “the special” one >>>>> that >>>>> > nobody >>>>> > > wants >>>>> > > > to work with. >>>>> > > > > So, I >>>>> > > > > > would >>>>> > > > > > >> > love to see the full >>>>> fledged >>>>> > support of >>>>> > > > setting the >>>>> > > > > policy by >>>>> > > > > > clients, >>>>> > > > > > >> > no matter what the result >>>>> > would be in >>>>> > > > terms of >>>>> > > > > implementing it to >>>>> > > > > > >> > interact with OPA. Instead, >>>>> > having an >>>>> > > > additional >>>>> > > > > requirement to >>>>> > > > > > >> > implement additional >>>>> handling >>>>> > to set >>>>> > > > policies different >>>>> > > > > from >>>>> > > > > > what S3 >>>>> > > > > > >> > actually provides would >>>>> > require special >>>>> > > > clients first and >>>>> > > > > > secondly an >>>>> > > > > > >> > additional path to OPA with >>>>> > all the >>>>> > > > additional burden >>>>> > > > > to tweak >>>>> > > > > > >> > security to allow

If we policy this that scripts to policy that that this play in that this this path

...

...

>>>>> > to OPA. I >>>>> > > > feel that the first >>>>> > > > > > wouldn’t >>>>> > > > > > >> > happen (special clients) >>>>> and >>>>> > the second >>>>> > > > in practice not >>>>> > > > > > either because >>>>> > > > > > >> > of security constraints by >>>>> > the OPA >>>>> > > admin >>>>> > > > folks. >>>>> > > > > > >> > >>>>> > > > > > >> > G, >>>>> > > > > > >> > -matt >>>>> > > > > > >> > >>>>> > > > > > >> > —————————————————— >>>>> > > > > > >> > Matthias Muench >>>>> > > > > > >> > Senior Specialist Solution >>>>> > Architect >>>>> > > > > > >> > EMEA Storage Specialist >>>>> > > > > > >> > matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>> >>>>> > > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>>> >>>>> > > > > <mailto: matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>> >>>>> > > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>>>> >>>>> > > > > > <mailto: >>>>> matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>> >>>>> > > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>>> >>>>> > > > > <mailto: matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>> >>>>> > > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com> >>>>> > > <mailto:matthias.muench@redhat.com >>>>> > <mailto:matthias.muench@redhat.com>>>>> >>>>> > > > <mailto:mmuench@redhat.com >>>>> > <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>> >>>>> > > > > <mailto:mmuench@redhat.com >>>>> > <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>>> >>>>> > > > > > <mailto: mmuench@redhat.com >>>>> > <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>>> > > > <mailto:mmuench@redhat.com >>>>> > <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>>> >>>>> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com>> >>>>> > > > <mailto:mmuench@redhat.com >>>>> > <mailto:mmuench@redhat.com> >>>>> > > <mailto:mmuench@redhat.com <mailto: mmuench@redhat.com >>>>> >>>>>> >>>>> > > > > > >> > Phone: +49-160-92654111 >>>>> > > > <tel:+49-160-92654111> >>>>> > > > > > >> > >>>>> > > > > > >> > Red Hat GmbH >>>>> > > > > > >> > Werner-von-Siemens-Ring 14 >>>>> > > > <x-apple-data-detectors://2/1> >>>>> > > > > > >> > 85630 Grasbrunn >>>>> > > > <x-apple-data-detectors://2/1> >>>>> > > > > > >> > Germany >>>>> > <x-apple-data-detectors://2/1> >>>>> > > > > > >> > >>>>> > > > > > >>>>> > > > > >>>>> > > > >>>>> > > >>>>> > >>>>>

---

...

...

>>>>> > > > > > >> > Red Hat GmbH, >>>>> > http://www.de.redhat.com >>>>> > > > > <http://de.redhat.com/> · >>>>> > > > > > >> > Registered seat: Grasbrunn, >>>>> > Commercial >>>>> > > > register: >>>>> > > > > Amtsgericht >>>>> > > > > > Muenchen >>>>> > > > > > >> > HRB 153243 · Managing >>>>> Directors: >>>>> > > Charles >>>>> > > > Cachera, Michael >>>>> > > > > > O'Neill, Tom >>>>> > > > > > >> > Savage, Eric Shander >>>>> > > > > > >> > >>>>> > > > > > >> >> On Jan 28, 2020, at >>>>> 15:02, Seena >>>>> > > Fallah >>>>> > > > > > <seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>>> >>>>> > > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>>>>>> wrote: >>>>> > > > > > >> >> >>>>> > > > > > >> >>  >>>>> > > > > > >> >> Amazon AWS S3 has two >>>>> type of >>>>> > > policies. >>>>> > > > One from bucket >>>>> > > > > > policy and >>>>> > > > > > >> >> one form IAM. I think it >>>>> > could be >>>>> > > better >>>>> > > > to have two >>>>> > > > > > policies models >>>>> > > > > > >> >> in Ceph one from bucket >>>>> > policy and one >>>>> > > > form OPA if its >>>>> > > > > enable. >>>>> > > > > > >> >> So if you are okay we can >>>>> change >>>>> > > the PR >>>>> > > > to make bucket >>>>> > > > > > policy enabled >>>>> > > > > > >> >> when OPA is enabled, too. >>>>> > Because now >>>>> > > > bucket policies not >>>>> > > > > > working >>>>> > > > > > >> >> when OPA integration is >>>>> enabled. >>>>> > > > > > >> >> >>>>> > > > > > >> >> On Tue, Jan 28, 2020 at >>>>> 2:57 AM >>>>> > > Seena Fallah >>>>> > > > > > <seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>>> >>>>> > > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>> <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>>>> >>>>> > > > > > >> >> >>>>> > <mailto:seenafallah@gmail.com <mailto: seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>>> >>>>> > > > > > <mailto: seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>>> >>>>> > > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com <mailto: >>>>> seenafallah@gmail.com>> >>>>> > > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com> >>>>> > > <mailto:seenafallah@gmail.com >>>>> > <mailto:seenafallah@gmail.com>>>>>>> wrote: >>>>> > > > > > >> >> >>>>> > > > > > >> >> Matt When OPA >>>>> integration is >>>>> > > enabled >>>>> > > > S3 policies >>>>> > > > > doesn’t >>>>> > > > > > work! If >>>>> > > > > > >> >> you want them to be >>>>> > worked we >>>>> > > should >>>>> > > > bypass S3 >>>>> > > > > policies >>>>> > > > > > to OPA >>>>> > > > > > >> >> for being applied and >>>>> > worked. >>>>> > > > > > >> >> Here we have conflict >>>>> in OPA >>>>> > > > integration with S3 >>>>> > > > > policies! >>>>> > > > > > >> >> >>>>> > > > > > >> >> On Tue, Jan 28, 2020 >>>>> at 2:52 >>>>> > > AM Matt >>>>> > > > Benjamin >>>>> > > > > > >> >> < mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>>> >>>>> > > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>>>> >>>>> > > > > > <mailto: mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>>> >>>>> > > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com >>>>> >>> >>>>> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com> >>>>> > > <mailto:mbenjami@redhat.com <mailto: mbenjami@redhat.com>> >>>>> > > > <mailto:mbenjami@redhat.com >>>>> > <mailto:mbenjami@redhat.com> >>>>> > >>>> >>>>

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io