Support for GitHub Secrets

That would be great if Github CLI could support Secrets which are used in Github Actions. Do you have any plans for that?

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!

Thank 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).

I 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 Content

Hey, 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]...

@mislav

@mislav @billygriffin

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 pat
ghs 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 like gh doesn't officially address the use of them.

@unfor19

@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.SealedBox in pure Go so github-secrets-writer implements 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

@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

@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 summon by 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.token with the default being ~/.githubsecrets/default.token. This way you can call the wrapper without specifying GHS_PROFILE and it would just use the default.

With the above,

ghs secret-apply -p willy_wonka -r github-secrets

becomes

authenticated_ghs secret-apply -p willy_wonka -r github-secrets
// or GHS_PROFILE=not-default authenticated_ghs secret-apply -p willy_wonka -r github-secrets

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.

@mislav

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

@doodlesbykumbi

@doodlesbykumbi

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 😎

@doodlesbykumbi

@doodlesbykumbi you should totally contribute a PR to this project, if you have the time.

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

I 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!

I'll be taking this work on.

GitHub Actions secrets are now supported: https://github.com/cli/cli/releases/tag/v1.4.0

feat: Store conversation manager in session (cli#441)

Navigation Menu

Repository navigation

Support for GitHub Secrets #441

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for GitHub Secrets #441

Description

Activity

billygriffin commented on Feb 14, 2020

hleb-kastseika commented on Feb 14, 2020

AnthonyWC commented on Feb 14, 2020

doodlesbykumbi commented on Apr 5, 2020

unfor19 commented on Apr 11, 2020

unfor19 commented on Apr 15, 2020

doodlesbykumbi commented on Apr 15, 2020

unfor19 commented on Apr 15, 2020

doodlesbykumbi commented on Apr 15, 2020

doodlesbykumbi commented on Apr 15, 2020

unfor19 commented on Apr 16, 2020

vorburger commented on May 10, 2020

vorburger commented on May 10, 2020

doodlesbykumbi commented on May 10, 2020

mislav commented on May 11, 2020

raboley commented on Sep 6, 2020

vilmibm commented on Nov 19, 2020

mislav commented on Dec 15, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions