Assume iam_role BEFORE resolving parameters

Question

Assume iam_role BEFORE resolving parameters

SpyderDave opened this issue 2 years ago · 1 comments

iam_role seems to be assumed after resolvers?

I use an iam_role in StackGroup Config to assume a cross account role. In my parameters, I frequently use !ssm resolver. In the past, I would assume the role manually (using AWS CLI) before running sceptre in order to allow the !ssm resolution to work (the parameters to resolve are in the account that the assumed role resides) Although I can continue doing this, it makes it impossible to use the iam_role_session_duration configuration due to session chaining limits in AWS (60 mins hard limit).

environment

sceptre 3.2.0
3.7
Amzn2

Not sure what a good workaround would be for this as I would like to increase the session limit.

Answer 1 · 2023-01-12T15:52:27.000Z

Hi @SpyderDave! I just took a look into this and it appears to actually be an issue in the SSM Resolver's code and how it interacts with Sceptre's connection manager.

Here is where it calls SSM to resolve: https://github.com/Sceptre/sceptre-ssm-resolver/blob/master/resolver/ssm.py#L60 and here is where those parameters come from: https://github.com/Sceptre/sceptre-ssm-resolver/blob/master/resolver/ssm.py#L60. Notice how it explicitly passes a region and a profile, but it ignores the iam_role completely.
If you look at the ConnectionManager here: https://github.com/Sceptre/sceptre/blob/master/sceptre/connection_manager.py#L259, if you explicitly pass a region or profile or iam_role that isn't None into call, it will actually use ALL THREE of those explicit values, even if some of them are None and even if that overrides what is already set on the ConnectionManager instance.

Ok, so if you're following me, this really means two things:

The ConnectionManager is a bit tricky to use... I have a PR open to improve things (#1287) but I don't think it'll actually solve this particular "trickiness". I'll have to look into that bit.
The real problem you're encountering isn't with Sceptre itself but with that resolver. Sceptre resolves things as expected, but the SSM resolver is explicitly ignoring the existence of the IAM role.

So, with all that said, I'm going to close this issue, since it's not really an issue with Sceptre proper.

However: you can do a few things

You should probably put an issue on the SSM resolver that expresses your issue.
I would absolutely welcome the fix on the resolver from you. I'd be very happy to work with you on resolving it, since it looks like it could be fixed in a few lines.
If you wanted to open a new issue for Sceptre pertaining to the default behavior of ConnectionManager.call, I think it would be good to have a conversation about how that method works right now, why it works the way it does, ways it could be improved, etc...