Bug 970134 - Support v4 signature format in keystoneclient Ec2Signer
Summary: Support v4 signature format in keystoneclient Ec2Signer
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-keystoneclient
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 3.0
Assignee: Jakub Ruzicka
QA Contact: Pavel Sedlák
URL:
Whiteboard:
Keywords:
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)

(edit)
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:
(edit)
Last Closed: 2013-06-27 16:50:41 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0992 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:
Always

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:
https://review.openstack.org/#/c/26013/

https://github.com/openstack/python-keystoneclient/commit/5c37d85944d9eed73ec6dd6254842108386bcc4f

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.

http://rhn.redhat.com/errata/RHSA-2013-0992.html


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