You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So in this case it might be worth documenting how the effects the underlining providers as well. I don't think it's an uncommon thing to want to target another role in another account via a provider in code. But I'd expect by declaring a provider saying "you must be this role" and magically bypassing seems pretty dangerous. Bearing in mind the underlying profile could be a completely different set of credentials. I'd either want a hard failure telling me this can have unexpected outcomes, or for it to always use the role I declare(whether it be by profile name or roleArn)
The reasoning is when you shift a set of code from say your laptop (configured with AWS creds) to CI (likely env vars set) the behaviour can have considerably different outcomes.
We have removed the code that stores the PROFILE in the stack as that was found to have bad consequences for teams using a profile that related to different credentials :)
So in this case it might be worth documenting how the effects the underlining providers as well. I don't think it's an uncommon thing to want to target another role in another account via a provider in code. But I'd expect by declaring a provider saying "you must be this role" and magically bypassing seems pretty dangerous. Bearing in mind the underlying profile could be a completely different set of credentials. I'd either want a hard failure telling me this can have unexpected outcomes, or for it to always use the role I declare(whether it be by profile name or roleArn)
The reasoning is when you shift a set of code from say your laptop (configured with AWS creds) to CI (likely env vars set) the behaviour can have considerably different outcomes.
Originally posted by @zoltrain in #952 (comment)
The text was updated successfully, but these errors were encountered: