Does not assume role correctly when use salt-cloud to create AWS ec2

[huxiaobabaer]

Description of Issue/Question

When i try to use salt-cloud to create AWS ec2, it does not assume role correctly

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)
My purpose is using salt-cloud ec2 in account 22222222 to create AWS ec2 in account 11111111

• Create role alt-cloud-cross-account in AWS account 11111111 with trust entities = aws account 22222222

• Attached Full EC2Acess policy to role salt-clou1d-cross-account

• Create ec2 in AWS account 22222222 and install salt cloud version 2019.2

• Create ec2 role with policy allow it to assume 11111111:role/salt-cloud-cross-account

• Config prodiver file:
  xxxxx-xxxxx-xxxx:
  id: 'use-instance-role-credentials'
  key: 'use-instance-role-credentials'
  role_arn: 'arn:aws:iam::11111111:role/salt-cloud-cross-account'
  driver: ec2

• config provider fine

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

Run salt-cloud -m test-map-file

From cloudTrail, i can see

• an api call DescrbeInstance in account 11111111. No instance found.
• an api call RunInstance in account 11111111. EC2 created in account 11111111
• seven an api call DescrbeInstance in account 22222222
  return 400, Bad request, an instance with instance id xxx not found
  Salt-Cloud error out

According to cloudTrail, I believe it assumes the role as expected when creating ec2, but after then when it queries the result of the creation, it does not assume role correctly. As it considers ec2 is not created, exit without finishing other following tasks like tag ec2, ssh ec2, install/config/start salt minion

Is it a bug of cloud-salt??

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
2019.2

[Ch3LL]

ping @saltstack/team-cloud any ideas here?

[gtmanfred]

I do not believe we have any code in place for assuming roles. This would require the feature to be added.

[gtmanfred]

Oh, looks like it actually should be assuming the role_arn. I don't know. probably a bug.

[huxiaobabaer]

Could you please reproduce it on your end and confirm if it is a bug?
Thanks

[changyong]

Hi, I checked the codes and found the problem. When the variable __Expiration__ isn't equal to '' , it will always return from the function directly, then it won't have chance to execute provider.get('role_arn') to get credential from assume role again.

[nnsense]

@Ch3LL Hi, I'm facing exactly the same issue while trying to create an instance (it doesn't find the security group and fails) and while destroying an instance (it cannot find the instance and fails).
Both commands can initially find the object but on the second call they fail.
Is there a patch I can apply myself? Any ETA for the fix to be implemented? Managing an infrastructure using hardcoded keys is not ideal, besides security concerns we're required to create API keys on every account. Thank you!

[nnsense]

Thanks to @changyong comment I've sorted it by changing

if __Expiration__ != '':

into

if __Expiration__ == '':

in utils/aws.py, it works now. I don't mind fetching credential again.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[major0]

I think this was closed prematurely. The bug still exists and the fix from #52572 was never merged in.

[major0]

Thanks to @changyong comment I've sorted it by changing

if __Expiration__ != '':

into

if __Expiration__ == '':

in utils/aws.py, it works now. I don't mind fetching credential again.

This was a fairly useful stop-gap to work around this particular bug.