Hi, Is the goal then NOT to provide per-user authn (etc) as AFS or DCE would do, when a user accesses files using the kernel client (and provide for that, in general)? I would have thought that was a lot of the point. It seems like that is the well trodden path, for AFS, DFS, NFSv4, it's basically similar, varying only in that NFSv4's per-user token propagation is a bit better integrated on Linux (but doesn't yet provide the PAG concept). Matt ----- "Andrea Ieri" <andrea.ieri@xxxxxxx> wrote: > Hi Sage, > > It's perhaps useful to clear up that Kerberos as a protocol provides > your service with the following information (at the end of the initial > exchange): > 1. a string representing a Kerberos principal (user@REALM) > 2. a session key, known only to you and the principal above > 3. a reasonable assurance that whoever sent you the ticket that > contains the data above controls the principal mentioned (as in "knows > its password") > > Now, you can choose what to do with the information above. > - you'll most likely need to map the "principal" to a "user", whatever > that means for your system (a UID/GID tuple obtained via LDAP? A user > string in your own local database?) > - you'll have to decide what to do with the session key. Do you want > to encrypt all communication? Implement a MAC? Throw it away? See for > example the different Kerberos options in NFSv4 > > In any case as you can see Kerberos is not concerned with > authorization at all. How you enforce permissions is out of its > scope. > > Cheers, > Andrea > > On 22/10/2014 18:39, Dan Van Der Ster wrote: > > 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 > >> -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -- 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
