Hi Sage, > On 16 Oct 2014, at 21:57, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > I started to write up a blueprint for kerberos / LDAP / AD support: > > https://wiki.ceph.com/Planning/Blueprints/Hammer/kerberos_authn%2C_AD_authn%2F%2Fauthz > > In case it isn't clear from that document, I only sort of know what I'm > talking about here. (This is largely based on what I managed to retain > from a conversation with Andrew, but I suspect I got some of it wrong.) > > For anyone working in environments where kerberos is in use, I am *very* > interested in hearing what your requirements are for your environment. In > particular, are you using AD or LDAP or something else? How do you expect > RBAC to work for you? Let’s talk about requirements then. (Anyway, I’m not in any way a kerberos expert and it is not 100% clear to me what you are trying to achieve.) Firstly, our environment is almost identical to that described by Marcus (we use AD). For filesystems, our user communities are used to the way OpenAFS works with kerberos. Generally, that means they use kinit && aklog to authenticate and they understand (mostly) how to use AFS groups and AFS ACLs for authz. Next I basically have a bunch of questions to clarify your goals. The first part of your blueprint seems to be a convenient way to distribute cephx keyrings. To prevent harvesting/reuse, would you intend those to not be “normal” cephx keyrings as such, but rather to be keyrings encrypted by the mon/whatever and time limited? For authz, is this mechanism meant to be used for RADOS only, or also for CephFS? If RADOS only, then as I understand it you could basically add the current cephx capabilities (with pool granularity) to the proposed ceph user db (perhaps scoped down to a few limited roles). I wouldn’t expect to be able to manipulate ceph capabilities via some AD blob (due mostly to my AD ignorance). I would probably expect to add our authorised ceph users to an AD group, then keep that in sync with your ceph user/role/capability db. If CephFS, then the problem I see is that the POSIX permissions/ACLs are being evaluated only on the client side. Were you thinking to change that, i.e. to add some notion of CephFS file-granular cephx capabilities? We thought a little bit about this before: https://wiki.ceph.com/Planning/Blueprints/%3CSIDEBOARD%3E/Strong_AuthN_and_AuthZ_for_CephFS The basic idea was to have an MDS or other service that evaluates permissions/ACLs on the server side then hands out an extra signed capability to be used by the client for IOs with an OSD. It seems heavyweight, however, so I’m not sure how this would perform in practise. Hope that helps, Dan > > We'll definitely have a slot for this at the upcoming CDS, but anything we > can hash out before then will make that conversation more productive. > > Thanks! > sage > ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
