Integrate with Keystone Authentication

Registered by Jay Pipes on 2010-12-20

Support Keystone Authentication layer, via in-process middleware and remote auth middleware.

Blueprint information

Thierry Carrez
Jay Pipes
Kevin L. Mitchell
Series goal:
Accepted for diablo
Milestone target:
milestone icon 2011.3
Started by
Jay Pipes on 2011-06-14
Completed by
Thierry Carrez on 2011-08-23

Related branches



First appeared in diablo-4

Setting to Medium, as same bug report was that priority

Work items:

Create middleware for Auth: TODO
Implement a simple auth server driver for middleware to call: TODO
Write stubout for auth layer for main unittests: TODO
Write unit tests for auth layer and driver: TODO
Write functional integration tests that spin up a Keystone auth server and a Glance API server with middleware pipelined: TODO

Starting over. Original branch had major bit-rot.

From Kevin:

Howdy. I'm going to be working on adding ownership information to
glance images--the idea is to have private images be visible to those
users that created them, as well as restricting access to private
images. Since your the PTL, I wanted to coordinate with you and make
sure that my approach makes sense, as well as to clarify my
understanding of how glance hangs together.

My plan for glance is to add an owner column to the images table, to be
populated with the Keystone tenant ID (and permitting NULL for backwards
compatibility). (To counter the argument that it belongs in the
metadata instead, I should point out that it needs certain
restrictions--I don't really intend for users to be able to just give
their images away to other tenants, at least not without some careful
thinking about the security implications.) For public images, the owner
column doesn't really matter, but for private images, the owner will be
used to make the image visible in listings. Of course, users with the
"admin" role will be able to set images to have any owner, including a
NULL owner.

This owner column will be coupled with a "NullAuthentication"
middleware, which will allow anonymous access (i.e., what we have now)
and set up reasonable defaults. I will also write another middleware
which will be distributed with keystone which will provide the
appropriate integration. Some simple enhancements for optional
authentication in the client API and CLI will round out the situation
for glance.

The piece of information I need about the glance set-up is to understand
the interaction between glance-api and glance-registry, and in
particular how you envision that interaction being secured. I.e., when
I pass the data off to glance-registry, should I transfer the user's
keystone auth token and expect to add authentication middleware to the
registry pipeline, or should I assume that connection is secured
already? What will be able to interact with glance-registry--only the
glance-api on the same host, or glance-api on multiple hosts, or what?

This ought to be enough for me to get started, given my reading of the
existing documentation for glance, but I definitely welcome any thoughts
you have on the approach I've outlined above...


Still to do: "Set up a functional test that spins up an out-of-process keystone server and performs a full run-through of requests to glance-api server that is hooked into keystone."


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.