Open Stack

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 ?

> [...]
> 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,

-- 
Thierry Carrez (ttx)