Hi Greg, On Wed, Nov 13, 2013 at 6:45 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > 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 AFAICT, this would allow single users to mount a subtree on CephFS and prevent them from writing where they are not permitted. But our use-case is different: we want to mount /cephfs/ from shared workstations and batch nodes to store personal home directories, shared group areas, and read-only software areas. Managing per-user keyrings and per-user mountpoints would become quickly unmanageable. > 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 > Thanks! I'll take a look. > 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 It's true, they are separable, but strong authn would have little utility without strong authz, and vice versa. > 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 Right, the shared secret is the kerberos service key in our model. > 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 It sounds like like you're referring to the Sideboard above, which unless I'm wrong won't help for our (not uncommon?) use-case. Cheers, Dan > 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
