heat_keystoneclient ec2 user fix

Fix bug where we incorrectly use the request context user_id,
instead of the user_id associated with the resource calling
get_ec2_keypair()

fixes bug 1089035

Change-Id: Ibb5e6d11461fb3ff1dd743066a9f7de3ee65b445
Signed-off-by: Steven Hardy <shardy@redhat.com>

diff --git a/heat/common/heat_keystoneclient.py b/heat/common/heat_keystoneclient.py
index 02aaa3bb04f63abd440975cea65cb5fc4c2def92..43083caae56d5a70c8aa7464bced6c6d09404a9c 100644 (file)
--- a/heat/common/heat_keystoneclient.py
+++ b/heat/common/heat_keystoneclient.py
@@ -125,21 +125,11 @@ class KeystoneClient(object):
         self.client.ec2.delete(user_id, accesskey)
 
     def get_ec2_keypair(self, user_id):
-        # Here we use the user_id of the user context of the request.  We need
-        # to avoid using users.list because it needs keystone admin role, and
-        # we want to allow an instance user to retrieve data about itself:
-        # - Users without admin role cannot create or delete, but they
-        #   can see their own secret key (but nobody elses)
-        # - Users with admin role can create/delete and view the
-        #   private keys of all users in their tenant
-        # This will allow "instance users" to retrieve resource
-        # metadata but not manipulate user resources in any other way
-        user_id = self.client.auth_user_id
-        cred = self.client.ec2.list(user_id)
         # We make the assumption that each user will only have one
         # ec2 keypair, it's not clear if AWS allow multiple AccessKey resources
         # to be associated with a single User resource, but for simplicity
         # we assume that here for now
+        cred = self.client.ec2.list(user_id)
         if len(cred) == 0:
             return self.client.ec2.create(user_id, self.context.tenant_id)
         if len(cred) == 1: