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

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

On 2/5/20 8:54 AM, Seena Fallah wrote:
> Hi all.
>
> Any updates here? :)
>
> On Sat, Feb 1, 2020 at 10:37 AM Seena Fallah <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>> wrote:
>
> I should also mention that if we get access to bucket via bucket
> policy and reject it via AWS IAM, the request will reject so I
> think we should make a new behavior at what we should do with this
> two source of truth?
>
> On Sat, Feb 1, 2020 at 10:33 AM Seena Fallah
> <seenafallah@gmail.com <mailto:seenafallah@gmail.com>> wrote:
>
> Yes but the main problem is when the policy isn't set in AWS
> IAM for example a user has only AmazonS3ReadOnlyAccess and we
> give PutObject policy via bucket policy, user can put object
> to that bucket but in radosgw, OPA will deny this process
> because there is only ReadOnlyAccess to that bucket for user
> and radosgw will not check bucket policy that gave access to
> user.
> I think we should weight bucket policy over OPA so if bucket
> policy accept that request it doesn't need to be checked with
> OPA BUT if there is no policy according to that request it
> should check by OPA because if the policy according to that
> request isn't set bucket policy will reject that request so it
> against failed!
>
> On Fri, Jan 31, 2020 at 1:30 AM Casey Bodley
> <cbodley@redhat.com <mailto:cbodley@redhat.com>> wrote:
>
>
> On 1/30/20 2:18 PM, Seena Fallah wrote:
> > Hi Casey,
> >
> > The main problem now is when OPA integration is enabled
> bucket
> > policies aren’t work!
> > I have checked AWS S3 that what is doing when both
> bucket policy and
> > IAM policy (the policy is set with AWS panel in IAM
> section) is set it
> > will OR between two of them so now in radosgw S3 we
> don’t have this
> > feature and bucket policies won’t work when OPA
> integration is enabled.
> >
> > So I think it’s better to active this feature and
> enabled bucket
> > policy when OpA integration is enabled.
> >
> > There is two solutions here in this discussion for
> enabling bucket
> > policy on OPA integration:
> > 1. Send bucket policy on set/del actions to OPA server
> to be apply on
> > OPA policy rules so in this case the source of truth
> will be OPA (the
> > state that we have now in OPA integration) and so these
> policies that
> > sent from bucket policy will be applied.
> > 2. OR between bucket policy and OPA policy like AWS S3.
> So there is
> > two source of truth in this case and if any of them deny
> the request,
> > the request will be denied.
>
> What you described here in 2. is exactly how it currently
> works.
>
> >
> > Do have any other solutions we have here and which of
> these solutions
> > do you prefer to have?
> >
> > On Thu, Jan 30, 2020 at 10:21 PM Casey Bodley
> <cbodley@redhat.com <mailto:cbodley@redhat.com>
> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>
> wrote:
> >
> > Hi Seena,
> >
> > I think it would probably help if you could describe
> your use case
> > here,
> > and what role you want OPA to play in the
> interpretation of these
> > bucket
> > policies. In other words, what is it that your OPA
> policy is doing
> > with
> > these bucket policy documents that shouldn't be done
> within radosgw?
> >
> > On 1/30/20 1:09 AM, Seena Fallah wrote:
> > > So Matt what should we have done with bucket
> policy if we enable
> > OPA
> > > integration?
> > >
> > > On Thu, Jan 30, 2020 at 1:45 AM Matt Benjamin
> > <mbenjami@redhat.com <mailto:mbenjami@redhat.com>
> <mailto:mbenjami@redhat.com <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>> wrote:
> > >
> > > I think we should not be introducing new
> special case
> > behavior, nor
> > > sending policy documents to OPA, which from
> what we have
> > heard and
> > > read, intends to make no use of them.
> > >
> > > Matt
> > >
> > > On Wed, Jan 29, 2020 at 4:45 PM Seena Fallah
> > > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>> wrote:
> > > >
> > > > I think it’s better to OR between two of the
> bucket
> > policies and
> > > OPA policies. So if one of them reject certain
> access the
> > request
> > > will reject as AWS do on its IAM and bucket
> policy.
> > > > Are you okay with this idea?
> > > >
> > > > On Wed, Jan 29, 2020 at 11:13 PM Casey Bodley
> > > <cbodley@redhat.com
> <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>>
> > <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>>>> wrote:
> > > >>
> > > >>
> > > >> On 1/28/20 2:45 PM, Matthias Muench wrote:
> > > >> > Hi,
> > > >> > I think making Ceph special to what the
> rest of the clients
> > > in the
> > > >> > world would expect would be a bit off the
> idea of providing
> > > S3 like
> > > >> > service.
> > > >> > To my understanding, setting OPA to be
> the source of
> > truth would
> > > >> > introduce latency (based on Casey’s
> comments) and will not
> > > allow to
> > > >> > set policies (based on Seena).
> > > >> > The first one brings us towards harder
> latency and
> > especially
> > > >> > depending on extern systems resource
> capability (assume
> > central
> > > >> > resource as the idea is and therefor not
> necessarily really
> > > “in reach”
> > > >> > within an acceptable latency, routing in
> addition,
> > etc.). The
> > > second
> > > >> > one says simply that this would break any
> existing
> > > compatibility with
> > > >> > clients and use cases. To me it looks not
> that good to
> > loose
> > > on both ends.
> > > >>
> > > >> Agreed. Even if one has to opt-in to this
> broken s3
> > > compatiblity, I'm
> > > >> skeptical that users will find this to be a
> compelling target
> > > for their
> > > >> applications.
> > > >>
> > > >> The existing prototype of OPA integration
> sends this
> > authorization
> > > >> request to OPA -in addition to- radosgw's
> own authorization
> > > logic, where
> > > >> we consult any of our user/bucket policies
> or ACLs that
> > apply.
> > > In this
> > > >> model, OPA is not the only source of truth.
> It just has the
> > > opportunity
> > > >> to deny access that we would otherwise
> grant, so it doesn't
> > > require that
> > > >> we break compatibility with any S3 features
> that conflict
> > with
> > > OPA's
> > > >> view of policy.
> > > >>
> > > >> Were we to change this so that OPA was the
> only source of
> > > truth, then
> > > >> we'd be left with two bad options: either
> reject all requests
> > > to modify
> > > >> policy and break existing applications, or
> send all
> > policy/ACL
> > > >> information to OPA and require every OPA
> policy script to
> > implement
> > > >> s3-compatible enforcement of them. I also
> don't see any
> > benefit
> > > to this
> > > >> model - why, if an client wants to use s3
> policy to
> > restrict a
> > > certain
> > > >> access, would OPA want to override that and
> grant access
> > instead?
> > > >>
> > > >> > I could live more with the latency issue
> but wouldn’t
> > like it.
> > > >> > For the second, I can understand the idea
> of having
> > > simplification for
> > > >> > auditing the access but I’m not that
> convinced to take the
> > > burden of
> > > >> > being “the special” one that nobody wants
> to work with.
> > So, I
> > > would
> > > >> > love to see the full fledged support of
> setting the
> > policy by
> > > clients,
> > > >> > no matter what the result would be in
> terms of
> > implementing it to
> > > >> > interact with OPA. Instead, having an
> additional
> > requirement to
> > > >> > implement additional handling to set
> policies different
> > from
> > > what S3
> > > >> > actually provides would require special
> clients first and
> > > secondly an
> > > >> > additional path to OPA with all the
> additional burden
> > to tweak
> > > >> > security to allow this path to OPA. I
> feel that the first
> > > wouldn’t
> > > >> > happen (special clients) and the second
> in practice not
> > > either because
> > > >> > of security constraints by the OPA admin
> folks.
> > > >> >
> > > >> > G,
> > > >> > -matt
> > > >> >
> > > >> > ——————————————————
> > > >> > Matthias Muench
> > > >> > Senior Specialist Solution Architect
> > > >> > EMEA Storage Specialist
> > > >> > matthias.muench@redhat.com
> <mailto:matthias.muench@redhat.com>
> > <mailto:matthias.muench@redhat.com
> <mailto:matthias.muench@redhat.com>>
> > > <mailto:matthias.muench@redhat.com
> <mailto:matthias.muench@redhat.com>
> > <mailto:matthias.muench@redhat.com
> <mailto:matthias.muench@redhat.com>>>
> <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>
> > <mailto:mmuench@redhat.com <mailto:mmuench@redhat.com>>
> > > <mailto:mmuench@redhat.com
> <mailto:mmuench@redhat.com> <mailto:mmuench@redhat.com
> <mailto:mmuench@redhat.com>>>>
> > > >> > Phone: +49-160-92654111
> <tel:+49-160-92654111>
> > > >> >
> > > >> > Red Hat GmbH
> > > >> > Werner-von-Siemens-Ring 14
> <x-apple-data-detectors://2/1>
> > > >> > 85630 Grasbrunn
> <x-apple-data-detectors://2/1>
> > > >> > Germany <x-apple-data-detectors://2/1>
> > > >> >
> > >
> >
>    _______________________________________________________________________
> > > >> > Red Hat GmbH, http://www.de.redhat.com
> > <http://de.redhat.com/> ·
> > > >> > Registered seat: Grasbrunn, Commercial
> register:
> > Amtsgericht
> > > Muenchen
> > > >> > HRB 153243 · Managing Directors: Charles
> Cachera, Michael
> > > O'Neill, Tom
> > > >> > Savage, Eric Shander
> > > >> >
> > > >> >> On Jan 28, 2020, at 15:02, Seena Fallah
> > > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>> wrote:
> > > >> >>
> > > >> >>
> > > >> >> Amazon AWS S3 has two type of policies.
> One from bucket
> > > policy and
> > > >> >> one form IAM. I think it could be better
> to have two
> > > policies models
> > > >> >> in Ceph one from bucket policy and one
> form OPA if its
> > enable.
> > > >> >> So if you are okay we can change the PR
> to make bucket
> > > policy enabled
> > > >> >> when OPA is enabled, too. Because now
> bucket policies not
> > > working
> > > >> >> when OPA integration is enabled.
> > > >> >>
> > > >> >> On Tue, Jan 28, 2020 at 2:57 AM Seena Fallah
> > > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>> wrote:
> > > >> >>
> > > >> >> Matt When OPA integration is enabled
> S3 policies
> > doesn’t
> > > work! If
> > > >> >> you want them to be worked we should
> bypass S3
> > policies
> > > to OPA
> > > >> >> for being applied and worked.
> > > >> >> Here we have conflict in OPA
> integration with S3
> > policies!
> > > >> >>
> > > >> >> On Tue, Jan 28, 2020 at 2:52 AM Matt
> Benjamin
> > > >> >> <mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>>> wrote:
> > > >> >>
> > > >> >> My take so far is that this is
> not a bug, and I'd
> > > like not to
> > > >> >> introduce special-case logic to
> override or
> > suppress
> > > >> >> processing of
> > > >> >> native policy.
> > > >> >>
> > > >> >> Matt
> > > >> >>
> > > >> >> On Mon, Jan 27, 2020 at 5:24 PM
> Seena Fallah
> > > >> >> <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>> wrote:
> > > >> >> >
> > > >> >> > I think it's very good that
> Ceph export its
> > > authorization
> > > >> >> and we could have external
> source of truth
> > with it. S3
> > > >> >> policies can transport to OPA
> and updates by users
> > > set/del
> > > >> >> policies.
> > > >> >> > But now we have conflict with OPA
> > integration and S3
> > > >> >> policies which is set when OPA
> integration is
> > > enabled, aren't
> > > >> >> work.
> > > >> >> >
> > > >> >> > Can you all please help to fix
> this bug?
> > > >> >> >
> > > >> >> > On Fri, Jan 24, 2020 at 1:05
> PM Seena Fallah
> > > >> >> <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>> wrote:
> > > >> >> >>
> > > >> >> >> Hi all.
> > > >> >> >>
> > > >> >> >> Any updates here?
> > > >> >> >>
> > > >> >> >> On Tue, Jan 21, 2020 at 2:50
> AM Seena Fallah
> > > >> >> <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>> wrote:
> > > >> >> >>>
> > > >> >> >>> OPA can be used in companies that
> uses many
> > > services like
> > > >> >> k8s, Ceph,... and want to have
> one central
> > point for
> > > >> >> authorizing users so they can
> maintenance their
> > > access for
> > > >> >> each user on each service for
> example and etc.
> > It’s
> > > just a
> > > >> >> use case and so it’s really good
> to have it. I
> > think
> > > this is
> > > >> >> the biggest use case for having
> OPA in
> > products that
> > > gets an
> > > >> >> option to centralize authorizing
> for all types of
> > > services.
> > > >> >> >>>
> > > >> >> >>> Performance for this model is issue
> like
> > having
> > > keystone
> > > >> >> with Ceph. So I think it’s based
> on users that
> > > active this
> > > >> >> integrations at all.
> > > >> >> >>>
> > > >> >> >>> The model for writing policies to
> radosgw
> > isn’t
> > > really
> > > >> >> good I think because of the
> reason above if
> > this accrued
> > > >> >> there is always two copies of
> policies and it
> > > doesn’t sounds
> > > >> >> good for maintaining.
> > > >> >> >>>
> > > >> >> >>> If bucket policy disable, s3
> clients like
> > boto3
> > > and etc
> > > >> >> will not work for setting
> polices but I think when
> > > someone is
> > > >> >> enabling OPA for authorizing it
> will also have an
> > > API for
> > > >> >> his/her OPA server to set/del
> policies and
> > they can call
> > > >> >> these APIs to set/del policies.
> > > >> >> >>> And for extensions like
> PublicAccessBlock,
> > it will
> > > >> >> disable because OPA is just
> authorizing
> > requests and
> > > Ceph
> > > >> >> doesn’t authorize any request
> when OPA integration
> > > is enabled
> > > >> >> so OPA should handle any
> incoming policies
> > were made
> > > by S3
> > > >> >> policies. So it doesn’t make
> conflicts and if OPA
> > > integration
> > > >> >> is enabled it won’t work as we
> return 405 on each
> > > set/del
> > > >> >> policies requests and if OPA is
> disabled users can
> > > use this
> > > >> >> policies.
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >>> On Tue, Jan 21, 2020 at 2:05 AM
> Casey Bodley
> > > >> >> <cbodley@redhat.com
> <mailto:cbodley@redhat.com>
> > <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>
> > <mailto:cbodley@redhat.com <mailto:cbodley@redhat.com>>>
> > > <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>>
> > <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com
> <mailto:cbodley@redhat.com>>>>> wrote:
> > > >> >> >>>>
> > > >> >> >>>> I am a big fan of the IAM policy
> documents,
> > > both because
> > > >> >> of the
> > > >> >> >>>> flexibility and expressiveness
> they provide,
> > > and because
> > > >> >> they're in a
> > > >> >> >>>> format that all of our s3 clients
> understand.
> > > >> >> >>>>
> > > >> >> >>>> I'm not familiar enough with OPA
> to know
> > what extra
> > > >> >> capabilities it
> > > >> >> >>>> offers that IAM policy cannot, but
> I have
> > serious
> > > >> >> concerns about the
> > > >> >> >>>> performance and scalability of a
> model where
> > > radosgw has
> > > >> >> to send
> > > >> >> >>>> blocking RPCs to OPA in order to
> > authorize each and
> > > >> >> every request.
> > > >> >> >>>>
> > > >> >> >>>> On the other hand, consider a
> model where a
> > > Policy Agent
> > > >> >> exercises its
> > > >> >> >>>> control over authorization by
> writing IAM
> > > documents to
> > > >> >> radosgw, which we
> > > >> >> >>>> use to cheaply authorize requests
> out of our
> > > metadata
> > > >> >> cache. I would
> > > >> >> >>>> imagine that this model could
> cover a lot of
> > > interesting
> > > >> >> use cases,
> > > >> >> >>>> without breaking support for
> existing s3
> > > applications
> > > >> >> that rely on
> > > >> >> >>>> bucket policy - as the proposal to
> reject
> > > >> >> PutBucketPolicy requests would.
> > > >> >> >>>>
> > > >> >> >>>> Is this something that OPA could
> feasibly do?
> > > >> >> >>>>
> > > >> >> >>>> For use cases that aren't supported by
> > the existing
> > > >> >> policy grammar,
> > > >> >> >>>> we're open to maintaining
> extensions to these
> > > documents.
> > > >> >> We already
> > > >> >> >>>> implement a number of s3 extensions
> > [1][2] that are
> > > >> >> easily accessible
> > > >> >> >>>> via python/boto and the aws cli.
> > > >> >> >>>>
> > > >> >> >>>> But a model where radosgw outsources
> > authorization
> > > >> >> entirely is a hard
> > > >> >> >>>> sell, because it conflicts with
> feature
> > development
> > > >> >> going forward. One
> > > >> >> >>>> example would be support for
> > PublicAccessBlock [3],
> > > >> >> where radosgw needs
> > > >> >> >>>> full visibility into policy to
> detect cases
> > > where public
> > > >> >> access would be
> > > >> >> >>>> granted.
> > > >> >> >>>>
> > > >> >> >>>> [1]
> > > >> >> >>>>
> > > >> >>
> > >
> >
> https://docs.ceph.com/docs/master/radosgw/s3/python/#using-s3-api-extensions
> > > >> >> >>>>
> > > >> >> >>>> [2]
> > > >> >> >>>>
> > > >> >>
> > >
> >
> https://github.com/ceph/ceph/blob/master/examples/boto3/service-2.sdk-extras.json
> > > >> >> >>>>
> > > >> >> >>>> [3]
> https://github.com/ceph/ceph/pull/30033
> > > >> >> >>>>
> > > >> >> >>>> On 1/20/20 12:21 PM, Seena Fallah
> wrote:
> > > >> >> >>>> > I’m also agree with you Matt
> that it will
> > > free us from
> > > >> >> complexity of
> > > >> >> >>>> > handling S3 policy or Swift ACL
> if we save
> > > the current
> > > >> >> state of OPA.
> > > >> >> >>>> > But if we want use this state of
> OPA we
> > > should act for
> > > >> >> S3 policy and
> > > >> >> >>>> > Swift ACL that if user is
> setting them it
> > > shouldn’t be
> > > >> >> allowed and
> > > >> >> >>>> > return user that you can’t set them!
> > Because
> > > now when
> > > >> >> OPA integration
> > > >> >> >>>> > is enabled and user set bucket
> policy
> > it returns
> > > >> >> success but actually
> > > >> >> >>>> > it doesn’t work!
> > > >> >> >>>> >
> > > >> >> >>>> > What are your thoughts?
> > > >> >> >>>> >
> > > >> >> >>>> > On Sun, Jan 19, 2020 at 12:33 AM
> Seena
> > Fallah
> > > >> >> <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>
> > > >> >> >>>> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>>> wrote:
> > > >> >> >>>> >
> > > >> >> >>>> > I think the other problem
> caused when OPA
> > > >> >> integration is enabled
> > > >> >> >>>> > and we set bucket policy is
> when user
> > > wants to get
> > > >> >> his/her bucket
> > > >> >> >>>> > policy. Some policies are set
> through OPA
> > > (for
> > > >> >> example in OPA
> > > >> >> >>>> > rules we have user A that has
> access to
> > > user B
> > > >> >> bucket so OPA
> > > >> >> >>>> > return true on authorizing
> request and it
> > > acts
> > > >> >> like bucket policy)
> > > >> >> >>>> > and some through bucket policy
> (s3 clients
> > > >> >> command). So when user
> > > >> >> >>>> > is getting his/her bucket
> policy what
> > > data should
> > > >> >> we return? The
> > > >> >> >>>> > policies that are set through
> bucket
> > > policy or OPA
> > > >> >> rules for that
> > > >> >> >>>> > bucket?
> > > >> >> >>>> >
> > > >> >> >>>> > I fact I think OPA rules are
> not static
> > > and will
> > > >> >> change in time
> > > >> >> >>>> > and so there should be a client
> interface
> > > for that
> > > >> >> OPA server that
> > > >> >> >>>> > users could change their rules
> for their
> > > buckets
> > > >> >> (giving access to
> > > >> >> >>>> > put, get, ... to someone else
> and etc.).
> > > So if the
> > > >> >>
> >
>   <https://www.google.com/maps/search/%C2%A0?entry=gmail&source=g>client
> > exists
> > > >> >> >>>> > there is no need to bucket
> policy and we
> > > can make
> > > >> >> it disable (by
> > > >> >> >>>> > returning 405) when OPA
> integration is
> > > enabled (I
> > > >> >> repeat that
> > > >> >> >>>> > still now in Ceph latest
> version when OPA
> > > >> >> integration is enabled
> > > >> >> >>>> > bucket policies aren’t work!)
> because the
> > > policies
> > > >> >> that are set
> > > >> >> >>>> > with bucket policy can be check
> with OPA,
> > > too.
> > > >> >> >>>> >
> > > >> >> >>>> > What’s your opinion?
> > > >> >> >>>> >
> > > >> >> >>>> > On Fri, Jan 17, 2020 at 9:40 PM
> Seena
> > Fallah
> > > >> >> >>>> > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>>> wrote:
> > > >> >> >>>> >
> > > >> >> >>>> > I think when OPA integration is
> > > enabled the
> > > >> >> source of truth
> > > >> >> >>>> > for authorizing should be
> OPA (it is
> > > right now
> > > >> >> in Ceph and all
> > > >> >> >>>> > requests are authorizing with
> OPA and Ceph
> > > >> >> doesn’t authorize
> > > >> >> >>>> > any request by it self).
> > > >> >> >>>> > When user is using bucket
> policy
> > feature
> > > >> >> he/she wants to get
> > > >> >> >>>> > access to someone else so when
> he/she
> > is the
> > > >> >> bucket owner,
> > > >> >> >>>> > he/she can perform this action
> and we
> > should
> > > >> >> apply this policy
> > > >> >> >>>> > for him/her. If we want
> policies just
> > > update
> > > >> >> within OPA
> > > >> >> >>>> > server/client and S3 clients
> (s3cmd,
> > aws, ...)
> > > >> >> don’t edit
> > > >> >> >>>> > policies, we should reply to
> them that
> > > >> >> set/delpolicy isn’t
> > > >> >> >>>> > allowed from here (return 405
> for example;
> > > >> >> just for saying
> > > >> >> >>>> > that the request that user
> send isn’t
> > > successful).
> > > >> >> >>>> >
> > > >> >> >>>> > Yes we can have some
> process and
> > > >> >> simplification before sending
> > > >> >> >>>> > it to OPA but the s3 policy
> has a
> > general
> > > >> >> structure so OPA
> > > >> >> >>>> > server can decode it by it self.
> > > >> >> >>>> >
> > > >> >> >>>> > On Fri, Jan 17, 2020 at
> 9:16 PM Matt
> > > Benjamin
> > > >> >> >>>> > <mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>
> > > >> >> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>
> > > >> >> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>>>>
> > wrote:
> > > >> >> >>>> >
> > > >> >> >>>> > The larger question, I think,
> is what OPA
> > > >> >> is supposed to
> > > >> >> >>>> > do with it.
> > > >> >> >>>> > The larger question I think it
> asks is
> > > >> >> whether OPA or Ceph
> > > >> >> >>>> > owns a
> > > >> >> >>>> > particular dimension of policy--or,
> > > >> >> perhaps, which owns
> > > >> >> >>>> > policy for
> > > >> >> >>>> > what portions of the namespace
> (at any
> > > >> >> particular point in
> > > >> >> >>>> > time).
> > > >> >> >>>> >
> > > >> >> >>>> > Without any new interaction,
> when OPA is
> > > >> >> configured, OPA
> > > >> >> >>>> > can make a
> > > >> >> >>>> > direct authorization decision
> with all
> > > >> >> available
> > > >> >> >>>> > information for
> > > >> >> >>>> > Ceph/RGW, notwithstanding any
> S3 or Swift
> > > >> >> ACL or S3 policy
> > > >> >> >>>> > that might
> > > >> >> >>>> > exist--including any that might
> have been
> > > >> >> stored prior to
> > > >> >> >>>> > turning on
> > > >> >> >>>> > this proposed feature to push
> policy
> > > >> >> documents to OPA. This
> > > >> >> >>>> > overriding property of the OPA
> integration
> > > >> >> when in use
> > > >> >> >>>> > frees us from a
> > > >> >> >>>> > lot of complexity regarding
> which system
> > > >> >> is the source of
> > > >> >> >>>> > truth, and
> > > >> >> >>>> > for what.
> > > >> >> >>>> >
> > > >> >> >>>> > I can see value in more
> sophisticated
> > > >> >> integration that
> > > >> >> >>>> > mutually
> > > >> >> >>>> > comprehends policy--but I'm
> having trouble
> > > >> >> with "send
> > > >> >> >>>> > policy documents
> > > >> >> >>>> > to OPA, maybe it will do something
> > with them."
> > > >> >> >>>> >
> > > >> >> >>>> > Matt
> > > >> >> >>>> >
> > > >> >> >>>> > On Fri, Jan 17, 2020 at 12:01
> PM Seena
> > Fallah
> > > >> >> >>>> > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>>> wrote:
> > > >> >> >>>> > >
> > > >> >> >>>> > > Hello Ash
> > > >> >> >>>> > >
> > > >> >> >>>> > > With bucket policy user A can
> get access
> > > >> >> to user B for
> > > >> >> >>>> > putting object on bucket C. So
> if this
> > > >> >> policy sent to Ceph
> > > >> >> >>>> > and OPA integration is enabled
> it will be
> > > >> >> discard because
> > > >> >> >>>> > this policy isn’t sent to OPA
> server to be
> > > >> >> updated.
> > > >> >> >>>> > > Here is a documentation for
> bucket
> > policy:
> > > >> >> >>>> > >
> > > >> >>
> https://docs.ceph.com/docs/master/radosgw/bucketpolicy/
> > > >> >> >>>> > >
> > > >> >> >>>> > > With this PR when user set bucket
> > > >> >> policy, the data of
> > > >> >> >>>> > that policy will sent to OPA
> server to be
> > > >> >> applied and so
> > > >> >> >>>> > OPA can get access to user that
> gets
> > > >> >> access to bucket via
> > > >> >> >>>> > bucket policy.
> > > >> >> >>>> > >
> > > >> >> >>>> > > On Fri, Jan 17, 2020 at 8:24
> PM Ash
> > Narkar
> > > >> >> >>>> > <ash@styra.com
> <mailto:ash@styra.com> <mailto:ash@styra.com
> <mailto:ash@styra.com>>
> > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>>
> > > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>
> > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>>>
> > > >> >> <mailto:ash@styra.com
> <mailto:ash@styra.com> <mailto:ash@styra.com
> <mailto:ash@styra.com>>
> > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>>
> > > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>
> > <mailto:ash@styra.com <mailto:ash@styra.com>
> <mailto:ash@styra.com <mailto:ash@styra.com>>>>>> wrote:
> > > >> >> >>>> > >>
> > > >> >> >>>> > >> Hello Seena,
> > > >> >> >>>> > >>
> > > >> >> >>>> > >> The OPA integration is with
> the RGW and
> > > >> >> the intent is
> > > >> >> >>>> > to check if an authenticated
> user is
> > > >> >> allowed to perform a
> > > >> >> >>>> > particular action on a particular
> > > >> >> resource. For example,
> > > >> >> >>>> > can Bob delete a bucket based
> on some
> > > >> >> attribute like his
> > > >> >> >>>> > location. I am not familiar
> with the
> > > >> >> internals of Ceph's
> > > >> >> >>>> > bucket policy command. It would
> be great
> > > >> >> to get some
> > > >> >> >>>> > context here and discuss if the
> bucket
> > > >> >> policy can be
> > > >> >> >>>> > authorized with OPA which is
> the intent of
> > > >> >> your PR I believe.
> > > >> >> >>>> > >>
> > > >> >> >>>> > >> Thanks
> > > >> >> >>>> > >> Ash
> > > >> >> >>>> > >>
> > > >> >> >>>> > >> On Fri, Jan 17, 2020 at 6:33
> AM Seena
> > > >> >> Fallah
> > > >> >> >>>> > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>>> wrote:
> > > >> >> >>>> > >>>
> > > >> >> >>>> > >>> So when OPA integration is
> enabled the
> > > >> >> bucket policy
> > > >> >> >>>> > from users will not work!
> > > >> >> >>>> > >>> I think it’s about Ceph
> architecture
> > > >> >> not OPA because
> > > >> >> >>>> > OPA is for authorizing the
> requests and
> > > >> >> bucket policy is
> > > >> >> >>>> > one of the authorizing methods
> that OPA
> > > >> >> should support.
> > > >> >> >>>> > >>>
> > > >> >> >>>> > >>> On Fri, Jan 17, 2020 at
> 5:56 PM Matt
> > > >> >> Benjamin
> > > >> >> >>>> > <mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>
> > > >> >> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>
> > > >> >> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>
> > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>
> > > <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com> <mailto:mbenjami@redhat.com
> <mailto:mbenjami@redhat.com>>>>>>
> > wrote:
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> Hi Seena,
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> As I wrote in a comment on
> your PR,
> > > >> >> my current
> > > >> >> >>>> > intuition is that what
> > > >> >> >>>> > >>>> you're doing here isn't
> consistent
> > > >> >> with the original
> > > >> >> >>>> > intent of the OPA
> > > >> >> >>>> > >>>> integration we currently
> have, nor
> > > >> >> with the OPA model
> > > >> >> >>>> > in general.
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> That said, I'd really like
> some
> > > >> >> feedback from OPA
> > > >> >> >>>> > architects, CC'd.
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> regards,
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> Matt
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> On Thu, Jan 16, 2020 at
> 5:04 AM Seena
> > > >> >> Fallah
> > > >> >> >>>> > <seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> <mailto:seenafallah@gmail.com <mailto:seenafallah@gmail.com>>>
> > > >> >> <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>
> > > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>
> > <mailto:seenafallah@gmail.com
> <mailto:seenafallah@gmail.com>>>>>> wrote:
> > > >> >> >>>> > >>>> >
> > > >> >> >>>> > >>>> > Hi all. In OPA
> integration from
> > > >> >> Ceph there is no
> > > >> >> >>>> > integration for bucket policy.
> > > >> >> >>>> > >>>> > When user is setting
> bucket policy
> > > >> >> to his/her
> > > >> >> >>>> > bucket the OPA server won't get
> who get's
> > > >> >> access to that
> > > >> >> >>>> > bucket so after that if the
> request is
> > > >> >> coming from the
> > > >> >> >>>> > user (that gets access to that
> bucket via
> > > >> >> bucket policy)
> > > >> >> >>>> > to access that bucket (PUT,
> GET,...), OPA
> > > >> >> will reject that
> > > >> >> >>>> > because of no data in database.
> > > >> >> >>>> > >>>> > I have create a pull
> request for
> > > >> >> this problem so if
> > > >> >> >>>> > user creates a bucket policy
> for his/her
> > > >> >> bucket, the
> > > >> >> >>>> > policy data will send to OPA
> server to be
> > > >> >> update on the
> > > >> >> >>>> > database.
> > > >> >> >>>> > >>>> > I think the main idea of
> having OPA
> > > >> >> is to have all
> > > >> >> >>>> > authorization in OPA and Ceph don't
> > > >> >> authorize any request
> > > >> >> >>>> > by it self.
> > > >> >> >>>> > >>>> > Here is the pull request
> and I
> > > >> >> would be thankful to
> > > >> >> >>>> > hear about your comments.
> > > >> >> >>>> > >>>> >
> > https://github.com/ceph/ceph/pull/32294
> > > >> >> >>>> > >>>> > Thanks.
> > > >> >> >>>> > >>>> >
> > > >> >>
>   _______________________________________________
> > > >> >> >>>> > >>>> > Dev mailing list --
> dev@ceph.io <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>
> > > >> >> <mailto:dev@ceph.io
> <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>
> > > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>>
> > > >> >> >>>> > >>>> > To unsubscribe send an
> email to
> > > >> >> dev-leave@ceph.io
> <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>
> > > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>
> > > >> >> >>>> > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>
> > > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>>>
> > > >> >> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>>
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> --
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> Matt Benjamin
> > > >> >> >>>> > >>>> Red Hat, Inc.
> > > >> >> >>>> > >>>> 315 West Huron Street,
> Suite 140A
> > > >> >> >>>> > >>>> Ann Arbor, Michigan 48103
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>>
> > > >> >>
> http://www.redhat.com/en/technologies/storage
> > > >> >> >>>> > >>>>
> > > >> >> >>>> > >>>> tel. 734-821-5101
> > > >> >> >>>> > >>>> fax. 734-769-8938
> > > >> >> >>>> > >>>> cel. 734-216-5309
> > > >> >> >>>> > >>>>
> > > >> >> >>>> >
> > > >> >> >>>> >
> > > >> >> >>>> > --
> > > >> >> >>>> >
> > > >> >> >>>> > Matt Benjamin
> > > >> >> >>>> > Red Hat, Inc.
> > > >> >> >>>> > 315 West Huron Street, Suite 140A
> > > >> >> >>>> > Ann Arbor, Michigan 48103
> > > >> >> >>>> >
> > > >> >> >>>> >
> > http://www.redhat.com/en/technologies/storage
> > > >> >> >>>> >
> > > >> >> >>>> > tel. 734-821-5101
> > > >> >> >>>> > fax. 734-769-8938
> > > >> >> >>>> > cel. 734-216-5309
> > > >> >> >>>> >
> > > >> >> >>>> >
> > > >> >> >>>> >
> > _______________________________________________
> > > >> >> >>>> > Dev mailing list -- dev@ceph.io
> <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>
> > > >> >> >>>> > To unsubscribe send an email to
> > > dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>
> > > >> >> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>
> > > >> >> >>>>
> > _______________________________________________
> > > >> >> >>>> Dev mailing list -- dev@ceph.io
> <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>>>>
> > > >> >> >>>> To unsubscribe send an email to
> > > dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>
> > > >> >> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >>
> > > >> >> Matt Benjamin
> > > >> >> Red Hat, Inc.
> > > >> >> 315 West Huron Street, Suite 140A
> > > >> >> Ann Arbor, Michigan 48103
> > > >> >>
> > > >> >>
> http://www.redhat.com/en/technologies/storage
> > > >> >>
> > > >> >> tel. 734-821-5101
> > > >> >> fax. 734-769-8938
> > > >> >> cel. 734-216-5309
> > > >> >>
> > > >> >>
> _______________________________________________
> > > >> >> Dev mailing list -- dev@ceph.io
> <mailto:dev@ceph.io> <mailto:dev@ceph.io <mailto:dev@ceph.io>>
> > <mailto:dev@ceph.io <mailto:dev@ceph.io>
> <mailto:dev@ceph.io <mailto:dev@ceph.io>>>
> > > >> >> To unsubscribe send an email to
> dev-leave@ceph.io <mailto:dev-leave@ceph.io>
> > <mailto:dev-leave@ceph.io <mailto:dev-leave@ceph.io>>
> > > <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
> <mailto:dev-leave@ceph.io>>>
> > > >>
> > >
> > >
> > > --
> > >
> > > Matt Benjamin
> > > Red Hat, Inc.
> > > 315 West Huron Street, Suite 140A
> > > Ann Arbor, Michigan 48103
> > >
> > > http://www.redhat.com/en/technologies/storage
> > >
> > > tel. 734-821-5101
> > > fax. 734-769-8938
> > > cel. 734-216-5309
> > >
> >
>