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> 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> 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>> 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>>> 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>>>
> 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>>>
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: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>>>
> 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>>>> 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>>>> 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>>>> 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>>>> 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>>>> 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>>>>
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-extra…
> > > >> >> >>>>
> > > >> >> >>>> [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(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 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(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 when
OPA integration is
> > > enabled the
> > > >> >> source of truth
> > > >> >> >>>> > for
authorizing should be OPA (it is
> > > right now
> > > >> >> in Ceph and all
> > > >> >> >>>> > requests are
authorizing with OPA and
> Ceph
> > > >> >> doesn’t authorize
> > > >> >> >>>> > any request by
it self).
> > > >> >> >>>> > When user is
using bucket policy
> > feature
> > > >> >> he/she wants to get
> > > >> >> >>>> > access to someone
else so when he/she
> > is the
> > > >> >> bucket owner,
> > > >> >> >>>> > he/she can perform
this action and we
> > should
> > > >> >> apply this policy
> > > >> >> >>>> > for him/her.
If we want policies
> just
> > > update
> > > >> >> within OPA
> > > >> >> >>>> > server/client and
S3 clients (s3cmd,
> > aws, ...)
> > > >> >> don’t edit
> > > >> >> >>>> > policies, we
should reply to them that
> > > >> >> set/delpolicy isn’t
> > > >> >> >>>> > allowed from here
(return 405 for
> example;
> > > >> >> just for saying
> > > >> >> >>>> > that the
request that user send
> isn’t
> > > successful).
> > > >> >> >>>> >
> > > >> >> >>>> > Yes we can
have some process and
> > > >> >> simplification before sending
> > > >> >> >>>> > it to OPA but
the s3 policy has a
> > general
> > > >> >> structure so OPA
> > > >> >> >>>> > server can decode
it by it self.
> > > >> >> >>>> >
> > > >> >> >>>> > On Fri, Jan
17, 2020 at 9:16 PM Matt
> > > Benjamin
> > > >> >> >>>> >
<mbenjami(a)redhat.com
> > <mailto:mbenjami@redhat.com>
> > > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
> > > >> >> <mailto:mbenjami@redhat.com
> > <mailto:mbenjami@redhat.com>
> > > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>
> > > <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(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:
> > > >> >> >>>> > >
> > > >> >> >>>> > > Hello Ash
> > > >> >> >>>> > >
> > > >> >> >>>> > > With bucket
policy user A can get
> access
> > > >> >> to user B for
> > > >> >> >>>> > putting object on
bucket C. So if this
> > > >> >> policy sent to Ceph
> > > >> >> >>>> > and OPA
integration is enabled it will
> be
> > > >> >> discard because
> > > >> >> >>>> > this policy isn’t
sent to OPA server to
> be
> > > >> >> updated.
> > > >> >> >>>> > > Here is a
documentation for bucket
> > policy:
> > > >> >> >>>> > >
> > > >> >>
https://docs.ceph.com/docs/master/radosgw/bucketpolicy/
> > > >> >> >>>> > >
> > > >> >> >>>> > > With this PR
when user set bucket
> > > >> >> policy, the data of
> > > >> >> >>>> > that policy will
sent to OPA server to
> be
> > > >> >> applied and so
> > > >> >> >>>> > OPA can get access
to user that gets
> > > >> >> access to bucket via
> > > >> >> >>>> > bucket policy.
> > > >> >> >>>> > >
> > > >> >> >>>> > > On Fri, Jan
17, 2020 at 8:24 PM Ash
> > Narkar
> > > >> >> >>>> > <ash(a)styra.com
<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(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:
> > > >> >> >>>> > >>>
> > > >> >> >>>> > >>> So
when OPA integration is enabled
> the
> > > >> >> bucket policy
> > > >> >> >>>> > from users will
not work!
> > > >> >> >>>> > >>> I
think it’s about Ceph architecture
> > > >> >> not OPA because
> > > >> >> >>>> > OPA is for
authorizing the requests and
> > > >> >> bucket policy is
> > > >> >> >>>> > one of the
authorizing methods that OPA
> > > >> >> should support.
> > > >> >> >>>> > >>>
> > > >> >> >>>> > >>> On
Fri, Jan 17, 2020 at 5:56 PM Matt
> > > >> >> Benjamin
> > > >> >> >>>> >
<mbenjami(a)redhat.com
> > <mailto:mbenjami@redhat.com>
> > > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
> > > >> >> <mailto:mbenjami@redhat.com
> > <mailto:mbenjami@redhat.com>
> > > <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> > <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>
> > > <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(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:
> > > >> >> >>>> > >>>>
>
> > > >> >> >>>> > >>>>
> Hi all. In OPA integration from
> > > >> >> Ceph there is no
> > > >> >> >>>> > integration for
bucket policy.
> > > >> >> >>>> > >>>>
> When user is setting bucket
> policy
> > > >> >> to his/her
> > > >> >> >>>> > bucket the OPA
server won't get who
> get's
> > > >> >> access to that
> > > >> >> >>>> > bucket so after
that if the request is
> > > >> >> coming from the
> > > >> >> >>>> > user (that gets
access to that bucket
> via
> > > >> >> bucket policy)
> > > >> >> >>>> > to access that
bucket (PUT, GET,...),
> OPA
> > > >> >> will reject that
> > > >> >> >>>> > because of no data
in database.
> > > >> >> >>>> > >>>>
> I have create a pull request for
> > > >> >> this problem so if
> > > >> >> >>>> > user creates a
bucket policy for his/her
> > > >> >> bucket, the
> > > >> >> >>>> > policy data will
send to OPA server to
> be
> > > >> >> update on the
> > > >> >> >>>> > database.
> > > >> >> >>>> > >>>>
> I think the main idea of having
> OPA
> > > >> >> is to have all
> > > >> >> >>>> > authorization in
OPA and Ceph don't
> > > >> >> authorize any request
> > > >> >> >>>> > by it self.
> > > >> >> >>>> > >>>>
> Here is the pull request and I
> > > >> >> would be thankful to
> > > >> >> >>>> > hear about your
comments.
> > > >> >> >>>> > >>>>
>
> >
https://github.com/ceph/ceph/pull/32294
> > > >> >> >>>> > >>>>
> Thanks.
> > > >> >> >>>> > >>>>
>
> > > >> >> _______________________________________________
> > > >> >> >>>> > >>>>
> Dev mailing list -- dev(a)ceph.io
> > <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(a)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(a)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(a)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(a)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(a)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(a)ceph.io
<mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > > >> >> To unsubscribe send an email to
dev-leave(a)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
> > >
> >
>
>