Epic: Organization-wide environment variables and secrets for prebuilds and workspaces

[jldec]

Summary
In epic #7517 we introduced project-specific environment variables for prebuilds & workspaces.
This followup epic adds team-wide environment variables shared across all the projects in a team.
The goal of this feature is to help teams to maintain cross-project configuration like secrets, with minimal duplication.

[svenefftinge]

Anyone, please share if you have concrete demand for this and why.

[axonasif]

In our discord channels, I have seen a bunch of people in the past who could potentially find this feature useful.

[tkislan]

@svenefftinge
One example is using private packages in a project. Without a secret there is no way to have prebuild download and resolve all the dependencies

[mikenikles]

I talked with a CTO today and they have 200+ microservices, each in their own git repository. They'd like to configure variables at the team level so individual projects inherit the variables.

[raaone7]

+1 please

[jankeromnes]

With Project-level variables already in place, it seems pretty easy to add Team-level variables as well (can re-use most of the same code and UI).

Thus, I believe this should not be an "epic", but just a regular issue. Also, I'm happy to make this happen, and thus optimistically assigned myself.

Currently focused on finishing other high-priority items, but happy to pick this up if/when it gets "scheduled". 👍

[karpa]

We would like to have prebuilt-only variables on projects.
We need to safely add a project variable (e.g a private key) BUT the variable is visible only during prebuild. (Thus not visible to users who work on the project)

[KayakinCoder]

Anyone, please share if you have concrete demand for this and why.

This would make setup and ongoing management of Gitpod for our team much less of a chore. We have ~15 microservices each with their own repository, and the management of env vars is one of the only downsides I have on my pro/con list for moving our team to Gitpod.

[jankeromnes]

Thanks for detailing your use case @KayakinKoder! This helps with prioritization.

---

@karpa Maybe I'm missing something, but it seems that what you describe can already be achieved today, like so:

• Have (or create) a Project in Gitpod (either under a Team, or under your Personal Account)
• Navigate to the Project Settings, then to Variables
• Here, you can create new environment variables, and select whether they should be visible only during prebuilds, or to every project collaborator in their workspaces too

I.e. if you want prebuild-only variables, you can keep "Hide Variable in Workspaces" checked. ✅

[aabkn301]

Could be very useful to be able to inject API keys that live at organization level.

Btw, support for tool like doppler.com can be useful also to have a better secret management.

Currently we use an init scritpt that download env from doppler and inject them in the current workspace using gp env :)

Thanks a lot for your amazing product,

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghostdevv]

Not stale 🙏

[axonasif]

Could workspace-classes be configured globally (org-wide) as well?
Was asked here: https://discord.com/channels/816244985187008514/1070284654055272488/1070298397929644114

[faermanj]

That would help a lot, especially if tem member variables can be set individually.
For example, telegram bot developers need unique individual API keys. I would like to set the credentials for new developers so that they are set from day 0.

[loujaybee]

We would like to have prebuilt-only variables on projects. We need to safely add a project variable (e.g a private key) BUT the variable is visible only during prebuild. (Thus not visible to users who work on the project) - @karpa

This would make setup and ongoing management of Gitpod for our team much less of a chore. We have ~15 microservices each with their own repository, and the management of env vars is one of the only downsides I have on my pro/con list for moving our team to Gitpod - @KayakinKoder

We are actively investigating Gitpod supporting something similar to as described here:

• Create a OIDC Provider for Vault JWT access on each Pod #9412

This allows Gitpod to be used as an IdP and authenticate with services like cloud providers (AWS, GCP, Azure) or Vault without the need for environment variables in your workspace. This works by establishing a trust relationship between Gitpod and these providers. If anyone stumbling on this issue would like to chat to see how this does/could work in Gitpod, I'd be happy to talk you through it, and see what we'd need to do to get things setup for you.

CC: @millerh1, @Sandared, @aabkn301, @MrPeacockNLB, @mikestaub, @ghostdevv, @faerman (for 👍 reactions)

[loujaybee]

Btw, support for tool like doppler.com can be useful also to have a better secret management - @aabkn301

Have you seen...

https://www.gitpod.io/blog/securely-manage-development-secrets-with-doppler-and-gitpod
https://docs.doppler.com/docs/gitpod

CC: @burningion

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[axonasif]

Not stale.

[oodavid]

This is the only issue for us.

Our tech-support team will use a CDE to manage small areas of our customers codebase.
For this, we need access to our private npm packages. We do this with an .npmrc file.
npm automatically replaces tokens in this file with environment variables:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

For the time being, we will ask our users to set their own environment variable on gitpod, but it makes rotating our tokens a bit of a chore. We'd much rather have an organisation-level token that we can rotate centrally.

When reviewing the different CDE's this quickly became a requirement as we know it will make onboarding new team members as simple as "click the invite link".

Edit: The reason we don't use project-level secrets, is that we have hundreds (thousands?) of repos.

[axonasif]

Hi @oodavid and everyone else here.

If you don't configure a custom image for each of the said repos, you could apply the following workaround:

• Build a private image using a dockerfile, push it to dockerhub. In the dockerfile, you may use the ENV key=value statement or even directly create the .npmrc file. (docs)
• Set the private image as the default organization image. (docs)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.