https://pulumi.com logo
#contribute
Title
# contribute
m

millions-train-91139

11/26/2023, 8:16 PM
Hey all, How can I push this change forward: https://github.com/pulumi/pulumi/pull/14543 Also related, I noticed
CheckpointV3
has a
Config
field, but it seem unused, is there a reason for it? I think it could be great to save the stack config in the same file so that
stack export / import
will also import the configuration.
e

echoing-dinner-19531

11/27/2023, 9:18 AM
On my todo list this week. While it looks reasonable at first glance we're a little concerned about the relationships between state and config so gonna give it a think over.
m

millions-train-91139

12/04/2023, 12:06 PM
Any chance to look at this as well: https://github.com/pulumi/pulumi/pull/14698 I want to advance it before I advance the former one. I want to change Pulumi to be very explicit about changing secret providers, while we are at it.
e

echoing-dinner-19531

12/04/2023, 12:50 PM
I think my comment from the other PR thread stands. Adding a flag like this now is a breaking change and we're generally very reluctant to accept those. Making this an error on empty stdin is also technically a breaking change, but is such a bad use of the system I think we'd be ok with that.
I do agree with your desires here though, if we we're building this from scratch today I'd happily add this flag.
Maybe leave a comment in the PR that --stdin is a good idea, if we ever get V4 pulumi or split out the secret providers to be versioned we could look at adding it in.
m

millions-train-91139

12/04/2023, 12:54 PM
So we are fine with having
rotate
dictate the source of the passphrase? TBH, I'm not even so sure how much passphrase rotation is really used in automated systems to care about breaking it.
e

echoing-dinner-19531

12/04/2023, 12:56 PM
Again, I think it would be a break change to change that now 😞 Ideally any change (either new change to passphrase, or a passphrase rotation) would read stdin but given there's probably a lot of code already using the envvar to set this I think we have to keep that working.
It's all very not ideal, but such is the fun of building systems while minimizing breaking behaviour changes.
Again, probably worth leaving a comment in the code that this is not ideal and we might be able to change it at some point.
m

millions-train-91139

12/04/2023, 1:02 PM
To be honest I think that changing secrets in CI is something that doesn’t really happen since a lot of things can go wrong. Which to be fair is the whole point of this work, to read existing secret providers from state and disallow switching secret providers in a non explicit way. I don’t mind dropping this, I just tried to clean this behavior as I advance, I also think that the reason there are not many issues around this, is due to the fact this is mostly unused.
Also wanted to ask, how do we feel about
config
being decoupled from
state
(retrieved from history on
config refresh
) but being encrypted by a secret provider stored in the state. Seems like lots of things can go wrong here, since obviously config + state updates are not atomic.
Also here, I think that probably the majority of users will not store secrets in config, and if they do, they would be easily restorable. However secrets in the state might usually be intermediate inputs/outputs which better not to lose those since getting access to them is a lot harder. So seems like a 2nd degree problem. A bit connected to my question about, should the last used config for some update should be stored in the
CheckpointV3
file, which now has an empty config section
e

echoing-dinner-19531

12/04/2023, 2:21 PM
I also think that the reason there are not many issues around this, is due to the fact this is mostly unused.
Maybe, but might just be that most are just using this and it works fine. It's hard to tell given we don't have telemetry, so we have to generally be cautious.
Seems like lots of things can go wrong here, since obviously config + state updates are not atomic.
Well this is why I said config secrets provider should take priority. config can change without a state update, but at least every state update would then consistently be using the provider set by config.
I think that probably the majority of users will not store secrets in config
Nah this is a bad assumption. Lots of users store secrets in config.
bit connected to my question about, should the last used config for some update should be stored
Maybe... I need to look into this more. It is a bit of a confusing system that's grown over the years trying to keep compatibility with what already exists.