My particular interest is for a less dynamic environment, so manual key distribution is not a problem. Re. OpenStack, it's probably good enough to have the Cinder host creating them as needed (presumably stored in its DB) and just send the secret keys over the message bus to compute hosts as needed - if your infrastructure network is not trusted then you've got bigger problems to worry about. It's true that a lot of clouds would end up logging the secrets in various places, but then they are only useful on particular hosts. I guess there is nothing special about the default "" namespace compared to any other as far as cephx is concerned. It would be nice to have something of a nested auth, so that the client requires explicit permission to read the default namespace (configured out-of-band when setting up compute hosts) and further permission for particular non-default namespaces (managed by the cinder rbd driver), that way leaking secrets from cinder gives less exposure - but I guess that would be a bit of a change from the current namespace functionality. On 13 February 2015 at 05:57, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > On 02/10/2015 07:54 PM, Blair Bethwaite wrote: >> >> Just came across this in the docs: >> "Currently (i.e., firefly), namespaces are only useful for >> applications written on top of librados. Ceph clients such as block >> device, object storage and file system do not currently support this >> feature." >> >> Then found: >> https://wiki.ceph.com/Planning/Sideboard/rbd%3A_namespace_support >> >> Is there any progress or plans to address this (particularly for rbd >> clients but also cephfs)? > > > No immediate plans for rbd. That blueprint still seems like a > reasonable way to implement it to me. > > The one part I'm less sure about is the OpenStack or other higher level > integration, which would need to start adding secret keys to libvirt > dynamically. -- Cheers, ~Blairo _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |