https://pulumi.com logo
Join Slack
Powered by
suddenly getting an error in my automation API in ...
# general
b
suddenly getting an error in my automation API in a docker container stating: 
passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE
but when I print out the ENV vars above (running in docker) it's listed.
adding this to the local workspace vars, haven't had to do this before, and these vars are in scope of the container running it:
Copy code
// create (or select if one already exists) a stack that uses our inline program
    const stack = await LocalWorkspace.createOrSelectStack(args, {
        projectSettings: projectArgs,
        envVars: { PULUMI_CONFIG_PASSPHRASE: "XXX", PULUMI_HOME: "/tmp/pulumi_home" },
    });
Copy code
bash-4.2# pulumi version
v3.32.1
bash-4.2# pulumi plugin ls
NAME    KIND      VERSION  SIZE    INSTALLED  LAST USED
aws     resource  4.24.1   286 MB  n/a        5 minutes ago
docker  resource  3.2.0    40 MB   n/a        5 minutes ago
gotta be a regression in 3.32.1
so you can't use a blank password anymore? there is danger of deleting stack?? wow that's not good
I am using an empty passphrase for virtually everything, I don't store anything secret in the state files, and the hassle of using a passphrase in 1000+ stacks is challenging
Should I be worried that stacks are in danger of being deleted on older stacks? that could catastrophic
what's the approach to handle this moving forward for existing stacks?
e
I don't think it can actually delete stacks. What it can do is create malformed empty stacks, that's always been possible to do by ctrl-c'ing out when it prompted for a password.
And an empty passphrase will still work, but you need to set it via PULUMI_CONFIG_PASSPHRASE_FILE pointing to an empty file. PULUMI_CONFIG_PASSPHRASE="" is treated the same as PULUMI_CONFIG_PASSPHRASE being unset. This is fairly normal for envvar behaviour and we misjudged how much people we're actually using empty passphrases, so we didn't think it would have the impact it's had. We currently having internal discussions about what we should do.
b
Thanks.. I think you need to put it back where it accepts 
PULUMI_CONFIG_PASSPHRASE=""
as a valid command.. maybe it's not "usual" but it's something that is pretty heavily ingrained in Pulumi world afaik.. I know it is for my org. The encryption of the stacks/passphrase should be optional imo, it's not something that is used very often in practice unless you are using secrets.
I'd have to update multiple CI/CD pipelines and containers to use 
PULUMI_CONFIG_PASSPHRASE_FILE
pointing to an empty file that I imagine I would need to 
touch
in order to achieve parity to where i was just a few days ago
e
The encryption of the stacks/passphrase should be optional imo, it's not something that is used very often in practice unless you are using secrets. (edited)
To be accurate setting it to "" isn't opting out of encryption, its just encrypting with an empty key. But we've seen enough cases of people doing this that reverting to allowing the envvar to be the empty string is an option we're looking at.
b
Sure, that makes sense.. but for intents and purposes, it indicates a desire of the user to not dip a toe into the "password protected" state file game. If that means internally encrypting it with an empty string, that's fine. But yes, I would applaud a move back to allow it with original behavior. To be clear, if everyone is using empty strings, and I 'get ahold' of someone else's state file, are there other security downsides besides being able to read their stack config secrets?
e
are there other security downsides besides being able to read their stack config secrets?
That's a pretty big one alone. One of our main concerns is that it's currently easy to set an empty password, but we also tell people it's ok to commit their config to vcs because secrets are encrypted and it's a pretty easy failure pit to fall into if someone does both of these things.
Having said that, we'll probably revert this for now and then rethink exactly where we want to take this given we already have users using this empty password behaviour.
b
yes, but for clarification purposes, sounds like that is the main issue. generally for my org we don't use stack secrets much at all, and generally use aws param store so just wanted to confirm.
e
N.B We've reverted this behaviour change to allow PULUMI_CONFIG_PASSPHRASE to be set to "" again. It will be in the next release.
b
👍 good to hear, i think that is the correct response.. thank you for taking action
125 Views
Open in Slack
PreviousNext
Powered by