Hello team, Our team just started to use Pulumi S...
# getting-started
f
Hello team, Our team just started to use Pulumi Service and we have an organization. Is there a way to generate access token on behalf of that organization? I can only generate my individual personal access token. If there is a way, do I need to be an admin of that organization?
s
You do need to be an admin to create an org token, per: https://www.pulumi.com/docs/intro/pulumi-service/organization-access-tokens/
f
Thank you for confirming @stocky-restaurant-98004 🙏
youre welcome 1
c
Docs say "Organization tokens are available on trials, and Enterprise and Business Critical subscriptions." We are on a trial but will eventually be on Team pricing, not Enterprise or Business Critical at this time.
Best practice, regardless of Org size would seem to be to have Org Tokens, but if that is a restriction to only enterprise teams, that would seem to force us to use a workaround like a shared account, but is not great security. Or is there an alternative or something we're missing?
l
You can use a non-shared CI account.
c
@stocky-restaurant-98004 Can you confirm Org Tokens are not available on Team accounts after the trial ends?
@little-cartoon-10569 Could you elaborate? We do have the Pulumi app installed and configured in GitHub.
s
@crooked-notebook-49997 That's correct - they will no longer be available once the trial ends.
c
So what would be the recommendation in that case for configuring access without personal tokens?
l
@crooked-notebook-49997 I think it's what you meant when you said "a workaround like a shared account". Just, don't share it. There's no need for anyone to use it once it's created and set up in CI. The creds remain in a vault and no one ever logs in as it.
c
So we have such an account we use for CD in other scenarios, I say its a shared account but in reality we do not share the creds and we do not want to. So while I have access, @fresh-musician-40418 does not, and he is setting up Pulumi.
l
Is this your current problem? • Limited number of accounts (3, iirc). • 1 needs to be admin (you). • 1 needs to be CI. • You have 15 other infra devs. We have this with one project. It is the ultimate push towards gitops! 🙂
c
Yup, I think so, more of less.
l
Our solution was a for dev envs to use local / private state, and only CI to use the Pulumi service. It's not awesome, but it forces excellent practices with things like project and stack naming. And in our case, the problem went away just after we got everything working acceptably, because the company saw how useful Pulumi was and upgraded us.
c
• 1 Me (Admin in GH and Pulumi) • 1 CI (Admin in GH and Pulumi) • 4-5 Devs
3 shared environments and corresponding branches: Dev, Stage, Prod. Plus, each developer has their own environment (AWS) (and branch). Desire is to manage/store Pulumi State Files in Pulumi (vs. local or S3).
l
CI doesn't need to be admin...
The only way to achieve that on the lower-tier plans and prevent shared credentials is to not give devs direct access to Pulumi and require everything to do done via GH. Dev envs can be managed just like stage / prod etc. Only the CI user does any real deployments.
c
Alright. All good advice and help. We'll continue and see where we end up. Thanks!