iam_role is ignored for dependencies #1262
Comments
|
Hi @Spaideri, there are a few things going on here, so let me comment on them individually.
I was the one that originally wrote that piece of code. The goal was to support using Correct me if I'm wrong, but based upon what you've posted, I'd expect the expected behavior in your case to be NOTHING deploys because your user is unable to assume the iam role. What I'm currently thinking the fix should be: Right now, the fallback happens when the ConnectionManager is obtained. However, what I'm thinking we should instead is tool out that fallback in ONLY the
|
|
@Spaideri, thanks so much for reporting this bug. It's a bit of an obscure edge-case and I'm still not positive what is actually causing this other-case fallback in your stack configuration, but I think it needs to be fixed. First, in order to prove my hypothesis, could you do me a favor and try out deploying but replace the Second, how would you like to contribute toward a fix? I'd be happy to help guide you/coach you in the process. There's a good community of Sceptre devs and I've found we're quite welcoming! (I only started up about a year and a half ago). |
|
Hi, and thanks for prompt reply! You are right to expect that nothing should be deployed if the specified I tested with hard coded Full config files below. I've simplified them a bit by removing some jinja2 imports and custom resolvers, but these are the actual versions I've reproduced the error with route53-private-hosted-zone.yaml "Stack B" iam-infra-roles.yaml "Stack A" Regarding contributing, python is the weakest language in my tool box and I feel like I'm not able to produce added value at this time :( |
|
I think it actually worked when you hard-coded. I believe AWS doesn't bother checking permissions when you attempt to deploy a stack with no changes. It Just says "no changes to be made" and doesn't blow up. That appears to be what actually happened. If I'm right, you it should block any changes to the stack. If you modify the stack template for your hosted zone and try to deploy, it SHOULD blow up without making any changes. (Do something non-destructive in case it's your prod thing. Like add a character to the template "Description" or something.
That's fine. I'll see what I can do when I get bored over the coming holiday ; ). |
|
Hi, I tried again with the hard coded Launch with hard coded iam role, I updated private hosted zone stack tags to trigger changes Launching the private hosted zone stack directly Hope you have a very very relaxing holiday! :) |
|
Huh. Well that isn't the result is was hoping for. I'll need to investigate. I still think there's some sort of catching going on. |
|
Hey @Spaideri, using the hard-coded iam_roles (not resolvers for them), can you run the launch using the |
|
Hi! Weird thing is that running with --debug the execution fails before the depending stack is launched. I removed some noise from the beginning of output sceptre --debug launch dev/eu-west-1/infra/iam-infra-roles.yaml -y Without --debug the result is as before sceptre launch dev/eu-west-1/infra/iam-infra-roles.yaml -y |
|
Thanks for posting those logs. I'm currently trying to figure out the source of this bug. Every time I think I've figured it out, I realize I'm mistaken and that's not a bug. I really wish I could just step through your specific deployment and see what's causing the issue. I don't really have an identical situation where I have an iam role that my environment's user CAN assume but my deployment role cannot assume. That's making it a bit difficult for me to diagnose. The areas of code I keep coming back around to have to do with:
The problem is that the call-stack gets rather deep (with some recursion) and there are a few levels of caching that might be causing the problem. In any case, I'm really struggling to find the problem piece of code. I might have to try to set up an arbitrary, new example similar to yours to see if I can simulate it, if I can. But I'm not sure I could. Alternatively, if you'd be willing to find a time for us to meet over a google meet or zoom or something, if I could guide you on how to set break points to debug the process, I could "look over your shoulder" and help diagnose this issue by see the actual code path followed. Would you be willing to find some time to do that some time next week? |
|
Hi! I work as a consultant for a +billion enterprise so I need to check if I can share anything from the real environment :( What I can do right now is to share you the IAM Role I'm using as |
|
It might take me a week or two to get to this. I'm very interested in figuring out what the issue is here, though. It seems a rather elusive bug that probably has to do with caching at some level. |
iam_role resolver is ignored for the stack refrenced with !stack_output resolver
iam_roledefined.iam_roledefined for stack B the it is launched using the current credentials, after stack B launch is complete stack A is executed with the specifiediam_rolefor the stack A as expectediam_rolefor A and B and my current user is not authorized to assume that role, but I'm still able to launch the transient stack B by launching stack AYour environment
Steps to reproduce
Note current user is not allowed to assume the IacInfraDeployRoleArn role
stack B
stack A
Output launching stack A
Output launching stack B directly
Expected behaviour
Stack dependencies defined throug the !stack_output resolver should be executed with the
iam_roledefined for the stackActual behaviour
Dependency stacks through !stack_output are executed with the current users credentials instead of assuming the
iam_roledefined for the dependency stackThe text was updated successfully, but these errors were encountered: