able-dusk-25606
04/30/2025, 8:01 AMpulumi 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
?limited-rainbow-51650
04/30/2025, 12:47 PMeverything 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?
able-dusk-25606
04/30/2025, 1:46 PMpulumi 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`.able-dusk-25606
04/30/2025, 1:47 PMable-dusk-25606
04/30/2025, 1:54 PMlimited-rainbow-51650
04/30/2025, 1:58 PMexport 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.