[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    Re: [ceph-devel] Ceph Authentication and Authorization
From:       Adam Lewis <supercargo () gmail ! com>
Date:       2009-08-14 20:24:05
Message-ID: 3e7465d20908141324m54635202ub2979a4c3c3756e () mail ! gmail ! com
[Download RAW message or body]

Sage,

> I suspect most users will be satisfied with the ability to delegate trust=
 to
> (root on) a client host mounting the fs, as they're accustomed to doing
> with NFS.

Don't assume that I'm satisfied with anything I'm accustomed to doing
with NFS ;)

Okay, back to lurking.

Adam


On Fri, Aug 14, 2009 at 2:38 PM, Sage Weil <sage@newdream.net> wrote:
>
> Hi Ethan!
>
> On Fri, 14 Aug 2009, Ethan L. Miller wrote:
> > Andrew Leung, Stephanie Jones, and I designed a protocol to do this in
> > 2007. =A0You should look at the paper we wrote:
> > <http://www.ssrc.ucsc.edu/pub/leung07-sc.html>
>
> This protocol deals primarily with the problem of authorizing clients to
> access individual (sets of) objects (based on file ownership, etc.) within
> the object store. =A0We're initially solving the more basic problem of
> authentication and authorization of the client to talk to the MDSs/OSDs
> (i.e., mount the file system) in the first place. =A0Andrew's prototype m=
ore
> or less assumes that problem is already solved. =A0(In particular, the
> monitor hands out user tickets to anyone who asks.)
>
> The initial goal is simply to avoid a userland client instance from
> getting complete access to the file system. =A0And to restrict librados
> users to individual object storage pools.
>
> Once that problem is solved, implementing fine grained per-file access
> control is certainly possible, but at this stage I suspect most users will
> be satisfied with the ability to delegate trust to (root on) a client host
> mounting the fs, as they're accustomed to doing with NFS.
>
> sage
>
>
> > The protocol we designed used the MDS to hand out keys, and supported
> > group authentication as well as expiring keys with group renewals. =A0It
> > also supported delegation: a user could generate a public/private key
> > pair and delegate access to only specific files to anyone with the
> > private key that was generated. =A0The result was a highly scalable
> > security system with less than 5% overhead (sometimes much less) on
> > the benchmarks we ran.
> >
> > The code was implemented in Ceph, and Andrew likely has it around
> > somewhere. =A0It probably needs to be updated to work with the current
> > version of Ceph, and will need bulletproofing, but it's a good start.
> >
> > > We're currently working on an authentication module for ceph. This
> > > will allow us both keeping the cluster secured internally, as no bad
> > > servers will be able to join the cluster, and both externally. E.g.,
> > > only permitted clients will be able to do certain specified
> > > operations. This is just a rough description of what we consider right
> > > now, but here it is:
> > >
> > > The following are the basic requirements:
> > > * Robust, scalable, keeps up with the cluster's consistency.
> > > * Identify the different cluster modules (e.g., mon, mds and osd) and
> > > allow only the permitted entities to participate in the cluster
> > > * Identify the clients, and set up a mechanism to authenticate them.
> > > Establish a session between the client and the cluster
> > > =A0* The created session will allow the client to communicate with the
> > > different cluster entities
> > > =A0* It will be possible to sign (and possibly encrypt) all protocol
> > > operations
> >
> > > I'd love to hear any comment, idea or request that you might have as
> > > we're about to start implementing this stuff.
> >
> > ( Ethan L. Miller =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: elm@cs.ucsc.edu =
=A0 =A0 =A0 =A0 =A0 =A0)
> > ( Professor, Computer Science =A0 Web: http://www.cs.ucsc.edu/~elm/ )
> > ( University of California =A0 =A0 =A0Phone: +1 831 459-1222 =A0 =A0 =
=A0 =A0 =A0 =A0)
> > ( Santa Cruz, CA 95064 USA =A0 =A0 =A0Fax: =A0 +1 831 459-1041 =A0 =A0 =
=A0 =A0 =A0 =A0)
> > ( PGP keyprint: 76C7 D699 1FF6 A1A4 B7A1 9629 2EBF 1273 A6ED 6A09 )
> >
> >
> > -----------------------------------------------------------------------=
-------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30=
-Day
> > trial. Simplify your report design, integration and deployment - and fo=
cus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. =A0http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Ceph-devel mailing list
> > Ceph-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ceph-devel
> >
> >
>
> -------------------------------------------------------------------------=
-----
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-D=
ay
> trial. Simplify your report design, integration and deployment - and focu=
s on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. =A0http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Ceph-devel mailing list
> Ceph-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ceph-devel

---------------------------------------------------------------------------=
---
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day =

trial. Simplify your report design, integration and deployment - and focus =
on =

what you do best, core application coding. Discover what's new with =

Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ceph-devel mailing list
Ceph-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ceph-devel


[prev in list] [next in list] [prev in thread] [next in thread]