https://pulumi.com logo
#aws
Title
# aws
b

breezy-butcher-78604

02/20/2024, 7:17 AM
hey friends, i'm having trouble getting Pulumi to pick up and use my AWS credentials that were generated from AWS SSO my stack config
Copy code
config:
  aws:region: eu-west-1
  aws:profile: pulumi
my AWS CLI config:
Copy code
[sso-session sso]
sso_start_url = https://<REDACTED>.<http://awsapps.com/start#|awsapps.com/start#>
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile pulumi]
sso_session = sso
sso_account_id = <REDACTED>
sso_role_name = <REDACTED>
region = eu-west-1
output = json
i can use the AWS CLI just fine:
Copy code
aws sts get-caller-identity --profile pulumi
{
    "UserId": "<REDACTED>",
    "Account": "<REDACTED>",
    "Arn": "arn:aws:sts::<REDACTED>:assumed-role/AWSReservedSSO_<REDACTED>"
}
but when running
pulumi up
or anything that needs to talk to the cloud provider i get the following error message:
Copy code
error: unable to discover AWS AccessKeyID and/or SecretAccessKey - see <https://pulumi.io/install/aws.html> for details on configuration
i've also tried running
AWS_PROFILE=pulumi pulumi up
with the same result. any ideas?
this is a typescript project and here are the versions of the providers i'm using FYI
Copy code
"@pulumi/aws": "^6.22.0",
        "@pulumi/pulumi": "^3.105.0",
s

steep-sunset-89396

02/20/2024, 10:13 AM
I'm curious @breezy-butcher-78604 what happens if you use the
default
profile? Here is my
~/.aws/config
which us slightly different than yours...
Copy code
[default]
sso_region = us-west-2
sso_start_url = <https://d>-<REDACTED>.<http://awsapps.com/start|awsapps.com/start>
sso_account_id = 123412341234
sso_role_name = AdministratorAccess
region = ap-southeast-2
output = json
And then I login using this command
aws sso login --no-browser
.
l

little-cartoon-10569

02/20/2024, 7:43 PM
You shouldn't use any profile when creating an aws.Provider with the intention of using the SSO details. Just let Pulumi figure it out.
b

breezy-butcher-78604

02/21/2024, 2:04 AM
same error even when configuring the default profile as you have @steep-sunset-89396
You shouldn't use any profile when creating an aws.Provider with the intention of using the SSO details. Just let Pulumi figure it out.
i have a bunch of different profiles set up so I imagine i'd need to provide some kind of hint on which one to use right?
s

steep-sunset-89396

02/21/2024, 2:20 AM
I'm assuming you opened the SSO sessions, right? (I made that mistake once🤦‍♂️ and I was loosing my marbles)
b

breezy-butcher-78604

02/21/2024, 2:21 AM
yeah theres definitely valid creds/session since I can use the aws CLI without issue
s

steep-sunset-89396

02/21/2024, 2:22 AM
Let me break my env and get back to you.
b

breezy-butcher-78604

02/21/2024, 2:26 AM
are there any debug switches/config i can add to get some more information on how the provider is trying to find creds?
s

steep-sunset-89396

02/21/2024, 2:28 AM
--verbose=11 --logtostderr
is the combo to use first.
l

little-cartoon-10569

02/21/2024, 2:32 AM
When you're creating the provider, pass no parameters (other than region). If you're using the default provider (which I recommend you don't do), then ensure that AWS_PROFILE, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are all unset.
Then log into SSO and it should work.
If you set a profile, then it has to be one that sets sso_session to the value of the sso-session that you've logged into.
Luke's config file snippet from above is current. Aurelien's is the old style, now deprecated.
If you run
AWS_PROFILE=pulumi pulumi up
and you have AWS_ACCESS_KEY_ID set, then AWS_ACCESS_KEY_ID will take precendence. If you don't have AWS_SECRET_ACCESS_KEY set, then you'll see that error message (I think).
b

breezy-butcher-78604

02/21/2024, 2:40 AM
yeah definitely confirmed there's no other
AWS_*
variables set
only
AWS_PROFILE
l

little-cartoon-10569

02/21/2024, 2:42 AM
Then it should work. Anything else I come up with here will be pure guesswork 🙂 The region you use in your sso-session block should be the region that your IAM Identity Centre created the SSO IdP or external IdP connection in. Not the region that your profile uses.
b

breezy-butcher-78604

02/21/2024, 2:47 AM
yep, makes sense, have confirmed that also
l

little-cartoon-10569

02/21/2024, 2:50 AM
Are you creating an aws.Provider instance? Or maybe more than one? Or are you using only the default aws.Provider?
b

breezy-butcher-78604

02/21/2024, 2:51 AM
just the default. its a very simple project with a few resources in it.
l

little-cartoon-10569

02/21/2024, 2:52 AM
Try manually creating an aws.Provider with just the region and profile parameters set, and pass that to all the resoruces.
If that works, then there must be something getting in the way of your default provider. Maybe you've aliased
pulumi
to something that sets some env vars.
b

breezy-butcher-78604

02/21/2024, 2:53 AM
i'll give it a go
s

steep-sunset-89396

02/21/2024, 2:58 AM
@breezy-butcher-78604 ok, so your setup seems to be working for me. The
default
fails on
p up
because it's not auth'ed and adding a
aws:profile: pulumi
works fine. No need to create any extra provider either.
b

breezy-butcher-78604

02/21/2024, 2:58 AM
using a non-default provider is causing the same error for me
i'm going to try creating a brand new project with the same profiles and see if its something wacky with this particular project/stack
@steep-sunset-89396 figured it out. i'll let him explain what we did
s

steep-sunset-89396

02/21/2024, 3:20 AM
For those in that situation... It's because the stack state holds an existing provider which contains the aws profile. running
pulumi up --target 'provider url'
and setting the desired
aws:profile: profileName
beforehand should solve the situation. This was visible when exporting the stack state via
pulumi stack export
. Thanks to @breezy-butcher-78604 for his tests as well.
l

little-cartoon-10569

02/21/2024, 3:20 AM
Ah, the old provider-in-the-state trick.
b

breezy-butcher-78604

02/21/2024, 3:21 AM
i didn't have to add a profile to state or anything, in my case just doing a targeted
pulumi up
on the provider (after updating provider versions locally) fixed the issue
it might be a weird issue jumping from 4.x.x of the provider straight to 6.x.x
but yeah, basically doing a
pulumi up
on the provider only fixed everything. thanks for the help
2 Views