Hide Forgot
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.
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
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.
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)
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