Bug 970134 - Support v4 signature format in keystoneclient Ec2Signer
Support v4 signature format in keystoneclient Ec2Signer
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-keystoneclient (Show other bugs)
unspecified
Unspecified Unspecified
high Severity high
: rc
: 3.0
Assigned To: Jakub Ruzicka
Pavel Sedlák
:
Depends On:
Blocks: 968247 970308 1000540
  Show dependency treegraph
 
Reported: 2013-06-03 10:02 EDT by Steven Hardy
Modified: 2016-04-27 01:24 EDT (History)
6 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-27 12:50:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steven Hardy 2013-06-03 10:02:21 EDT
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 14:25:44 EDT
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 04:33:23 EDT
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 12:50:41 EDT
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.