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.
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>
>> >
_______________________________________________________________________
<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>
<mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>>
> <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com> <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>>>>
> >
<mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
<mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>> <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
<mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>>>
> <mailto:cbodley@redhat.com
<mailto:cbodley@redhat.com>
<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>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>>
> > >> >>
>>>> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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.).
<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>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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>>>>
> > >> >>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>>
> > >> >>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<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>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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>>>>
> >
<mailto:ash@styra.com
<mailto:ash@styra.com> <mailto:ash@styra.com
<mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>
> <mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>>>
> > >> >>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>
> <mailto:ash@styra.com <mailto:ash@styra.com>
<mailto:ash@styra.com <mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>>
> >
<mailto:ash@styra.com
<mailto:ash@styra.com> <mailto:ash@styra.com
<mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>
> <mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>
<mailto:ash@styra.com
<mailto:ash@styra.com>
<mailto:ash@styra.com
<mailto:ash@styra.com>>>>>>> wrote:
> > >> >>
>>>> > >>
> > >> >> >>>> > >> Hello
Seena,
> > >> >> >>>> > >>
> > >> >> >>>> > >> The OPA
integration is
with
the RGW and
> >> >> the intent is
> >> >> >>>> > to check if an authenticated
user is
> > >> >> allowed to perform a
> > >> >> >>>> > particular action
on a
particular
>
>> >> resource. For example,
> >> >> >>>> > can Bob delete a bucket based
on some
> >> >> attribute like
his
> >> >> >>>> > location. I am not familiar
with the
> > >> >> internals of Ceph's
> > >> >> >>>> > bucket policy
command. It
would
be great
> > >> >> to get some
> > >> >> >>>> > context here and
discuss
if the
bucket
> >> >> policy can be
> >> >> >>>> > authorized with OPA which is
the intent of
> > >> >> your PR I believe.
> > >> >> >>>> > >>
> > >> >> >>>> > >> Thanks
> > >> >> >>>> > >> Ash
> > >> >> >>>> > >>
> > >> >> >>>> > >> On Fri,
Jan 17, 2020
at 6:33
AM Seena
> > >> >> Fallah
> > >> >> >>>> >
<seenafallah(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>>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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>>>>
> > >> >>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>> <mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>>
> > >> >>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>
>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>>>
> >
<mailto:mbenjami@redhat.com
<mailto:mbenjami@redhat.com>
<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>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com> <mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>>
> > >> >>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>
>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>>>
> >
<mailto:seenafallah@gmail.com
<mailto:seenafallah@gmail.com>
<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>>>>
> > >> >>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io> <mailto:dev@ceph.io
<mailto:dev@ceph.io>>>
> <mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>>>>
> >
<mailto:dev@ceph.io <mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
> <mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>>
> >
<mailto:dev@ceph.io <mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>
<mailto:dev@ceph.io
<mailto:dev@ceph.io>>>>>>
>
>> >> >>>> > >>>> > To unsubscribe send an
email to
> > >> >> dev-leave(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>>>>
> >
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>>
> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>>>>
> > >> >>
>>>> > <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>
> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>>
> >
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>>>
> > >> >> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>
> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto: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>>>
> >
<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(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>>>>
> > >> >>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>
> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto: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>>>
> >
<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(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>>>>
> > >> >>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>
> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>>> <mailto:dev-leave@ceph.io
<mailto:dev-leave@ceph.io>
<mailto:dev-leave@ceph.io
<mailto: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>>
<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