https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# aws
s
This message was deleted.
b
you can’t really do it if you define an explicit provider, you need to fall back to ambient credentials and let the AWS SDK figure it out via the credential chain
l
I need multiple providers in the same code. I have projects that deploy to two accounts.
I'm happy to rely on the ambient credentials, I just need to assume roles in each account that the ambient credentials are allowed assume. And the ambient credentials ought to support both SSO and OIDC.
b
that’s gonna be really hard, sadly. You might need to define env vars that are set before each instantiation of the provider
l
My plan has been to create roles in all target accounts that trust the OIDC and SSO "ambient" roles. Then I can construct something like
Copy code
const acct1 = new aws.Provider("acct1", { assumeRole: { myWellknownRoleArn ...
That should work with OIDC, because I create the OIDC role and can add the right policy to get it to trust across accounts. The SSO role won't work though, because I can't modify the role 😞 I need to assume twice from SSO; once to a role in the same account, that I can modify; and once to the role in the target account.
I think it's time to abandon SSO for this. If I stick to only OIDC, and required Pulumi ESC, I guess I'd be ok? Then the only risk would be that Pulumi ESC would stop working for my legacy Team account, after it leaves preview...
b
what are you using OIDC for?
l
Originally I was planning to switch to Pulumi Deployments but that doesn't support my Pulumi org. Now I'm working with Pulumi ESC.
b
for human user access?
or for machine access?
l
Originally, no, for CI access. But now it's looking like a way around my SSO problem, so I'm considering it for all access.
b
you should really be able to craft a role you can assume in destination account from SSO, human user access should really be done via SSO. Any machjine based access can be done via OIDC. I have a bunch of clients that operate this way, the destination role assumption definitelty works
I personally would not depend on Pulumi ESC for human user authentication at all, it’s not the right model. It breaks a whole bunch of things, such as cloudtrail auditability for anyone accessing the role given to ESC.
(I did surface these concerns internally before I departed Pulumi, fwiw)
l
The problem with SSO is: • You can't have two SSO sessions at the same time, even with multiple profiles, and • You can't modify the IAM Identity Center's SSO role to trust a role in a different account. The only way around that would be to have a role-assumption chain for SSO. It wouldn't be needed for OIDC, but I guess it could be there anyway, just to make the code simpler.
Hmm. I might be able to do it via PermissionSet. I just need two PermissionSets, one to set up roles and one to set up users. Which means my chain of Pulumi projects to set up accounts so that Pulumi projects can deploy to them gets pretty unwieldy. I think I need three pre-project projects, run in a specific order. There's a really good case here for doing it by hand 🙂
Hmm again. This seems to be getting easier. I had assuming that this help text, from 
aws sso login help
, was correct:
Please note that only one login
session can be active for a given SSO Session and creating multiple
profiles does not allow for multiple users to be authenticated against
the same SSO Session.
However, I've used 
aws --profile acct1 sso login
followed by 
aws --profile acct2 sso login
, then created aws.Provider instances using those two profiles, and it's working fine (so far).
Which will eliminate all my problems, I think. I just need a switch statement in the chunk of code that creates my providers, and have different branches for SSO and OIDC.
I guess Pulumi is smarter than the shell/environment, and handles multiple SSO sessions nicely 🙂
Oh it's even easier. Because I'm using the same 
[sso-session xyz]
section in both profiles, I'm actually only logged in once, with two profiles getting different keys. It just works, even via the AWS cli and shells, etc.
☝️ 1
Open in Slack
PreviousNext
Powered by