Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 970134 - Support v4 signature format in keystoneclient Ec2Signer
Summary: Support v4 signature format in keystoneclient Ec2Signer
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-keystoneclient
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 3.0
Assignee: Jakub Ruzicka
QA Contact: Pavel Sedlák
Depends On:
Blocks: 968247 970308 1000540
TreeView+ depends on / blocked
Reported: 2013-06-03 14:02 UTC by Steven Hardy
Modified: 2016-04-27 05:24 UTC (History)
6 users (show)

Fixed In Version: python-keystoneclient-0.2.3-3.el6ost
Doc Type: Bug Fix
Doc Text:
Cause: Recent python-boto (>= 2.6.0) uses AWS v4 signatures by default which are not supported by keystoneclient. Consequence: Signature validation fails when using recent python-boto. Fix: Add support for v4 signature verification to keystoneclient. Result: Signature validation succeeds with recent python-boto.
Clone Of:
Last Closed: 2013-06-27 16:50:41 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0992 0 normal SHIPPED_LIVE Important: python-keystoneclient security, bug fix, and enhancement update 2013-06-27 20:44:09 UTC

Description Steven Hardy 2013-06-03 14:02:21 UTC
Description of problem:
Require backport of keystoneclient support for v4 signatures, which is a blocker to updating python-boto (bz968247) as it now uses the v4 signature format by default.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Try using latest-trunk boto against an AWS-compatible openstack service, e.g the Heat CFN API

Actual results:
Signature validation will fail

Expected results:
Signature validation succeeds

Additional info:
Upstream patch/commit:


Comment 3 Steven Hardy 2013-06-03 18:25:44 UTC
Some further info on one way to verify this, using upstream heat which now depends on this patch to allow ec2 style authentication with the heat-api-cfn service:

1 - clone upstream heat (https://github.com/openstack/heat)
2 - Install via install.sh
3 - Modify /etc/heat/heat-api-cfn.conf keystone_ec2_uri to point at keystone if not running on localhost
4 - run heat-api-cfn -d && tail -f /var/log/heat/api-cfn.log
5 - create an ec2 keypair via keystone ec2-credentials-create
6 - Install recent (>= 2.6.0 python boto, or latest upstream trunk (https://github.com/boto/boto)
7 - Create a boto config as described in https://wiki.openstack.org/wiki/Heat/Using-Boto
8 - Run the command "heat-boto --debug list"

This command won't work because you're not running the heat-engine service, but you should see the following in the api-cfn.log:

INFO heat.api.aws.ec2token [-] AWS authentication successful.

This proves that we were able to pass the (v4 formatted) request to keystone, and have it validated by the v4 capable keystoneclient Ec2Signer as in this patch.

There are several other, more minimal approaches, but in order to avoid actually using the code in the patch (to calculate the signature), this is probably the quickest and most well proven reproducer, since this was the exact use-case which prompted the upstream patch.

Comment 7 Steven Hardy 2013-06-04 08:33:23 UTC
Note, I've now tested the following boto versions with this patch:

- 2.5.2 (v2 Signatures)
- 2.6.0 (F18 package, v4 signatures
- 2.9.0 (pip install from pypi, v4 signatures)

These all work fine.  Unfortunately the latest package in pypi (2.9.5) doesn't seem to work, so disregard my latest-trunk comment in the validation instructions above, we may have another format tweak to deal with for the latest boto-goalposts-move..

Since 2.6.0 is in F18 and seems a likely candidate for EL6 update, this seems to be the best candidate version for validation purposes, we can deal with the 2.9.5 issue later via a separate bug (after I've fixed it upstream)

Comment 18 errata-xmlrpc 2013-06-27 16:50:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.