Support .env files in profile settings variables

[chuck-alt-delete]

It’s tedious to create a new variable entry in my profile settings for each variable I want to define. I’d love to paste in a “.env style” text file, like

MY_VAR1=cool
MY_VAR2=awesome
…

The use case I have is setting up secrets to access managed services. If my managed service has a bunch of different api keys and such, I want one simple way to define them all at once rather than one at a time.

[JanKoehnlein]

We're currently flooded with ongoing work. Please bring this up to groundwork again.

[loujaybee]

If you want, you could do this programatically by copying your environment variables to a workspace then running gp env for each line (example below). Use with caution though as this may overwrite any existing named existing variables 🙏

#!/bin/bash

while read -r ENV_VAR; do
    gp env $ENV_VAR
done < .env

Are your secrets coming from a single secrets source, if so which app/service are you using?

[chuck-alt-delete]

Thank you for the workaround. It is a bit fragile as I cannot use wildcard scopes for different repositories. I’d have to manually run this for each repository.

Perhaps this would be acceptable if gp env supported a way to define a repo scope for the set variable, preferably also incorporating this

• More flexible environment variable wildcard scopes #6316

That way, I could make a “set up your variables” exercise where users run that script once and they are set for all repositories in the scope.

Are your secrets coming from a single secrets source, if so which app/service are you using?

I wish I could use Hashicorp Vault or something, where I could have a single access key and use it to programmatically retrieve secrets at runtime. I personally am using Confluent Cloud, where I have two API keys, two URL endpoints, email, password, and a Confluent cloud environment ID. If I were integrating Confluent cloud with Mongo Atlas, then I would add additional variables to access my MongoDB instance, for example. Not all of these are secrets, but they are all related and I want to define them only once in settings -> variables.

[loujaybee]

Thank you for the workaround. It is a bit fragile as I cannot use wildcard scopes for different repositories. I’d have to manually run this for each repository.

That's a good point, I've raised that as a distinct issue: #6339

[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.

[chuck-alt-delete]

Please don’t close! This issue is still causing friction for me. Surely others are finding it tedious to manage individual environment variables in gitpod.io/variables?

Also, the workaround is never really going to be sufficient because I need environment variables available in the workspace on launch. I can’t wait for the user to input them manually. Why? Because the whole idea is for a user to launch a workspace and so it will dynamically and securely load that user’s API keys and launch a an application. I want this to be automatic.

[axonasif]

@chuck-alt-delete You can pretty much get this done with the dotfiles support.
See https://www.gitpod.io/docs/config-dotfiles
If you need help regarding it, let me know 👍

[chuck-alt-delete]

I don’t think this will work. Dot files are applied to all workspaces, and I don’t think they are meant to store secret credentials like gitpod.io/variables. Am I misunderstanding the dotfiles implementation?

[chuck-alt-delete]

I suppose we can close this Issue as long as these are addressed:

• Support scopes flag in gp env #6339
• More flexible environment variable wildcard scopes #6316

If these are in place, then I could create a dedicate repo that would walk users through a one time, secure setup for variables on a specific set of other repos.

[axonasif]

I don’t think this will work. Dot files are applied to all workspaces, and I don’t think they are meant to store secret credentials like gitpod.io/variables. Am I misunderstanding the dotfiles implementation?

What if you can store your .env file in a private repo and load the variables from that in all of your workspaces?
Does that sound good? dotfiles are not meant to be but you can use them in such a manner if that's appropriate for you.

[chuck-alt-delete]

Thanks for your help, but no that does not fit my use case very well. There are several drawbacks.

• First, I don’t want to require each user create their own private dotfiles repo (and docs say the repo must be public, but either way it doesn’t work).
• Second, I don’t want to encourage the practice of committing credentials to git in learning materials, even if it might be ok in this instance.
• Third, I don’t want these variables available in all repos. Only the ones that require them. Otherwise it makes it too easy for someone to forget later and share workspaces with sensitive credentials.

[axonasif]

and docs say the repo must be public, but either way it doesn’t work

You can clone a private repo under your org through a public dotfiles repo, only members in your org will be able to clone such private repos. That was the idea 😅

Second, I don’t want to encourage the practice of committing credentials to git in learning materials, even if it might be ok in this instance.

Fair enough. Perhaps #7881 would be a better fit for your use-case.

Third, I don’t want these variables available in all repos. Only the ones that require them. Otherwise it makes it too easy for someone to forget later and share workspaces with sensitive credentials.

It essentially shouldn't get leaked. Although there is always a risk when you "Share Workspace" from the dashboard, which also gives away your git credentials and everything else. So one must use gp snapshot command instead for sharing a workspace.¹

Footnotes

1. https://www.gitpod.io/docs/sharing-and-collaboration#how-to-take-a-snapshot-url ↩

[chuck-alt-delete]

Thanks again for the lengths you are going to help! I realize I mentioned more about my use case in those other linked issues but not here. I’m not just working with other engineers in my org. I’m creating labs and demos for learners and prospective customers. The goal is to have a 1 time setup for the users where they enter their credentials. Then after that, every lab (each lab in its own repo) should be able to automatically connect to each user’s SaaS account. For example:

• https://github.com/chuck-confluent/ccloud-gitpod-demo/blob/main/.gitpod.yml#L41

[loujaybee]

I wish I could use Hashicorp Vault or something, where I could have a single access key and use it to programmatically retrieve secrets at runtime. I personally am using Confluent Cloud, where I have two API keys, two URL endpoints, email, password, and a Confluent cloud environment ID. If I were integrating Confluent cloud with Mongo Atlas, then I would add additional variables to access my MongoDB instance, for example. Not all of these are secrets, but they are all related and I want to define them only once in settings -> variables.

@chuck-alt-delete We are now currently looking at enabling something as you described.

• Also as described here: Create a OIDC Provider for Vault JWT access on each Pod #9412

If you (or anyone else 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.