On 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 > 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. It looks to me like Maat is already pretty close to what the use of CephFS on untrusted clients would require. Any idea why Maat does not use a kerberized Ceph service and the corresponding shared session keys? I think that could avoid the generation and distribution of per client keys and outsource the shared key negotation to a standardized mechanism (and allow for integration with existing authN service infrastructures, of course). Also, why was the Maat idea (which was apparently implemented, tested and benchmarked) not integrated into mainline Ceph? Thanks! Arne
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
