Repository navigation
Support for GitHub Secrets #441
Description
Activity
Thanks! We agree! We've discussed this internally and it's something we're considering when we'll build it, so we'll use this issue to track that!
Reacted by Hleb Kastseika, R. Stephen Guerra, Tyler Jones and Jack ConsidineThank you! Hope to see this feature in near releases:)
Would definitely be interested to see this feature; especially using it in the context of gitOps CI/CD where it can create a new secret and a reference to the value. Specifically the input of the secret value can come referenced source (so that secret value doesn't need to be check in; essentially separating the creation of a new secret object and the input of a secret value).
Reacted by Hleb Kastseika, R. Stephen Guerra, Kumbirai Tanekha, Jack Considine and Elle O'BrienI created github-secrets-writer (written in Go) for writing (create/update) one or more secrets.
github-secrets-writer is a command-line tool that simplifies the process of creating or updating Github secrets by carrying out the encryption for you, and writing the secrets to Github via the API.
With a small amount of effort I could incorporate it here but it looks like the project isn't open for feature contributions.
Usage looks like this:
$ GITHUB_TOKEN=... github-secrets-writer \ --owner example-owner \ --repo example-repo \ --from-literal secretName1=secretValue1 \ --from-literal secretName2=secretValue2 \ --from-file secretName3=/path/to/secretValue3 Write results: secretName1: 204 No Content secretName2: 204 No Content secretName3: 204 No ContentHey, I've created a githubsecrets cli - https://github.com/unfor19/githubsecrets
Install with pip
pip install githubsecrets
Or use with Docker (you must supply all arguments, prompts are not available in Docker mode)
macOS and Linux
$ docker run -v $HOME:/root unfor19/githubsecrets --help Usage: ghs [OPTIONS] COMMAND [ARGS]...Windows
$ docker run --rm -v c:/Temp:/root unfor19/githubsecrets --help Usage: ghs [OPTIONS] COMMAND [ARGS]...
I'd like to convert the githubsecrets-cli (python) that I've created, to golang and add it as a feature to gh-cli.
The current flow -
- Generate a personal access token in GUI
ghs init- creates a credentials file, which stores profiles, each profile has - owner/org and personal access token (pat)ghs profile-apply- create a profile, supply owner and patghs secret-apply- define which profile to use, github repo, secret name and value
Now I wonder, if I want to add this feature, how should I approach it when it comes to personal access tokens?
It seems likeghdoesn't officially address the use of them.@unfor19 Have you seen my earlier comment? #441 (comment).
github-secrets-writer is written in Go but focuses on writing secrets. Adding GET, LIST and DELETE would be trivial given that it's built using https://github.com/google/go-github.
The Github personal token is ingested as an environment variable
GITHUB_TOKEN, which I believe is a common practice.It's also worth noting that I couldn't find the equivalent of Python's
nacl.public.SealedBoxin pure Go sogithub-secrets-writerimplements that building on top of the primitives provided by Go's supplementary cryptography libraries, see https://github.com/doodlesbykumbi/github-secrets-writer/blob/master/pkg/encryption.go#L24-L37.@doodlesbykumbi wow I missed that one, good work! I've read that they are now open for new features, so you'll probably be able to merge this as a feature once the authors reply.
Regarding GITHUB_TOKEN as env var, it just seems to be annoying to supply it each time that you run it manually. For CI/CD processes it's perfect, but for daily use it's annoying. Do you have any ideas on how to improve that? 🤔
@unfor19 I agree, manually handling the GITHUB_TOKEN env var can be a bit cumbersome. It's also asking for trouble from a security standpoint. I find your idea of profiles interesting.
Generally, for managing injection of secrets as environment variables I tend to make heavy use of https://cyberark.github.io/summon/.
Where you keep the secret is really up to you, it could be a fully-fledged secret store or it could be on the file system like in your CLI. Summon has this concept of providers which fetch secrets from some given store given the id/path of the secret, then it will inject them into your process for you.
Supposing that your CLI took the GITHUB_TOKEN envvar, you could actually replicate the profile functionality in your CLI using
summonby creating a wrapper for your ghs command as follows.function authenticated_ghs() { summon \ --provider /bin/cat \ -D profile=${GHS_PROFILE:-default} \ --yaml 'GITHUB_TOKEN: !var ~/.githubsecrets/$profile.token' \ ghs $@; }The GITHUB_TOKEN values for each profile can be stored at
~/.githubsecrets/$profile.tokenwith the default being~/.githubsecrets/default.token. This way you can call the wrapper without specifyingGHS_PROFILEand it would just use the default.With the above,
ghs secret-apply -p willy_wonka -r github-secretsbecomes
authenticated_ghs secret-apply -p willy_wonka -r github-secrets // or GHS_PROFILE=not-default authenticated_ghs secret-apply -p willy_wonka -r github-secretsNote: It might not be the best idea to store your GITHUB_TOKEN on the file system in general, but perhaps on your development machine there can be good reason. It's a good idea to ensure that there are constraints on who has access to files containing these sensitive values, the same holds true for any secret store.
Reacted by shaharglazner@mislav @billygriffin What are your thoughts on #441 (comment) ?
...
With a small amount of effort I could incorporate it here but it looks like the project isn't open for feature contributions.Note: It might not be the best idea to store your GITHUB_TOKEN on the file system in general, but perhaps on your development machine there can be good reason. It's a good idea to ensure that there are constraints on who has access to files containing these sensitive values, the same holds true for any secret store.
I totally agree with you on that, but I didn't want to make it complicated and use an external-provider, I wanted to make it as simple as possible.
The security risk here is only if someone gets access/hacks to your local machine, and I imagine that exposing this git-token will be the least of your problems if your machine is hacked.
For example, I use aws-vault to store my AWS credentials on my local machine, but most of the people I know are simply following AWS's guide - Configuring the AWS CLI, and store their credentials in a plain-text file. I'm not saying it's a good approach, but when it comes to simplicity and the risk of getting hacked ... I go for simplicity 😎
Reacted by Kumbirai Tanekha@doodlesbykumbi you should totally contribute a PR to this project, if you have the time.
Reacted by Kumbirai TanekhaIssue mentioned in http://blog2.vorburger.ch/2020/05/fineractdev-cicd-from-github-to-google.html 😄
Looks like the contributing page has changed, and the repo is open to feature PRs now. I'll make some time for this soon
Our contributing docs state (emphasis mine):
We accept pull requests for bug fixes and features where we've discussed the approach in an issue and given the go-ahead for a community member to work on it.
We appreciate that there is interest to add this feature, but please hold off pull requests until someone from our team actually gives the go-ahead for GitHub Secrets.
Reacted by Kumbirai TanekhaI would like the same feature and was thinking about contributing my work from the https://github.com/google/go-github project that spawned from this issue google/go-github#1607
and this PR google/go-github#1626. I was able to use the package for libsodium in go to deal with the encryption of the secret similar to the python implementation. If there are any updates on accepting PRs let me or the others know! thanks!Reacted by Mislav Marohnić and Kumbirai TanekhaI'll be taking this work on.
Reacted by Antonio Alvarado, Juan Pablo Arias, Ned Bellavance, Alvaro Tinoco, MaLub, Ed Smith, Vighnesh Raut and Nestor VeraReacted by Ed SmithGitHub Actions secrets are now supported: https://github.com/cli/cli/releases/tag/v1.4.0
Reacted by Hleb Kastseika and Nestor Vera- added a commit that references this issue
on Jul 21, 2025
That would be great if Github CLI could support Secrets which are used in Github Actions. Do you have any plans for that?