Bug 970134

Summary: Support v4 signature format in keystoneclient Ec2Signer
Product: Red Hat OpenStack Reporter: Steven Hardy <shardy>
Component: python-keystoneclientAssignee: Jakub Ruzicka <jruzicka>
Status: CLOSED ERRATA QA Contact: Pavel Sedlák <psedlak>
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: apevec, ayoung, bperkins, jruzicka, pbrady, ykaul
Target Milestone: rc   
Target Release: 3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 16:50:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 968247, 970308, 1000540    

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