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 :)
On Thu, Feb 6, 2020 at 8:16 PM Casey Bodley <cbodley(a)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>> 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@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@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(a)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(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>>>>
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@redhat.com>>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(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@redhat.com
<mailto:cbodley@redhat.com>
<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(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@redhat.com
<mailto:matthias.muench@redhat.com>
<mailto:matthias.muench@redhat.com
<mailto:matthias.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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(a)redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(a)gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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(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@redhat.com
> <mailto:cbodley@redhat.com>
>