aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexius Ludeman <...@lexinator.com>
Subject Re: timeline on aurora-515: kerberos support
Date Fri, 27 Jun 2014 00:19:35 GMT
yeah sorry I didn't mean to imply forwarding credentials as a 1.0
requirement, just something I'd like to keep in mind.


On Thu, Jun 26, 2014 at 4:20 PM, Brian Wickman <wickman@apache.org> wrote:

> I think 1.0 will just be client <-> scheduler authentication.  In the
> future it would be great to either delegate or forward credentials to the
> Mesos sandbox, but that's not trivial and will likely require native
> support from Mesos.  It's not clear how one should model entities in this
> environment (e.g. host principals vs service principals vs task principals)
> and could even be different on a framework by framework basis.  I am no
> security/kerberos expert either so I'd defer to prior art here if any can
> be found.
>
>
> On Thu, Jun 26, 2014 at 3:55 PM, Alexius Ludeman <lex@lexinator.com>
> wrote:
>
> > great!  thanks for your quick reply.  I saw the client support change.
> >  understood on authorization.  Agreed that initial support could be with
> > flat files.
> >
> > I have a well established accounting system, so my focus will likely be
> > less on community solutions for managing authorization/identity.
>  Certainly
> > I am open to making the authentication/authorization that supports those
> > systems.
> >
> > It doesn't appear kerberos supports groups directly.   In my case my
> > kerberos server is backed by ldap which ideally I would want to manage
> > groups rather than role/users.   I don't know how specific that is to my
> > use case.
> >
> > One other thing I would like to support is the ability to forward
> kerberos
> > authentication on to slave/thermos.  This would allow the processes on
> the
> > slave to use those credentials.  I'm not totally clear if this even
> > possible based on my brief understanding of kerberos.
> >
> > thanks
> >
> >
> >
> > On Thu, Jun 26, 2014 at 2:25 PM, Brian Wickman <wickman@apache.org>
> wrote:
> >
> > > The first step of client support is there -- we created the
> > > TRequestsTransport on the client, which uses the python requests
> library
> > to
> > > do thrift-over-HTTP.  There is a python package called
> > 'requests-kerberos'
> > > that has a class called HTTPKerberosAuth that can be passed into
> > > TRequestsTransport and properly handles WWW-Authenticate negotiation.
> > >
> > > On the server side, we'll need to add a KerberosAuthFilter that does
> the
> > > SPNENO/WWW-Authenticate handshake and validates/extracts the GSSContext
> > > from the authenticate header.  This will need to do things like
> > validating
> > > that the target principal is the Aurora scheduler.
> > >
> > > This says nothing of authorization though -- we'll need to agree upon a
> > > solution for managing authorization, perhaps initially just flat files
> > or a
> > > simple mapping from user principal to accepted roles.  We should also
> > > investigate existing community solutions for authorization/identity
> > > management such as Apache Shiro.  Open for ideas on all fronts.
> > >
> > > I'd love to hear your input and a hand in any of the above would be
> > > welcomed and greatly appreciated.
> > >
> > > cheers,
> > > brian
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jun 26, 2014 at 1:50 PM, Alexius Ludeman <lex@lexinator.com>
> > > wrote:
> > >
> > > > hi Brian,
> > > >
> > > > I see "aurora client should support kerberos" in AURORA-515
> > > > <https://issues.apache.org/jira/browse/AURORA-515> and I am quite
> > > > interested on the expected timeline.   Is an early stage of it
> > available?
> > > >
> > > > If you think that AURORA-515 is in the order of months away for an
> > alpha
> > > > version then I would plan to develop it internally as I need it on a
> > > > shorter deadline.  I hope we can chat about your intended design so
> > that
> > > my
> > > > implementation could be similar and when the time comes I could swap
> my
> > > > local fork and use the upstream implementation.
> > > >
> > > > At this time I'll admit upfront I know very little about kerberos so
> I
> > > have
> > > > some learning ahead.
> > > >
> > > > thanks
> > > > lex
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message