On Tue, Mar 15, 2016 at 2:44 PM, Loris Cuoghi <lc@xxxxxxxxxxxxxxxxx> wrote: > So, one key per RBD. > Or, dynamically enable/disable access to each RBD in each hypervisor's key. > Uhm, something doesn't scale here. :P > (I wonder if there's any limit to a key's capabilities string...) > > But, as it appears, I share your view that it is the only available > approach right now. > > Anyone would like to prove us wrong? :) The OSD capabilities aren't fine-grained enough to prevent you from creating objects, except by specifying that you only get access to certain prefixes or namespaces. So, either you lock down a key to a specific set of RBD volumes, or you let it create RBD volumes arbitrarily. ...unless, maybe, you can keep it from writing to the RBD index objects? But that doesn't prevent the user from scribbling across your cluster, just registering it. ;) That said, it is *possible* (although probably *unwise*) to give hypervisor keys access to all of the RBD volumes they host. cephx keys can have an arbitrary number of "allow" clauses, although I imagine if you get them large enough it could cause trouble (or maybe not?) in terms of memory usage or just plain old permission parsing time. And you'd likely run into issues with newly-created or newly-migrated instances ending up on a hypervisor which has an old version of its keyring cached. I'm not certain if there's a way to refresh those on-demand from the monitor. -Greg _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |