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

Uh oh!

Support for GitHub Secrets #441

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions