https://pulumi.com
Join Slack
What does it mean "our program has to run"? What is this "program"? <https://www.pulumi.com/blog/imp...
# general
b
What does it mean "our program has to run"? What is this "program"? https://www.pulumi.com/blog/improved-refresh-destroy-experience/
l
index.ts, main.py, etc. Your code.
e
same thing 
up
runs
b
I'm very confused then.
You are essentially saying that 
pulumi refresh
was completely useless before this 
--run-program
flag was added.
If 
pulumi refresh
cannot fetch credentials, then it will always fails, then what was the purpose of the command when it was introduced?
e
Most providers didn't need refreshed credentials on every run, they could use the creds last used that were saved in state
b
Credentials are saved in state?
e
Sometimes
b
In the case of AWS?
e
Depends on the provider and how it was configured
b
If I understood the article correctly, before this new flag was introduced, you could create an S3 bucket, do some changes that would cause a config drift, then run 
pulumi refresh
and it would always fail.
e
Depended on your config, if you had long lasting access keys they'd be saved in state and would still work on the refresh
If you had short lived access tokens then yes it would fail
b
That's bad practice. You would use always short-lived tokens with tools like granted.
I see, so before this change it was effectively impossible to use 
pulumi refresh
with AWS.
Or actually, it was still possible as long as you are the one generating the creds I think?
e
I think env var creds were a workaround, but I'm not 100% sure about all the details here.
b
Because if I use an external tool like granted, that generates credentials valid for 12h using 
assume -x
I think Pulumi would still try to use AWS default credentials provider chain
So read from the env variables, then 
~/.aws/config
etc
e
yeh, if your config was such that the thing saved to state was just something like "use profile X from aws/config" then the actual access keys could be reloaded by the provider
b
Ok so basically this new feature you added is basically to allow the pulumi program itself to fetch the credentials
Instead of using 3rd-party tools like granted
e
We've had lots of customers using 
refresh
without too many problems over the years But there was this issue that some scenarios ended up with tokens in state and there was no way to refresh them, and this is now fixed by this latest release.
b
I'm just not sure on what this new flag does exactly, I will need to try. I guess you would need to specify the SSO url and it would open the page with the dialog where you need to grant permission like any other tool trying to generate temp credentials.
e
The new flag runs your program, so whatever your program does to get credentials for explicit provider resources will now be run on refresh as well.
It also pulls the new config from Pulumi.<stack>.yaml for default providers
Overall, providers should work the same in 
up
and 
refresh
for all cases now
b
But a program shouldn't be able to fetch credentials from remote by itself
they should always live in your local system somewhere
at least that's how it works in all other IaC like TF or CDK
They aren't persisted in the state
e
Pulumi programs are general programs, if you want to write code to fetch the latest access key via some api from your platform team you can do that. We persist these to state for historical reasons so that refresh would have access to them. TF/CDK requires you to wrap your "code" in other code like bash scripts to get credentials and things.
b
No, you don't do anything like that. Both TF and CDK simply retrieve the credentials automatically from AWS default credential provider chain.
This is the general order they follow (docs taken from Java SDK but it would be similar in other languages).
e
Yes that's the most common way, and how most people use Pulumi as well. But not every provider works the same as AWS sometimes there isn't a credentials chain that can be used. Also people do complex things, for example TFC has a whole feature to use dynamic short lived credentials, but now in Pulumi you could just write that support directly into your program if you needed it.
6 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by