aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: timeline on aurora-515: kerberos support
Date Tue, 02 Sep 2014 15:42:42 GMT
Thanks for the update, Alexius!  This is great news!

-=Bill


On Sat, Aug 30, 2014 at 12:08 PM, Alexius Ludeman <lex@lexinator.com> wrote:

> Hi,
>
> I've just completed the code associated with this task(& aurora-159
> <https://issues.apache.org/jira/browse/AURORA-159>).  I have a working
> scheduler and client that use SPNEGO to authenticate.  There is still work
> ahead for authorization.
>
> Once it goes through some internal code review(~1 week), I will try and
> start the process to get this outbounded.  Just a word of warning this out
> bounding process could take some time...
>
> thanks
>
>
>
> On Thu, Jun 26, 2014 at 5:19 PM, Alexius Ludeman <lex@lexinator.com>
> wrote:
>
> > 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