Re: kerberos / AD requirements, blueprint

["Matt W. Benjamin" <matt@linuxbox.com>]

I meant to say, per-user protection.

Matt

----- "Matt W. Benjamin" <matt@linuxbox.com> 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@cern.ch> 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@newdream.net> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html