https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# aws
s
This message was deleted.
m
I don’t think I quite understand, but there shouldn’t be any caching of AWS credentials anywhere; the AWS provider reads these at runtime in one of several ways as described here: https://www.pulumi.com/registry/packages/aws-native/installation-configuration/#get-your-credentials
It might be easier to help if you could describe what “action” you want to perform and what behavior you’re seeing.
f
In my Pulumi configuration I add
Copy code
aws:assumeRole:
    roleArn: arn:aws:iam::rest-of-role-arn
    sessionName: infra-deploy-session-staging
and it correctly assumes the role when deploying. But if I remove it, it continues to assume the role on subsequent deploys.
My AWS CLI profile is not set up to assume the role automatically and if I deploy another stack that does not have 
aws:assumeRole
set it deploys as my IAM user without assuming any role as expected.
m
Are you working with multiple stacks?
Like for the same project I mean.
f
Yes but I'm not mistakenly deploying the wrong one
This is the only one configured to assume the role in question
m
Ok cool, thanks — yeah just wanted to rule that out first.
👍 1
I haven’t actually used this 
assumeRole
option myself, so I’ll have to poke a bit also. You’re right that this does seem odd though. Which backend are you using?
Pulumi Service, self-managed somehow..?
f
Pulumi Service
Also if I change the assumed role ARN to a different one it tries to assume the new one, so it's just removing it that it doesn't seem to notice
m
Also helpful, ok thanks. I’ll try this as well and see what I can find out.
f
Also I just discovered that if I change it to role B and it fails, then I remove the config for role B, it goes back to trying to assume role A (the last one it succeeded with?)
m
Yeah, I suspect if you log into the Pulumi Service after you do that (try with role B and get a failure) and inspect the config for your stack, you’ll see that role A is still the configured one.
f
Interestingly enough, it isn't
m
It doesn’t look like I can reproduce this locally — at least not with the 
aws
provider version 5.x. Which version are you using?
And I guess it’s worth asking which Pulumi version you’re using also, and whether you’re running something like 
--refresh
as part of the update would be good to know, too.
f
Copy code
@pulumi/pulumi@npm:3.53.1
@pulumi/aws@npm:5.28.0
CLI v3.53.1
👍 1
m
And you’re 100% certain you aren’t felling back to some role arn in an AWS config file/profile?
f
None of my profiles are configured to assume a role
m
Yeah, the only way I can reproduce this in the way you’re describing is with a role configured in an AWS profilem which Pulumi will fall back to when there isn’t configuration applied at the stack or project level. Commenting the 
assumeRole
block immediately stops using it when I run 
pulumi up
and then falls back to the role I’ve configured at 
~/.aws/credentials
for example.
One more question worth asking: how is it you’re determining Pulumi is doing (or will do) the wrong thing (falling back to this previously set role)?
are you calling 
getCallerIdentity
in code somehow, or?
f
I'm running an update and it is telling me the role isn't permitted to perform an action
m
And the error is quoting the “bad” role ARN back to you?
f
Error deleting IAM role policy api-task-####:policy-name-####: AccessDenied: User: arn:aws:sts::####:assumed-role/the-role-in-question is not authorized to perform: iam:DeleteRolePolicy on resource: role api-task-#### because no identity-based policy allows the iam:DeleteRolePolicy action
m
Ok thanks. So the preview succeeds but the update fails?
Sorry for all the questions btw! Thanks for patience.
👍 1
f
Yes
m
Ok. Are you in a position where you could drop this into your program to see if it returns the same role ARN?
Copy code
aws.getCallerIdentity().then(identity => console.log(identity.arn));
Curious whether that shows a different ARN when you comment out the 
assumeRole
block in your stack config.
f
Interestingly it logs my identity, not the role
Perhaps it is due to it deleting a resource and it's holding onto the identity that created it?
m
Ok, that’s what I see, too. Getting somewhere!
So we know it’s not Pulumi per se, but somewhere the ARN is being used, probably from within state somehow. I might look next at your resources and properties and see if that role ARN is anywhere to be found among them.
Since you’re using the Service, you might be able to find that out on the Resources tab.
f
I exported the state file and searched through it earlier and found no mention of the role ARN
m
Hrm.
And I think you said that when you specify a different 
roleArn
in your stack config, the 
AccessDenied
error you get back quotes that ARN and not the original one. Right?
f
Actually it fails in the preview step since the other role didn't have permission to view some stuff
Oh also when I deploy other stacks that have no 
assumeRole
they deploy with my user, not the role
So it's just this stack, not my AWS CLI config
👍 1
m
Random thing I’d probably try just to see if it makes a difference — 
pulumi refresh
with the 
assumeRole
bit commented out again.
f
Ok well refreshing actually revealed that the role in question had been deleted before and now it succeeded, although I'm not sure why the issue happened in the first place
m
Oh!
f
I'm also not certain that fixed it, it's just not trying to do the action that it didn't have permission for
m
That is interesting, ok.
Yeah, I don’t understand what was happening there either. Curious to know whether that does free you up though.
f
Yes I'm set for now, thanks
Hopefully next time this happens refreshing will fix it
m
Awesome, that’s great to hear
Yes, I don’t love that I don’t fully understand what happened there, but glad you’re unblocked.
👍 1
7 Views
Open in Slack
PreviousNext
Powered by