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

Encrypt and store secret keys in private git repo #23

Open
MainShayne233 opened this issue Apr 30, 2020 · 4 comments
Open

Encrypt and store secret keys in private git repo #23

MainShayne233 opened this issue Apr 30, 2020 · 4 comments
Assignees
Labels
Dev Ops Might require going into DB or hosting service enhancement New feature or request help wanted Extra attention is needed

Comments

@MainShayne233
Copy link
Contributor

Situation

We have some API keys we want to keep secret, such as our Canvas API auth token. We should expect the amount of secrets to grow as we develop the app.

Current Method

The current method for keeping these secret is storing our app/canvas.py (which currently has all of them) file in Google Drive and downloading it whenever setting up a new repo.

Reasons for Change

This is working for the moment, but I see/foresee the following issues:

  • app/canvas.py contains more than just secrets, and it'd make sense to only have the secrets stored privately and not any application code.
  • We can't currently easily run the app or tests in CI without shimming a app/canvas.py into place, and even then the app fails if it can't auth with the services correctly
  • If we need to add more secrets that aren't related to app/canvas.py, we'll have to store even more files in Google Drive.
  • There aren't many easy ways to programatically access the app/canvas.py from Google Drive, so any time we need to access it requires a manual process.

Proposed Method

(This method is based on how we managed our secret keys at a previous company I worked at)

Private Git Repo

Now that we have a GitHub organization, we can create a free private GitHub repo that will be where the secrets are stored. The secrets can be stored in a really plain/easy to parse format such as JSON, YAML, or even as .env files. This way, we can have them get automatically imported into our app as long as they are available on the running machine and in the expected path in the app repo.

Encryption

We will never put the secret keys into the GitHub repo without first encrypting them. There's a really cool tool called ansible-vault that allows you to easily encrypt files and edit them as needed as long as you have the encryption key. This encryption key is something we can store in a shared password manager, such as LastPass, so that whomever needs access to the secrets can have it.

How It Would Work In Practice

Setup for development

If you were setting the app up for development, all you'd need to do is:

  • Clone the app repo
  • Have access to the encryption token stored in the password manager
  • Run a script (./bin/dev/setup-secrets <encryption-key>) and it would:
  • automatically clone the secrets repo into a temp directory
  • decrypt the secrets and place them in the app repo where the app expects them to be
  • deletes the temp secrets repo

Setup for CI

CI may or may not need any secrets, but if it ends up needing some, we can easily run the procedure above in the CI setup.

Setup for production

Production will certainly need the secrets, and we can include the steps above for pulling the latest secrets from GitHub whenever the app is deployed.

Modifying Secrets

Whenever you need to change, add, or remove secrets, it's as simple as running ansible-vault edit path/to/encrypted/secrets/file and it will open up the file in a text editor where you can make any changes you want, and then you'd simply push this change to the GitHub repo.

Pros

  • We only store secrets, not application code
  • Secrets are readily available for development, CI, production etc, and can always be automatically accessed by any scripts we write.
  • Secrets are version controlled so we can track changes to them
  • This will easily handle any future secrets we need to add
  • All the tools being used are free
  • I know how to do the setup for this :)
@MainShayne233 MainShayne233 self-assigned this Apr 30, 2020
@MainShayne233 MainShayne233 added Dev Ops Might require going into DB or hosting service enhancement New feature or request labels Apr 30, 2020
@MainShayne233
Copy link
Contributor Author

@AustinCundiff , as someone who I'm sure has far more security experience than me, how does this sound to you?

@AustinCundiff
Copy link
Collaborator

I've never heard of ansible-vault. That's pretty rad. I don't consider myself a devops expert, but I think this is definitely thorough and certainly sufficient for this project. I'm just glad there are no secrets being stored in public GitHub code.

The only improvement I can think of would be involving physical tokens, but don't think that would be worth the effort in this case (yubikeys aren't cheap either).

@MainShayne233
Copy link
Contributor Author

Dang yeah, yubikeys for everyone would be awesome, but probably won’t comply with our $free.99 budget. 😛

Appreciate the feedback! Also, nice to meet you! 🙂

@lcundiff
Copy link
Member

lcundiff commented Aug 3, 2020

This has been successfully implemented by @MainShayne233

Set up guide can be found here:
@AustinCundiff if you have a really free rainy day, let us know if there's any blank spots.

@lcundiff lcundiff added the help wanted Extra attention is needed label Feb 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dev Ops Might require going into DB or hosting service enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants