Re: CDS blueprint: strong auth for cephfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux