Hi Sage,

> On 16 Oct 2014, at 21:57, Sage Weil <[email protected]> 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
> 

Reply via email to