How to launch the Swift functional test suite with Keystone

It is easy to launch the swift functional tests with v2 auth (Keystone).

Assuming you have a recent version of python-swiftclient, python-keystoneclient and swift you need to first add a few users which is easily done with this script :

Assuming you have already your OS_* variables configured with an admin, you can just launch it and it will :

  • add a tenant/user named test/tester.
  • add a tenant/user name test2/tester2.
  • add a user tester3 belonging to test2 but not operator on that tenant.

and it will create a /etc/swift/swift.conf for testing. You can adjust the keystone host in auth_host there (default to 127.0.0.1)

You can now just go to your swift directory and launch the script :

  $ ./.functests

and the functional tests will run against a keystone server (or a auth v2 api compatible server).

Keystone and PKI tokens overview

PKI tokens has been implemented in keystone by Adam Young and others and was shipped for the OpenStack grizlly release. It is available since the version 2.0 API of keystone.

PKI is a beautiful acronym to Public-key infrastructure which according to wikipedia defines it like this :

Public-key cryptography is a cryptographic technique that enables users to securely communicate on an insecure public network, and reliably verify the identity of a user via digital signatures.

As described more lengthy on this IBM blog post keystone will start to generate a public and a private key and store it locally.

When getting the first request the service (i.e: Swift) will go get the public certificate from keystone and store it locally for later use.

When the user is authenticated and a PKI token needs to be generated, keystone will take the private key and encrypt the token and the metadata (i.e: roles, endpoints, services).

The service by the mean of the auth_token middleware will decrypt the token with the public key and get the info to pass on to the service it set the *keystone.identity* WSGI environement variable to be used by the other middleware of the service in the paste pipeline.

The PKI tokens are then much more secure since the service can trust where the token is coming from and much more efficient since it doesn’t have to validate it on every request like done for UUID token.

Auth token

This bring us to the auth_token middleware. The auth token middleware is a central piece of software of keystone to provide a generic middleware for other python WSGI services to integrate with keystone.

The auth_token middleware was moved in grizzly to the python-keystoneclient package, this allows us to don’t have to install a full keystone server package to use it (remember this is supposed to be integrated directly in services).

You usually would add the auth_token middleware in your paste pipeline at the begining of it (there may be other middlewares before like logging, catch_errors and stuff so not quite the first one).

[filter:authtoken]
signing_dir = /var/cache/service
paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
auth_host = keystone_host
auth_port = keystone_public_port
auth_protocol = keystone_public_port
auth_uri = http://keystone_host:keystone_admin_port/
admin_tenant_name = service
admin_user = service_user
admin_password = service_password

There is much more options to the auth_token middleware, I invite you to refer to your service documentation and read a bit the top of the auth_token file here.

When the service get a request with a X-Auth-Token header containing a PKI token the auth middleware will intercept it and start to do some works.

It will validate the token by first md5/hexdigesting it, this is going to be the key in memcache as you may have seen the PKI token since containing all the metadatas can be very long and are too big to server as is for memcache.

It will check if we have the key in memcache and if not start verify the signed token.

Before everything the token is checked if it was revoked (see my previous article about PKI revoked tokens). The way it’s getting the revoked token is to first check if the token revocation list is expired (by default it will do a refresh for it every seconds).

If it need to be refreshed it will do a request to the url ‘/v2.0/tokens/revoked‘ with an admin token to the keystone admin interface and get the list of revoked tokens.

The list get stored as well on disk for easy retrieval.

If the token is not revoked it will convert the token to a proper CMS format and start verifying it.

Using the signing cert filename and the ca filename it will invoke the command line openssl CLI to do a cms -verify which will decode the cms token providing the decoded data. If the cert filename or the ca filename was missing it will fetch it again.

Fetching the signing cert will be done by doing a non authenticated query to the keystone admin url ‘/v2.0/certificates/signing‘. Same goes for the ca making a query to the keystone url ‘/v2.0/certificates/ca‘.

When we have the decoded data we can now build our environement variable for the other inside the environement variable call keystone.token_info this will be used next by the other services middleware. Bunch of new headers will be added to the request with for example the User Project ID Project Name etc..

The md5/hexdigest PKI token is then stored with the data inside memcache.

And that’s it, there is much more information on the IBM blog post and on Adam’s blog I am mentionning earlier.

Howto revoke a token with keystone and PKI (v2.0 API)

This is something I have been asked and I was at first under impression it was only available in v3, digging a bit more into the code there is actually a way to do that in v2 when you are using PKI tokens. Since I could not find much documentation online here is a description of the steps how to do it.

Let first get a PKI token, you can do it the hard way by sending a json blob to the keystone url and parse the json results like this :

$ curl -s -d '{"auth": {"tenantName": "tenant", "passwordCredentials": {"username": "user", "password": "password"}}}' -H 'Content-type: application/json' http://localhost:5000/v2.0/tokens

or do the easy way by gettting my script available here :

http://p.chmouel.com/ks

and use it like that :

eval $(bash ks -s localhost tenant:user password)

it will give you a variable $TOKEN and a variable $STORAGE_URL that you can use further down.

now let’s try to use it with our swift :

$ curl -i -H "X-Auth-Token: $TOKEN" ${STORAGE_URL}
HTTP/1.1 204 No Content
Content-Length: 0
Accept-Ranges: bytes
X-Timestamp: 1366666887.01151
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
Content-Type: text/html; charset=UTF-8
X-Account-Object-Count: 0
X-Trans-Id: tx5b50dc6d01d04923a40a1486c13dd94d
Date: Mon, 22 Apr 2013 22:01:00 GMT

all good here,

so now go inside your keystone.conf and get your admin/service token or use that friendly copy and paste command line :

$ ADMIN_TOKEN=$(sed -n '/^admin_token/ { s/.*=[ ]*//;p }' /etc/keystone/keystone.conf)

and use it to DELETE the token we do that request directly to our keystone which is localhost here point it wherever you want:

$ curl -X DELETE -i -H "X-Auth-Token: $ADMIN_TOKEN" http://localhost:5000/v2.0/tokens/$TOKEN
HTTP/1.1 204 No Content
Vary: X-Auth-Token
Content-Length: 0
Date: Mon, 22 Apr 2013 22:01:08 GMT

We can still use it because the token is still in the cache. By default tokens are cached in memcache as good as 5 minutes but the
revocation list is fetched every seconds or so.

$ curl -i -H "X-Auth-Token: $TOKEN" ${STORAGE_URL}
204 No Content
Content-Length: 0
Accept-Ranges: bytes
X-Timestamp: 1366666887.01151
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
Content-Type: text/html; charset=UTF-8
X-Account-Object-Count: 0
X-Trans-Id: tx9018045ce1324203a91e882ec6d27ac3
Date: Mon, 22 Apr 2013 22:01:12 GMT

but after a bit (like over a minute or so) we are getting a proper denied:

$ curl -i -H "X-Auth-Token: $TOKEN" ${STORAGE_URL}
HTTP/1.1 401 Unauthorized
Content-Length: 131
Content-Type: text/html; charset=UTF-8
X-Trans-Id: tx9133daf949204f0facf45152a43836bb
Date: Mon, 22 Apr 2013 22:27:23 GMT

>h1<Unauthorized< 

This server could not verify that you are authorized to access the document you requested.

and from the log messages:

proxy-server Token 49d94a8ca068013b6efe79e3463627c8 is marked as having been revoked
proxy-server Token validation failure.#012Traceback (most recent call last):#012  File "/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py", line 689, in _validate_user_token#012    verified = self.verify_signed_token(user_token)#012  File "/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py", line 1045, in verify_signed_token#012    raise InvalidUserToken('Token has been revoked')#012InvalidUserToken: Token has been revoked

[..]
proxy-server Marking token MIIGogYJK...... as unauthorized in memcache

bingo the token has been now revoked properly.

Swift and quotas in upcoming 1.8.0 (Grizzly) release.

There is two new nifty middlewares for doing quotas in upcoming Swift release 1.8.0 called container_quotas and account_quotas.

Those are two different middlewares because they are actually addressing different use cases.

container_quotas is typically used by end users the use case here is to let user to specify a limit on one of their container.

Why would you want to restrict yourself you may ask ? This is because when you allow a public upload to a container for example with tempurl or/and formpost you want to make sure people are not uploading a unlimited amount of datas.

The headers to configure for the container quota are :

X-Container-Meta-Quota-Bytes – The Maximum size of the container, in bytes.
X-Container-Meta-Quota-Count – Maximum object count of the

The account_quotas is more the typical quota implementation. A “super
user” with the reselleradmin group/role can set a byte limit for
an account and the account will not be able to have new
objects/containers until someone cleanups his account to get under the
limited quotas.

The headers to configure the account quotas are :

X-Account-Meta-Quota-Bytes – The Maximum size of the account in bytes.

The commit for the container quotas is here :

Basic container quotas

and account quotas commit :

Account quotas

Enjoy.

 

emacs anything with magit

I have been using quite a bit the anything-mode for Emacs, it’s basically a Quicksilver/Alfred or Gnome-do for Emacs and allow to configure a lot of different sources to complete some chosen ‘source’with different actions.

With my work on OpenStack I have found myself jumping a lot between git directories and due configured the variable ‘magit-repo-dirs for easy access to most of them easily.

Plugging those two just seemed natural I had already this in my emacs to quickly open those magit repository directories :

(global-set-key (read-kbd-macro "C-S-o") '(lambda ()(interactive) (dired (magit-read-top-dir nil))))

But going with anything is much nicer and I can add another action for openning the source to  magit so I quickly came up with this magit source :

so now I open my different OpenStack Swift projects quickly with only a few keyboard touch (I bind my custom anything function to C-z) which shows graphically like this :

anything switch to magit dirs.

as always my full emacs config is available here:

http://github.com/chmouel/emacs-config

Upload to OpenStack Swift via CORS/HTML5 request.

One of our client at eNovance had a need to be able to upload to Swift directly from a web browser without going via a PHP proxy.

Things in browser-land are not exactly the same as what we have in user-land, it is a bit more restricted to ensure the end-user security and there is a few hoops to jump through to get it working.

To be able to do a xmlrpc upload to another server (swift in this case) there is a ‘standard/recommendation’ document made by W3C about it located here :

http://www.w3.org/TR/2013/CR-cors-20130129/

Basically what happen when in Javascript we do :

request.open("POST", "http://swift/AUTH_account/container/");
request.setRequestHeader('X-Auth-Token', myToken);
request.send();

The browser just before the request will send an OPTIONS request to check with the server if the request is allowed by the server. This look like this when uploading to Swift :

Screen Shot 2013-02-01 at 12.29.50

The Options request that the browser does is literally asking for the server (swift) to know if this domain where it’s uploading from is allowed to upload directly via xmlrpc. The request looks like this :

Screen Shot 2013-02-01 at 12.39.50It says, hello there: my Origin: is this IP and I want to be able to access with this method ‘PUT’, can I do it ? The server will reply something along (if it’s allowed), yeah sure please feel free to send this headers along and those methods and Origin are actually what I am allowing.

Thanks to the work of Adrian Smith this is supported since Swift version 1.7.5 (and improved in 1.7.6), you can do  at server level config or with headers on container easily see the full detailled documentation here:

http://docs.openstack.org/developer/swift/cors.html

While working on this I could not find a clear example to test it, I only found a great article on this page :

http://www.ioncannon.net/programming/1539/direct-browser-uploading-amazon-s3-cors-fileapi-xhr2-and-signed-puts/

that was targetted to amazon s3 and I adapted it to use with OpenStack Swift.

You can find it here and use it as an example for your application :

https://github.com/chmouel/cors-swift-example

My running and cycling stats of 2012

And here is another year finishing and I am looking back how did I do with my fitness.

I have not done well with regard to my class A running race, I wasn’t able to make to the Jerusalem marathon due of passport problem of my kid and had to easy my running due of a bad ankle since February, but I still did a 1h32 half marathon by March and a 1h38 in L.A in Septembre, just in time to hit over 1000km by this year :

  Running stats 2012

I have instead did much more cycling finishing a easy sportive in wales of 130km and a pretty hard one in south of france of 160km with a lot of mountains climbed. I made it to 5000Km (for my racing bike not counting my city bike which has around 500km on it) :

Cycling Stats 2012

I would have done much more if I didn’t have a bad upper shine when I was in australia where I was going to do a month of cycling.

This year looks promising with the Madrid Marathon in april (going for around 3h20) and probably some pretty good cycling trips during the summer if shin/ankle get sorted, I am looking forward to 2013.