Be able to use multiple accounts simultanously.

[damianh]

This is not bug report but a feature request.

I have multiple pulumi profiles under different email addresses and I keep forgetting which one I'm logged into which is causing some issues. Sometimes I need want to work on different accounts concurrently (in different terminal sessions of course). pulumi login is a machine wide state and having to login -> logout -> login -> logout is proving tiresome and error prone.

As an example, AWS has the concept of profiles to address this issue. In my terminal I set an environment variable AWS_PROFILE and then all subsequent aws cli operations will use that. In a different terminal session I might use a different AWS_PROFILE. There is also the --profile argument for cli operations. Perhaps Pulumi could do something similar?

[damianh]

An implementation suggestion just off top of head to inspire :)

• pulumi login --profile X <- performs a login and stores credentials token under profile "X". If alreay logged in for this profile, then the profile is used for rest of session.
• pulumi login --list-profile <- lists the logged in profiles on the machine
• pulumi logout --profile X <- logs out of a specific profile.

[lukehoban]

We added a PULUMI_BACKEND_URL env var in #5789, which I think basically accomplishes what is asked for here.

Adding documentation for that in pulumi/docs#4874.

That env var doesn't add any explicit profile management (which I think is ultimately just about assigning an alias "profile" name to the backend URL), but I'm inclined to think this isn't particularly high value in and of itself. The major improvement PULUMI_BACKEND_URL offers is that the backend can be configured without system-wide pulumi login state change.

[damianh]

In my case the backend urls I'm using for multiple "profiles" are https://app.pulumi.com. How will PULUMI_BACKEND_URL work when seperate access tokens will be needed for the same backend url?

[damianh]

I've just added this to my powershell $profile:

function pulumi-profile([string]$profile){
    pulumi logout
    if($profile -eq "work"){
        $env:PULUMI_ACCESS_TOKEN = "pul-XXXXXXX"
    }
    elseif($profile -eq "personal"){
        $env:PULUMI_ACCESS_TOKEN = "pul-XXXXXXX"
    }
    pulumi login
}

Seems to work :

[lukehoban]

In my case the backend urls I'm using for multiple "profiles" are https://app.pulumi.com. How will PULUMI_BACKEND_URL work when seperate access tokens will be needed for the same backend url?

In that case you don't need to login/logout at all - you are using the same backend the whole time, just different credentials. If you just set PULUMI_ACCESS_TOKEN, it should work.

[damianh]

Yes that's what I'll do. I however think it would be a quality of life improvement to support the idea as first class feature and thus support pulumi login via browser to get the access token(s) vs the manual approach.

[damianh]

I blogged about my approach here https://dhickey.ie/2021/01/24/pulumi-multiple-accounts/

[codeweft]

Dropped in a gist here for linux users: https://gist.github.com/codeweft/2dd50dac3ae0dc2f69ab6ac954d4eded

[MythicManiac]

Could Pulumi perhaps support a .env file at the project root for reading the PULUMI_ACCESS_TOKEN, provided it's also in .gitignore?

[ghostsquad]

In that case you don't need to login/logout at all - you are using the same backend the whole time, just different credentials. If you just set PULUMI_ACCESS_TOKEN, it should work.

How does this work when I want to use s3://<something>, and need to target different AWS Accounts?

[ghostsquad]

Possibly need to clarify this comment. The scenario is that credentials for backend are different from credentials needed for pulumi up.

[rhyek]

Using version v3.35.3 and pulumi commands will actually log in with any existing PULUMI_ACCESS_TOKEN and the session will persist even across different terminal sessions. Changing the environment variable to a different token will not cause a new log in so I'm still forced to run pulumi logout to use the new credentials.

[damianh]

Nearly 3 years. Close if it's not going to happen?

[praneetloke]

@damianh I think you should reopen this. Despite the length of time this has been open for, this still remains a useful feature to add.

Also based on the conversation thus far in this issue, I think some clarity is needed on the ask here. Specifically, I believe the ask is for switching between Pulumi Cloud accounts that belong to the same cloud backend URL, for eg. https://api.pulumi.com or if an enterprise has a self-hosted cloud: https://api.acme.com.

If I have a user abc@company.com and a def@company2.com account on Pulumi Cloud, I have to: pulumi logout https://api.pulumi.com, pulumi login every time to switch between the two. While you could use the PULUMI_ACCESS_TOKEN env var to override the account being used, it's not a developer-friendly experience to have to create an access token for each of my Pulumi Cloud accounts and remember to use a different one each time. Moreover, using the env var method seems to override the credentials acquired by the CLI by an earlier pulumi login which means I can't temporarily use a different cloud account either.

This is not a problem for self-managed backends since the backend URLs are different if you are using different buckets between your "accounts".

[damianh]

Re-opened as requested (however it is getting really long in the tooth...)

Specifically, I believe the ask is for switching between Pulumi Cloud accounts that belong to the same cloud backend URL

Correct. Though I can't speak for enterprise self-hosted cloud - I've not used that.

[rhyek]

While you could use the PULUMI_ACCESS_TOKEN env var to override the account being used, it's not a developer-friendly experience to have to create an access token for each of my Pulumi Cloud accounts and remember to use a different one each time.

I don't agree with this. I like to have .env.local files in the root of my projects and load them automatically with direnv. The AWS cli picks its env vars from there automatically and I am confident that every AWS command I run in each project is done so against that project's account.

This is what I would expect to happen with pulumi and its PULUMI_ACCESS_TOKEN.

[hmrodrigues]

for reference, I used this script. I named pulumi and it's placed on PATH before the actual pulumi binary. It loads the env vars, optionally sources a a script with the profile name (useful to load other variables for example) and then calls pulumi it self

#!/bin/sh

set -e

PULUMI_PROFILE_PATH="${HOME}/.pulumi/profiles"

pulumi="$(which -a pulumi | grep -v ${0})"

if [ ! -z "${PULUMI_PROFILE}" ]; then
    case "${PULUMI_PROFILE}" in
        XXX) PULUMI_BACKEND_URL='XXX'
    esac
    export PULUMI_BACKEND_URL
    if [ -e "${PULUMI_PROFILE_PATH}/${PULUMI_PROFILE}" ]; then
        . "${PULUMI_PROFILE_PATH}/${PULUMI_PROFILE}"
    fi
fi

$pulumi $@
exit $?

[nmdaniil]

I am writing to highlight a significant challenge faced by DevOps engineers managing multiple projects (4 and more) or companies with separate accounts on https://app.pulumi.com. Currently, for each project, engineers must execute a series of steps to log in to the appropriate Pulumi account:

> cd projectX

> pulumi logout

> pulumi login

...find and copy access token projectX

> [insert access token projectX]

This process is cumbersome and prone to human error.

Forgetting to switch accounts could result in pushing state of one project into another state, leading to potential chaos and disruption of business-critical services 😱
Given the high stakes involved in managing stateful resources, this issue poses a significant risk 💸💰🫰

it's surprising that there are currently no solutions offered to manage multiple Pulumi accounts more efficiently.

Solution

The simplest solution to this issue could be to add a credentials_path field in Pulumi.yaml:

backend:
  credentials_path: ./secret/project-x-credentials.json

This approach would provide a clear, project-specific reference to the appropriate credentials, streamlining the workflow for DevOps engineers managing multiple projects and reducing the likelihood of errors.

[JanStevens]

Chipping in, you can just move the complete .pulumi dir located in your user profile to be colocated in your project and add it to gitignore. Ex: export PULUMI_HOME='.pulumi' this way every project will have its independent pulumi configuration / provider and secrets

[praneetloke]

@nmdaniil

Forgetting to switch accounts could result in pushing state of one project into another state, leading to potential chaos and disruption of business-critical services

I kind of agree with what you are saying and it's quite possible that, if you have the same project/stack deployed in multiple accounts and made a code change meant for one account and were logged into another, then yeah you could accidentally apply the change to the project/stack in the wrong account. However, ideally, you have a separate repo for each account that you are deploying the project to, so you can make independent code changes. Note that I say "ideally" because there may be instances where you can't do that.

Having said that, I think that the stack config file Pulumi.<stack>.yaml should have the account name or the org name persisted so the CLI can do a sanity check to see if you are using the right service-backed account that either matches the account name or are logged into an account that has access the org to which the stack belongs.

Lastly, I think it would be simple to have the CLI allow switching between service-backend accounts and cache them in the same file as it does today. Something like pulumi login https://api.pulumi.com <alias> and then later you can switch between aliases with pulumi login --alias <alias> (note that I didn't call it a profile because it's not a full-fledged profile like most people are used to with the AWS CLI.) The alias would also be useful for self-managed users so that they don't have to type pulumi login s3://... every time, for example, and can simply do pulumi login --alias.