I am configuring Glance to authenticate against Keystone. It works but I am unsure exactly how some of the authentication options interact.
I started with the configuring glance documentation, but this
doesn't actually document any of these options. I found the
authentication documentation, which discusses
some of them, but does not actually document auth_uri
.
The example glance configuration in the OpenStack Install and Deploy Manual looks like this:
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 127.0.0.1
service_port = 5000
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 012345SECRET99TOKEN012345
The authentication documentation says:
Those variables beginning with auth_ point to the Keystone Admin service. This information is used by the middleware to actually query Keystone about the validity of the authentication tokens.
Okay. So how does auth_uri
interact with auth_host
, auth_port
,
and auth_protocol
? Can one simply provide auth_uri
and discard
the other options? Is there a corresponding service_uri
configuration option? And why does the port in auth_uri
correspond to the service_port
in the above configuration instead of the auth_port
?
Keystone refers to port 35357
as the "admin" port, which to me
suggests that this would only be required for administration of
keystone (creating/deleting services, tenants, etc). Glance instead
refers to this as the "auth" port, which suggests a different use.
What exactly is provided by the service on port 35357 that is not
provided by the service on port 5000?
First check out: http://docs.openstack.org/ops/OpenStackOperationsGuide.pdf
Looking at the glance source code...
... is the only file that references auth_uri.
As for the differences between 5000 and 35357 on keystone...
http://docs.openstack.org/developer/keystone/api_curl_examples.html has a pretty explicit discussion of what API examples work on both, or not.
My understanding of port 5000 is that its specific purpose is to allow for public API authentication to keystone, so you don't need to expose 35357 just to allow people to authenticate to it.
As for why there are auth creds inside of each of the openstack components that tie into keystone... truthfully I don't. know.
However I should point out that API v2 is coming in grizzly. Not fully documented yet, and it will begin to introduce some radical changes in how keystone operates.