Perhaps something like this? mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow r class-read object_prefix rbd_directory, allow rwx object_prefix rbd_header., allow rwx object_prefix rbd_data., allow rwx object_prefix rbd_id.' As Greg mentioned, this won't stop you from just creating random objects in the pool that match the substrings list in the cap, but it will prevent you from creating new images. -- Jason Dillaman Red Hat Ceph Storage Engineering dillaman@xxxxxxxxxx http://www.redhat.com ----- Original Message ----- > From: "Gregory Farnum" <gfarnum@xxxxxxxxxx> > To: "Loris Cuoghi" <lc@xxxxxxxxxxxxxxxxx> > Cc: ceph-users@xxxxxxxxxxxxxx > Sent: Tuesday, March 15, 2016 5:54:43 PM > Subject: Re: cephx capabilities to forbid rbd creation > > 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 > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |