aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wickman <wick...@apache.org>
Subject Re: timeline on aurora-515: kerberos support
Date Thu, 26 Jun 2014 23:20:51 GMT
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