Open Stack

On Thu, 2013-06-27 at 16:35 +0200, Thierry Carrez wrote:
> Adam Young wrote:
> > Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I
> > manage to get somebody's token I can do whatever this person is able to do.
> 
> Right. Tokens are considered secrets for that reason.
> 
> > To fix it, the other services that use tokens to:
> > 
> > 1. Authenticate the identity
> > 2. Match the name in the token to the  identity that authenticated the connection. 
> > 
> > If the names match then you can be sure that the user that connected to the service and presented a token is the same user that acquired the token from keystone in the first place.
> 
> That sounds like an extra layer of security rather than a "fix" ?
> 
> > To make this happen we need to add authentication to the connections between clients and services.  
> > 
> > To be able to do that we need to 
> > 1. Enable multiple forms of authentication per client.  The best way to do this is to use a common client library, which we have developed in keystoneclient 
> > 2. Use the 'requests' libraray for HTTP across all clients
> > 3. Enable running the API servers in Apache HTTPD.  Making Eventlet support X509 CLient certs and Kerberos is going to be difficult, and the likelihood of introducing a security problem is high.
> 
> Devil's advocate says: the key idea behind Keystone was to centralize
> authentication, though. Doesn't this extra layer kind of defeat that ?
> Why would you need tokens at all, with a strongly-authenticated
> connection to the API servers ?

No, because the role of keystone is authentication and authorization.
Just because you can securely connect to an API server does that mean
you are a valid user? It's a likely scenario that not everyone in an
organization with a kerberos ID is going to actually have an account or
any permissions in an openstack deployment. Also what roles and
permission does the user have when they connect?

When connecting to a strongly-authenticated server the server needs no
knowledge of your ldap tree or user list, it simply needs to compare
what it receives via kerberos or client cert with what keystone has
validated and put in the token. This is also handled completely within
the auth_token middleware from keystoneclient and so will not be
something that will impact development of other projects, but a security
feature that deployments may enable.

It will also always be an optional feature.

> > [...]
> > So this raises a couple of points. 
> > - We need to get Nova, Quantum and Cinder to use keystoneclient.
> 
> I'm actually surprised that they don't, so +1 :)
> 
> > - Eventlet is mostly gone from the clients already. I'm not sure how
> > many of those http requests would end up actually blocking.
> 
> +1
> 
> > - It would appear that clients have all at some point taken a central
> > layout approach and with it taken httplib. We probably can't get them
> > all changed over to requests before we try to add kerberos.
> 
> I'm not sure they would be so opposed to the idea. Especially
> considering the next point.
> 
> > - There is already a number of concerns around the way we use https. By
> > default httplib does not verify https certificates, requests does and
> > provides global ways of setting the bundle.
> > https://wiki.openstack.org/wiki/SecureClientConnections already
> > advocates for the transfer to requests with some interesting examples
> > like https://bugs.launchpad.net/python-glanceclient/+bug/1079692
> > (Server's name isn't verified when using https)
> 
> We definitely need a more consistent support of https rather than so
> many different implementations that fail in so many different ways. FWIW
> we'd consider absence of server cert checking in Python client libraries
> connections as a vulnerability, so please report as a security bug any
> occurrence of that.
> 
> Regards,
>