New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organization level secure variables #2069

Closed
till opened this Issue Mar 17, 2014 · 21 comments

Comments

Projects
None yet
@till

till commented Mar 17, 2014

Maybe a data bag which is organization-wide to manage/maintain some keys instead of adding them to all my .travis.yml files.

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Mar 17, 2014

You want github-org/repo1 and github-org/repo2 to share some information in .travis.yml? I am not sure how that would work. Where would you set this information? What happens if you have a conflict (no matter how the information is set)? Do you want a mechanism to inject exceptions (e.g., the org-wide value is X, but you want to set value Y for repo3)? I suspect the situation will be quite murky and confusing.

In general, I believe having these values set for each repository is cleaner.

If I misunderstood what you had in mind, please elaborate.

@till

This comment has been minimized.

till commented Mar 17, 2014

@BanzaiMan I want a web interface or API to set environment variables for github-org so I can use them in each repository's .travis.yml.

E.g. to rotate keys like API tokens for Github, ssh key to clone/install dependencies, S3 keys, etc.. Right now I am maintaining all of the above in each YAML file. We have 60 or so repositories enabled. It makes rotating keys very tedious.

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Mar 17, 2014

Sharing secure environment variables among repositories is problematic, since we use they are encrypted for each repository.

I changed the subject of this ticket from 'Manage secure environment variables globally' to 'Organization level secure variables', which I believe is what you are asking. I tend to think this is a potential security issue, though I may be mistaken.

@BanzaiMan BanzaiMan changed the title from Manage secure environment variables globally to Organization level secure variables Mar 17, 2014

@till

This comment has been minimized.

till commented Mar 23, 2014

I don't see it as such, the people I work with have my trust. :)

@sarahhodne

This comment has been minimized.

Contributor

sarahhodne commented Mar 26, 2014

I think I am in favour of this feature, I think it would be useful for quite a few people. For example, say we (travis-ci) wanted to deploy all of our applications to staging on Heroku on a passing build. Every repository needs a Heroku API key. Now, say this key is leaked for some reason (either as part of the build or otherwise) and it needs to be changed. Normally this would require committing the new key to every single repository, but with this feature it only needs to be updated once.

I do see this as being a potential security issue, but I think in part this can be left to the people choosing to either use or not use this feature. To make it a bit more secure we could add a list of repositories that are allowed to use the key (so in the example above, only the repositories that are actually supposed to be deployed to Heroku get to see the key).

@samgiles

This comment has been minimized.

samgiles commented Aug 6, 2014

You could achieve something similar with the Travis API: http://docs.travis-ci.com/api/#settings:-environment-variables (Would be nice for it to be exposed in the UI though, unless I've missed it of course..)

@oehme

This comment has been minimized.

oehme commented Dec 8, 2014

👍
I have a hard time explaining to people why they have to repeat the same 3 variables for each of their repositories.

I worked around this by having a build job that uses the travis API to set the variables in all other build jobs. https://github.com/oehme/travis-secrets-setter

@rkh

This comment has been minimized.

Member

rkh commented Dec 13, 2014

I think this can be scripted on top of our API/CLI, though the script would need to be run again or automatically check for new repositories.

@joshk

This comment has been minimized.

Member

joshk commented Jul 25, 2015

Closing this as the issue has become stale and is not likely to be done in the next 3-6 months.

@joshk joshk closed this Jul 25, 2015

@till

This comment has been minimized.

till commented Jul 26, 2015

@joshk just for the record, still an issue for us.

@joshk

This comment has been minimized.

Member

joshk commented Jul 26, 2015

I ❤️ you @till

I can understand why this would be good, but do not think it is something we will be adding in the next 3-6 months. We may reopen and relook at this in the future though.

@jehine-MSFT

This comment has been minimized.

jehine-MSFT commented Apr 26, 2016

Hello Travis CI folks,

My team has run into the same issue. It would be great to have a dynamic way of adding encrypted lines of text after the config has been loaded that Travis could then decode API keys and such. With current limitations, we are left with having to run a job that will update each of our repos's travis configs for each branch whenever we rotate our keys.

There are valid scenarios where customers would need this functionality without performing poor security habits.

Any plans yet to develop this feature? Something as simple as being able to call a travis API decryptLine API within the test script would solve this problem. Since these tests only run in your environment I don't see this being a security risk.

Thanks!

@till

This comment has been minimized.

till commented Apr 27, 2016

@jehine-MSFT you can automate some of this with custom scripting around the travis ci cli. I believe that is what we to mass-update, etc.. Still wish there was a better option.

@till

This comment has been minimized.

till commented Apr 27, 2016

(You're welcome, @joshk)

@deitch

This comment has been minimized.

deitch commented Sep 12, 2016

I know this is an old issue, but it is an issue. It probably should be open.

I can list many different use cases, but I think @till describes it best:

We have 60 or so repositories enabled. It makes rotating keys very tedious.

Not just rotating keys. A common scenario is an organization with 6 or 60 repos, and a common artifact store (e.g. Docker registry). Those creds should not be in the repo, even as a secret. Management of it is impossible.

Think of the current flow for adding a project:

  1. Create new repo
  2. Add it as project in Travis part of target org
  3. Ask whoever manages the artifact repository for a key, or have them retrieve it
  4. Create encrypted
  5. Add it to travis.yml

And what happens when we need to invalidate or change keys, as @jehine-MSFT said? Mess.

Here is a far better flow:

  1. Create new repo
  2. Add it as project in Travis part of target org

Done. Because it is org-wide env vars, all of my deployment and build scripts inherit them.

Of course a local script or travis.yml could override, but by default, everything works cleanly.

@gajus

This comment has been minimized.

gajus commented May 10, 2017

So, as the result of the recent incident (https://blog.travis-ci.com/2017-05-08-security-advisory), a user needs to go to every single repository and update the ENV variable. In my case, thats over 100 repositories.

@gajus

This comment has been minimized.

gajus commented May 10, 2017

This is how I've done it:

export GITHUB_USER=gajus
export GH_TOKEN=...

travis login
travis repos -o $GITHUB_USER -a --no-interactive | xargs -n1 travis env set GH_TOKEN $GH_TOKEN --private --repo
@matthewcummings

This comment has been minimized.

matthewcummings commented Sep 18, 2017

Team Travis. . . please add this functionality!

@jmahowald

This comment has been minimized.

jmahowald commented Oct 4, 2017

@gajus Thanks for that tip. Created a mini script to encapsulate it just a little more for more my needs.

cat ~/bin/travisset.sh
#!/bin/bash

PATTERN=$1
ENV_VAR=$2

travis repos --pro --no-interactive -m $1 | xargs -n1 travis env set $ENV_VAR ${!ENV_VAR} --private --repo

travisset.sh 'myorg/*' AWS_ACCESS_KEY_ID

@JChanceHud

This comment has been minimized.

JChanceHud commented Aug 17, 2018

Hello Everyone,

My company recently switched from circleci to travis and this issue was a pretty big roadblock in the transition. Circle has a really nice feature called organization contexts that allows shared variables across an entire organization to be set.

I wrote a utility called travis-env that reads a JSON configuration file from S3 and then outputs the content to stdout in a way that can be used by eval like the following:

eval "$(npx travis-env)"

This allows me to provision each ci repo using a single configuration variable that is a JSON formatted string including AWS credentials and the bucket containing the JSON config file.

More information about usage can be found in the readme, and these are some of our open source projects with .travis.yml configs that use the tool:

Hopefully some others find this tool helpful, issues and pr's welcome!

@rhanton

This comment has been minimized.

rhanton commented Sep 6, 2018

We could really use this too. Seeing that Circle CI has it kind of makes me consider moving to them for CI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment