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(a)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(a)gmail.com>
wrote:
> In a code base (
>
https://github.com/ceph/ceph/pull/32294/files#diff-bb1cc6889525611b45d6af6d…)
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(a)suse.com>
> wrote:
>
>> Seena Fallah <seenafallah(a)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-oper…
>>
>> 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)gmail.com
<mailto:seenafallah@gmail.com
>> >
>> >>>>>>> > <mailto:seenafallah@gmail.com
<mailto:
>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
<mailto:
>> seenafallah(a)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(a)gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>
>> >>>>>>> > <mailto:seenafallah@gmail.com
<mailto:
>> seenafallah(a)gmail.com>>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>
>> >>>>>>> > <mailto:seenafallah@gmail.com
<mailto:
>> seenafallah(a)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(a)redhat.com <mailto:
>> cbodley(a)redhat.com>
>> >>>>>>> > <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)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(a)redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>
>> >>>>>>> > <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>>>
>> >>>>>>> > > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>
>> >>>>>>> > <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)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(a)redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>>
>> >>>>>>> > > > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)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(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>>
<mailto:
>> seenafallah(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>>
>> >>>>>>> > > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)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(a)redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>
>> >>>>>>> > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>>
>> >>>>>>> > <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>
>> >>>>>>> > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
<mailto:cbodley@redhat.com
>> >>>>>>> >
<mailto:cbodley@redhat.com>>>>
>> >>>>>>> > > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>
>> >>>>>>> > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>>
>> >>>>>>> > <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)redhat.com>>
>> >>>>>>> > > >
<mailto:cbodley@redhat.com
>> >>>>>>> > <mailto:cbodley@redhat.com>
>> >>>>>>> > > <mailto:cbodley@redhat.com
<mailto:
>> cbodley(a)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(a)redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>
>> >>>>>>> > > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>>
>> >>>>>>> > > > >
<mailto:
>> matthias.muench(a)redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>
>> >>>>>>> > > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>>>
>> >>>>>>> > > > > >
<mailto:
>> >>>>>>> matthias.muench(a)redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>
>> >>>>>>> > > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.muench@redhat.com>>>
>> >>>>>>> > > > >
<mailto:
>> matthias.muench(a)redhat.com
>> >>>>>>> > <mailto:matthias.muench@redhat.com>
>> >>>>>>> > >
<mailto:matthias.muench@redhat.com
>> >>>>>>> >
<mailto:matthias.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(a)redhat.com>>
>> >>>>>>> > <mailto:mmuench@redhat.com
<mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>>
>> >>>>>>> > > > >
<mailto:mmuench@redhat.com
>> >>>>>>> > <mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>
>> >>>>>>> > <mailto:mmuench@redhat.com
<mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>>>
>> >>>>>>> > > > > >
<mailto:mmuench@redhat.com
>> >>>>>>> > <mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mmuench@redhat.com
>> >>>>>>> > <mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>>
>> >>>>>>> > <mailto:mmuench@redhat.com
<mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mmuench@redhat.com
>> >>>>>>> > <mailto:mmuench@redhat.com>
>> >>>>>>> > > <mailto:mmuench@redhat.com
<mailto:
>> mmuench(a)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(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>>
<mailto:
>> seenafallah(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>>
>> >>>>>>> > > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)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(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>>
<mailto:
>> seenafallah(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>>
>> >>>>>>> > > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>>
<mailto:
>> seenafallah(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>>>
>> >>>>>>> > > > > >
>> >>
>> >>>>>>> > <mailto:seenafallah@gmail.com
<mailto:
>> seenafallah(a)gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>>
>> >>>>>>> > > > > >
<mailto:
>> seenafallah(a)gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>
>> >>>>>>> > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)gmail.com>>>
>> >>>>>>> > > > >
<mailto:seenafallah@gmail.com
>> >>>>>>> > <mailto:seenafallah@gmail.com>
>> >>>>>>> > > <mailto:seenafallah@gmail.com
<mailto:
>> >>>>>>> seenafallah(a)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(a)redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>>
>> >>>>>>> > > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>>>
>> >>>>>>> > > > > >
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>>
>> >>>>>>> > > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com
>> >>>>>>> >>>
>> >>>>>>> > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
>> >>>>>>> > > <mailto:mbenjami@redhat.com
<mailto:
>> mbenjami(a)redhat.com>>
>> >>>>>>> > > >
<mailto:mbenjami@redhat.com
>> >>>>>>> > <mailto:mbenjami@redhat.com>
>> >>>>>>> >
>> >>>>>>
>> >>>>>>
>> > _______________________________________________
>> > Dev mailing list -- dev(a)ceph.io
>> > To unsubscribe send an email to dev-leave(a)ceph.io
>>
>>