Skip to content
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

Add gh secret encrypt command to encrypt a secret locally without sending to GitHub #4388

Closed
shrink opened this issue Sep 29, 2021 · 6 comments · Fixed by #4423
Closed

Add gh secret encrypt command to encrypt a secret locally without sending to GitHub #4388

shrink opened this issue Sep 29, 2021 · 6 comments · Fixed by #4423
Labels
enhancement a request to improve CLI good first issue help wanted Contributions welcome

Comments

@shrink
Copy link

shrink commented Sep 29, 2021

Describe the feature or problem you’d like to solve

dev:~$ gh secret encrypt
Paste your secret: *************
✓ Encrypted secret for `org/repository`
QkMFB+vyCCE2yT5j6Tb07doxD2xKHagI2l6AjMuwUkizN7pMGXKBVOj154Pg/hwn0PbPWFvo83z+ir25iw==

Proposed solution

Separate the encryption step and make it available as a separate command so that users can easily generate an encrypted secret for their repository/organisation in infrastructure automation. An alternative might be a simple flag on set (e.g: --preview or --nowrite or --local) but I think that would be semantically incorrect (the meaning of set is explicit).

Additional context

There are hacks to grab the encrypted value now, like enabling debugging with API output which exposes the encrypted value in the request body -- and then deleted from the repository/organisation.

dev:~$ DEBUG=api gh secret set example

> PUT /repos/org/repository/actions/secrets/example HTTP/1.1
...

{
    "encrypted_value": "QkMFB+vyCCE2yT5j6Tb07doxD2xKHagI2l6AjMuwUkizN7pMGXKBVOj154Pg/hwn0PbPWFvo83z+ir25iw==",
    "key_id": "568250167242549743"
}

I'm happy to submit a Pull Request with an implementation for this if it's given the go-ahead.

@shrink shrink added the enhancement a request to improve CLI label Sep 29, 2021
@mislav
Copy link
Contributor

mislav commented Sep 30, 2021

Separate the encryption step and make it available as a separate command so that users can easily generate an encrypted secret for their repository/organisation in infrastructure automation.

Hi, why would you need to print an encrypted secret without storing the value to repository or org secrets on GitHub?

@shrink
Copy link
Author

shrink commented Sep 30, 2021

Hi, why would you need to print an encrypted secret without storing the value to repository or org secrets on GitHub?

Hi @mislav! The use-case I have in mind is specifically for infrastructure-as-code using Terraform. I am using infrastructure code to configure my Organization Secrets. Any value I provide to Terraform will be persisted in the Terraform State, and so if I pass in an unencrypted secret, the unencrypted secret will forever be a part of the infrastructure state (which is often uploaded to something like Azure Storage or Amazon S3).

resource "github_actions_organization_secret" "service_account_credentials" {
  secret_name     = "my_secret"
  visibility      = "all"
  plaintext_value = "Hello, World! This is my secret value that is encrypted in GitHub but recoverable from the infrastructure state."
}

If I encrypt it before it enters my infrastructure code then I do not have to worry about what happens to the value -- essentially, the same principle as gh encrypting locally, but the risk is accidental exposure by software I control rather than the network. My goal is to do something like...

resource "github_actions_organization_secret" "service_account_credentials" {
  secret_name     = "my_secret"
  visibility      = "all"
  encrypted_value = "QkMFB+vyCCE2yT5j6Tb07doxD2xKHagI2l6AjMuwUkizN7pMGXKBVOj154Pg/hwn0PbPWFvo83z+ir25iw=="
}

The official GitHub Terraform provider specifically encourages encrypting the secret locally before sharing it with Terraform:

It is also advised that you do not store plaintext values in your code but rather populate the encrypted_value using fields from a resource, data source or variable as, while encrypted in state, these will be easily accessible in your code.

The non-hack way to do this at the moment is by using the code snippets in the GitHub Documentation.

My current workflow is:

  1. Run DEBUG=api gh secret set example locally
  2. Extract the encrypted value from the api request body
  3. Add the encrypted value to my infrastructure code
  4. Visit my Organization on GitHub and delete the secret
  5. Run my infrastructure code so that the secret is re-added to GitHub

My ideal workflow would be:

  1. Run gh secret encrypt
  2. Add the encrypted value to my infrastructure code

Thanks,

@mislav
Copy link
Contributor

mislav commented Oct 1, 2021

The official GitHub Terraform provider specifically encourages encrypting the secret locally before sharing it with Terraform:

It is also advised that you do not store plaintext values in your code but rather populate the encrypted_value using fields from a resource, data source or variable as, while encrypted in state, these will be easily accessible in your code.

Interesting! Thank you for explaining.

It should definitely be easy for us to introduce an extra flag or command that causes the encrypted value to be printed instead of stored. Something like gh secret set -n/--no-store? I wanted to suggest that this doesn't warrant a separate command, but now that I think about it, a separate command makes the most sense 🤔 Anyway, contributions welcome!

@mislav mislav added good first issue help wanted Contributions welcome and removed needs-user-input labels Oct 1, 2021
@sguzmanm
Copy link
Contributor

sguzmanm commented Oct 3, 2021

Hi I see you need some help with this, is it OK if I give it a try? I'm trying to get myself into open source

@Sarahletty

This comment was marked as spam.

@Sarahletty

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement a request to improve CLI good first issue help wanted Contributions welcome
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants