I meant to say, per-user protection. Matt ----- "Matt W. Benjamin" <matt@xxxxxxxxxxxx> wrote: > 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 -- 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
