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,
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
