Yes, Sage, your answers make sense (in regard to cephx). Thanks! A word of warning on this response: I am in the R&D side of our center and do not make final decisions on file system adoption.
Ideally, protecting KVM images (stored using the KVM-RBD code) and files with ACLs would be ideal. I agree with Claudio on the need to deal with untrusted client machines in large deployments. I think a potential usage scenario for ceph (if it has enterprise authentication like Kerberos) is to combine the performance of a scalable scratch file system with the security benefits of an enterprise file system like AFS for sharing data across organizations (or within workgroups). The ability to potentially use one file system (instead of two) is an attractive thought for a high performance computing center (and its users). In theory, I think ceph's use of scalable metadata would allow it to achieve higher performance than AFS when many client compute nodes access the same directory (with tens of thousands of files). In addition, ceph could eliminate some of the complexity of AFS--teaching users about client side caching and callbacks. I'm not trying to bash AFS (and I don’t think it will disappear anytime soon) since it is very stable, but I think ceph has a promising design, especially with respect to scalable metadata. Thanks, Nathan -----Original Message----- From: Cláudio Martins [mailto:[email protected]] Sent: Sunday, August 01, 2010 1:43 PM To: Sage Weil Cc: Nathan Regola; [email protected] Subject: Re: cephx questions On Fri, 30 Jul 2010 16:07:47 -0700 (PDT) Sage Weil <[email protected]> wrote: > On Fri, 30 Jul 2010, Nathan Regola wrote: > > Hi, > > > > Thank you for this excellent project. Are you still planning on > > incorporating the code from the Maat paper at some time in the future? > > As I'm sure you already know, access control lists on the storage > > objects would be quite useful to store research data. > > We may. The question is what granularity of security people really need. > Maat essentially gives fine-grains access control on individual objects > storing file data, based on the user you are logged in as on the client. > But in order for this to be very useful, you need some additional > user-level distributed authentiation scheme like Kerberos, or else a > misbehaving client can pose as any user on that host. Currently, the > kernel client authenticates to cephx and is given a capability to access > all objects in the file system object pool.. the same set of objects it > can access by traversing the namespace as 'root'. It doesn't get access > to other object pools in the distributed object store (e.g., metadata > objects, rbd images, or other pools you may create). > > What kind of objects (or files?) do you want to protect with ACLs? Do you > need object granularity, or is pool granularity sufficient? > Hi all, As far as I'm concerned, if we could get file granularity it would be great. I think the NFSv4 ACL model, for example, would be an excellent model for Ceph ACLs. Note that for realistic general purpose deployments (think big enterprise workgroup or university campus) you will have to cope with untrusted client machines. So you will end up using Kerberos or some kerberos-like security mechanism. NFSv4 and AFS are attractive because of this and I think that Ceph with file ACLs and Kerberos support would be very appealing to those people (who already have a working Kerberos setup, but may be looking for a more scalable/robust file storage solution). I'd be glad to help test/debug any such features. Best regards Cláudio
