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
Hello,
I want to discuss if this is possible or if there are any security implications.
Here is my use case:
Very often I need to perform certain API actions that are not available via the provider (eg. not yet implemented) and as a workaround, I use AWS SDK to make the change or resolve the value regardless of the state.
Dynamic providers also need AWS credentials
The problem description
My code needs to follow the same "path" as pulumi providers do and then I have to do the double/tripple work perform the same steps.
Eg.
Say I want to create a dynamic resource calling AWS but in another account that is assumed by role or a different region.
Then in pulumi I can do this.
1. get client with current credentials
2. call sts to assume role
3. create new client with the credentials from 2
Then the code looks something like this for 2 step "hop"
type Constructor<T> = new (...args: any[]) => T;
async function createClient<T>(client: Constructor<T>, region: string, assumeRoleArn: string): Promise<T> {
console.log(`Assuming role '${assumeRoleArn}'`);
const stsClient = new sts.STS({});
const assumedRole = await stsClient.send(
new sts.AssumeRoleCommand({
RoleArn: assumeRoleArn,
RoleSessionName: "pulumi-command",
})
);
return new client({
region,
credentials: {
accessKeyId: assumedRole.Credentials?.AccessKeyId!,
secretAccessKey: assumedRole.Credentials?.SecretAccessKey!,
sessionToken: assumedRole.Credentials?.SessionToken!,
},
});
}
As you can see AWS SDK exposes credentials object making it possible to pass it around. So I do not see any problem if pulumi provider could do the same thing.
This would unlock workflows with dynamic providers and other integrations.
new MyDynamicProvider("name", {awsProvider: pProvider}) //(or pass it through opts)
then inside the code for the dynamic provider could look like:
import * as iam from "@aws-sdk/client-iam";
async create(inputs: ProviderInputs): Promise<pulumi.dynamic.CreateResult> {
const outs: ProviderOutputs = inputs;
const client = new iam.IAM({
region,
credentials: {
accessKeyId: inputs.awsProvider.Credentials?.AccessKeyId!,
secretAccessKey: inputs.awsProvider.Credentials?.SecretAccessKey!,
sessionToken: inputs.awsProvider.Credentials?.SessionToken!,
},
})
return { id: this.name, outs };
}
The text was updated successfully, but these errors were encountered:
Thanks for the suggestion @1oglop1 I think it is an excellent idea. I think it should be in principle possible - the explicit Pulumi provider object could expose a secreted credentials output (or promise), that could then be used in the program to configure the AWS SDK client and continue doing what needs to be done.
It sounds like promise would be more convenient, but having an Output would allow continuing to mark the credentials as secret. Another security consideration here is that temporary auto-expiring credentials may be exposed, so that helps in case they do leak somewhere.
It is good to think of security here but at a glance it does not appear to be something that needs to block the feature, appropriate documentation can explain to users how to utilize this responsibly.
I will get this discussed in our team, in the meanwhile if anyone is seeing this, up-voting the issue helps prioritizing.
Hello,
I want to discuss if this is possible or if there are any security implications.
Here is my use case:
The problem description
My code needs to follow the same "path" as pulumi providers do and then I have to do the double/tripple work perform the same steps.
Eg.
Say I want to create a dynamic resource calling AWS but in another account that is assumed by role or a different region.
Then in pulumi I can do this.
But then with AWS SDK I have to do multiple steps
Then the code looks something like this for 2 step "hop"
As you can see AWS SDK exposes
credentials
object making it possible to pass it around. So I do not see any problem if pulumi provider could do the same thing.This would unlock workflows with dynamic providers and other integrations.
then inside the code for the dynamic provider could look like:
The text was updated successfully, but these errors were encountered: