Open Stack

I replied to almost exactly this email off-list and so thought i would copy my reply to -dev.


----- Original Message -----
> From: "Jamie Lennox" <jamielennox at redhat.com>
> To: "Sanket Lawangare" <sanket.lawangare at gmail.com>
> Sent: Wednesday, February 25, 2015 6:39:14 AM
> Subject: Re: Kerberos in OpenStack
> 
> 
> 
> ----- Original Message -----
> > From: "Sanket Lawangare" <sanket.lawangare at gmail.com>
> > To: jamielennox at redhat.com
> > Sent: Wednesday, February 25, 2015 5:43:38 AM
> > Subject: Kerberos in OpenStack
> > 
> > Hello Mr. Jamie Lennox,
> > 
> > My name is Sanket Lawangare. I am a graduate Student studying at The
> > University of Texas, at San Antonio. For my Master’s Thesis I am
> working on
> > the Identity component of OpenStack. My research is to investigate
> external
> > authentication with Identity(keystone) using Kerberos. I am working
> with
> > ICS- Institute for Cyber Security at UTSA under Mr. Farhan Patwa.
> 
> Hi Sanket, we are working quite hard on kerberos at the moment so it's
> nice to have you on board .
> Make sure you hang around in #openstack-keystone on Freenode, if i'm not
> around (I'm based in Sydney so Timezones clash) Adam Young (ayoung) is
> up to date on all this.
> 
> > Based on reading your Blogs and my understanding of Kerberos I have
> come up
> > with a figure explaining possible interaction of KDC with the
> OpenStack
> > client, Keystone and the OpenStack services(Nova, Cinder, Swift...). I
> am
> > trying to understand the working of Kerberos in OpenStack.
> > 
> > Please click this link for viewing the figure:
> >
> https://docs.google.com/drawings/d/1re0lNbiMDTbnkrqGMjLq6oNoBtR_GA0x7NWacf0Ulbs/edit?usp=sharing
> > 
> > P.S. - [The steps in this figure are self explanatory the basic
> > understanding of Kerberos is expected]
> > 
> > Based on the figure i had couple of questions:
> > 
> > 
> >    1.
> > 
> >    Is Nova or other services registered with the KDC?
> 
> No not at this time. OpenStack does all it's AuthN/AuthZ for
> non-keystone services via a token at this time we purely capture the
> POST /v3/auth/tokens route which issues a token with kerberos and use
> the REMOTE_USER as proof of AuthN rather than needing a user/pass. After
> this point OpenStack operates using a token as per normal.
> 
> > 
> >    1.
> > 
> >    What does keystone do with Kerberos ticket/credentials? Does
> Keystone
> >    authenticates the users and gives them direct access to other
> services
> >    such
> >    as Nova, Swift etc..
> 
> Related to the first question, the OpenStack user information and their
> roles is encoded into the token data which is then validated by
> auth_token middleware on each of the services. After the initial AuthN
> kerberos request we do not currently do any additional kerberos auth.
> 
> > 
> >    1.
> > 
> >    After receiving the Ticket from the KDC does keystone embed some
> >    kerberos credential information in the token?
> 
> Keystone will set 'method' in the token field to reflect the method that
> was used to authenticate the token - however i can't remember if it sets
> the method to 'kerberos' or 'external' for kerberos auth.
> 
> > 
> >    1.
> > 
> >    What information does the service (e.g.Nova) see in the Ticket and
> the
> >    token (Does the token have some kerberos info or some customized
> info
> >    inside it?).
> 
> No this information is completely hidden from the other services.
>  
> > 
> > If you could share your insights and guide me on the interaction
> between
> > these components. I would be really appreciate it. Thank you for your
> time.
> 
> So those answers are pretty short in that kerberos is really only used
> for that initial AuthN contact, after which keystone issues a token and
> everything else works without kerberos. there is an advantage to this in
> that you don't have to do the 401 Negotiate dance on every request but
> it does lack the security of kerberos (tokens are bearer tokens and can
> be intercepted and used).
> 
> I think what you are looking for is the 'token binding' feature. This is
> actually one of the first things I worked on in keystone, and we were
> simply not ready for it at the time.
> 
> There is the functionality in the tokens that make it so that a token
> can only be used in conjunction with another form of authentication and
> the expectation we had was that kerberos would be the main candidate,
> followed by SSL client certs. It means that if you used a valid token
> without also presenting the appropriate kerberos ticket authentication
> would fail.
> 
> The reason that this never took off is due to the way service to service
> communication happens. When you ask nova to boot you a virtual machine
> it makes a number of calls to the other services, glance to get the
> image, cinder for a block store, neutron for a network connection etc.
> To do this it reuses the user token, so nova will forward the token you
> give it to each of those services - and so if you bind it to the
> kerberos ticket then the same feature that gives security essentially
> stops that sharing and OpenStack stops working.
> 
> Now, there is an effort underway that when doing service to service
> communication you should also a service token. The way we currently
> operate is that each service requires a user which has permission to at
> least validate any tokens it is given. So instead of just passing
> 'X-Auth-Token' as we do now when a service forwards that token on to
> another service it would also forward a current 'X-Service-Token' for
> the service user.
> 
> What I hope this means is that we can start validating binds on tokens
> only on 'X-Service-Token' if present - because if this is nova talking
> to neutron the service token could be correctly bound to the nova
> service user. If not present we validate bind on 'X-Auth-Token' as
> normal. I think this will make token binding viable again. I'm pushing
> this from a number of fronts however I would be surprised if I could get
> all the services to fully adopt the approach in the L time frame (next 8
> months).
> 
> 
> I'm pretty sure I just overwhelmed you with information and it may not
> make sense immediately but I hope it does as you get into it more and
> give you some areas to research.
> 
> Feel free to send me any follow ups or future questions, I'm generally
> available in #openstack-keystone as well - though as i mentioned
> timezones don't always work out.
> 
> 
> Jamie
> 
> 
> 
> > Regards,
> > 
> > Sanket Lawangare
> > 
> > (Cell phone: 832-449-0550)
> > 
> 
>