Is it possible to get obtain the credentials (and/or profile, region, anything else that the provider has resolved as required to communicate with aws) used by the aws provider to pass it to aws-sdk, so you can do additional work in the same context? I understand that an instantiated aws-sdk used to be accessible from the aws package but that was removed at some point. I'm attempting to make a dynamic resource provider that properly ties in to Pulumi's inheritance and works as a 'drop-in' resource in a way where it shouldn't matter if the user is explicitly defining an AWS provider or if it's using the default one. I'm able to sort-of circumvent it by doing my own lookups into the users environment and using

new pulumi.Config('aws')

etc. but there are many cases where this will return different credentials to the ones actually in use by the AWS provider, so I'm not able to provide a particularly robust integration with how the rest of pulumi works.

No. You can pass the same details to your project via "normal" config, and us it for both the SDK and the Pulumi provider. But for security reasons, you cannot get those secrets out of the provider once it is instantiated.

While that makes sense, it is pretty unfortunate

can't you use

const x = someComponent.getProvider("aws::") as aws.Provider;

this contains the provider config, it only works for getting the config you have passed in as explicit provider however, if it's using default aws provider it will be undefined so you would just need to handle that scenario and fetch the default config.

I've been asking the same question for ages and the current desing is indeed really painful to work with to the point it is almost losing the benefit of dynamic providers. Because one has to reapeat the same auth operations that pulumi provider had done already.

That's security for you.

I can't think of a 'nice' workaround for it either. Looking up the env vars and such is fine for simple usecases, but lets be honest if you're defining dynamic providers, you're already past the simple usecases. I guess you can sorta call sts.getCallerIdentity and then try to find the equivalent in the users defined profiles but even that doesn't cover some usecases because there's about 8 billion different routes to auth with aws and the aws provider could be using any of them, including temporary creds

You should define your own config section on your attack or project yaml file, and define the necessary values, exactly as if you were going to create an explicitly AWS provider. Then construct two providers from the same values: the AWS one and your dynamic one.

OT: @little-cartoon-10569 do you have any links explaining the security reasons, I am unable to come up with my own justifications.

No, but consider: external packages / plugins can accept providers (e.g. you have something like the EKS or AWSX library, and you can pass an AWS provider object into it so it can deploy things). If the secrets could be taken out of a provider object, then Somebody Else's Code could do it. And that means they're not secrets any more. The code could, if cleverly obfuscated, deposit your secrets into their vaults. And voila, you're now paying for their bitcoin mining.