Open Stack

On 06/27/2013 10:35 AM, 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 be specific, symmetric shared secrets.

>
>> 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" ?
If you consider "bearer tokens" to be sufficient security, then yes.  
If, on the other hand, bearer tokens are seen as a security risk, then 
it is 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 ?
Keystone centralizes both authentication and authorization.  It offloads 
the need to store passwords from all of  the various services to Keystone.

However,  authentication based solely on userid/password has a well 
documented body of known issues.  I am proposing that we use the more 
secure mechanisms for authentication, and limit keystone's role to 
authorization data.

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