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 >>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
