On Wed, Nov 13, 2013 at 8:05 AM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: > Hi all, > This mail is just to let you know that we've prepared a draft > blueprint related to adding strong(er) authn/authz to cephfs: > > http://wiki.ceph.com/01Planning/02Blueprints/Firefly/Strong_AuthN_and_AuthZ_for_CephFS > > The main goal of the idea is that we'd like to be able to use CephFS > from untrusted clients: > - the CephX key gives full rw access to pools (e.g. data/metadata) > via rados; we cannot distribute this key to untrusted hosts. > - root on untrusted clients can forge their uid/gid and rm -rf /cephfs/*. > > In the doc we've proposed one way to add authn/authz to the ceph > server side, but perhaps there is a simpler (more feasible in the > short term) solution which would enable us to allow untrusted cephfs > clients. You want to check out: http://wiki.ceph.com/01Planning/Sideboard/Client_Security_for_CephFS, the previous edition of the client security blueprint http://www.ssrc.ucsc.edu/Papers/leung-sc07.pdf, "Scalable Security for Petascale Parallel File Systems", which discusses one way of using MDS-granted permissions http://www.ssrc.ucsc.edu/Papers/li-fast13.pdf, "Horus: Fine-Grained Encryption-Based Security for Large-Scale Storage" is largely orthogonal in specifics but might inspire some other ides It looks to me like you've actually got two different blueprints there, though – "Allow Ceph clients to use Kerberos as an entry point" and "Enable stronger CephFS security". You're going to need to discuss the MDS tickets in a lot more detail than you have there, though — for instance, with your current description you'll need a shared secret between the OSD and MDS, and you'll need to expire the client extra keys, etc. You may want to consider skipping this in the first iteration and just implementing proper security on the MDS while relying on RADOS-level options to keep data secure (separate namespaces or pools for different users, and providing narrow caps to clients). That would also leave more time for some serious research into how to do a scalable implementation of any ticketing system we create. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html