Hello! When getting started, `pulumi login` and th...
# getting-started
a
Hello! When getting started,
pulumi login
and then via browser was nice and easy ðŸŒŧ Now I want to harden this up and test out how multiple developers would connect from their local machine. Github actions looks fine, but everything for local dev points to personal access tokens, which isn't allowed in most organizations. I also see that my
pulumi login
commands have left a long trail of tokens with no expiry sad panda. My takeaway is "_the only way to login to Pulumi for local development is with a personal access token_". Is that correct? Should I look to object storage backends, that can be covered by
azure login
or
aws sso login
?
l
Hello @able-dusk-25606, regarding this part of your message:
everything for local dev points to personal access tokens, which isn't allowed in most organizations.
We experience the opposite with most of our customers. For local development, they have to use a personal access token so the exact identity of the person ends up in the audit logs. Can you expand a bit why you don't want to use a personal access token to access Pulumi Cloud for local development purposes?
a
Thanks for the response to a pretty broad and uncertain question. I agree that it's essential to use the identity of the developer 👍. My concern is, after a couple of weeks of
pulumi login
, I see I have generated a trail of never expiring access tokens (screenshot attached). If any one of these were compromised along the way, my understanding is that the holder could be me on pulumi cloud (no 2FA either). What I'm looking for is a pattern for OAuth with short lived tokens. This is not my speciality -- so I appreciate the help interpreting my concern ðŸĪŠ Where I'm coming from, is recent experiences terraforming Azure and Databricks, and developing with dbt, where no PATs were required after an `az login`.
I suppose the long trail of PATs is a result of using devcontainers 😅
Given that I'm not sure where these PATs are landing up on my devcontainer when I do login... that feels a bit prone to being accidentally leaked.
l
A manual thing you can do is
export PULUMI_ACCESS_TOKEN=<pat>
before
pulumi login
. The login will pick up the existing token at that moment. I agree this requires human effort, which can lead to human error. I'm checking internally whether an admin can enforce an expiration on a PAT.