-
Notifications
You must be signed in to change notification settings - Fork 17
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
How to store secrets #25
Comments
Questions:
If our only secret is a Github API token, and it is only used by Snabb Bot, and we can revoke it and issue a new one at any time, then I don't think Blackbox helps us. However, we might want to either setup a minimal secure environment for running Snabb Bot or make sure the secrets are not dangerous. I am not sure what secrets Hydra uses...? Could be that running both Hydra and NixOps on the same server is problematic i.e. giving the whole community root access to the CI machine. Could consider separating those somehow. |
Currently we have two for Hydra. One to sign built packages and one SSH key pair for Hydra to access build slaves. These keys are now present on In very soon future we'll need GitHub API token for Snabb Bot as you've said. If that's read-only token we can expose it to public as it's public access anyway. I would limit access to |
We could just use nixops to copy them on bootstrap: http://permalink.gmane.org/gmane.linux.distributions.nixos/20368 |
We'll need this very very soon now that davos is running NixOS. cc @eugeneia |
Current solution is to store GitHub credentials for SnabbBot on eiger. For now I am satisfied with that. My proposed solution is to have a private repository that is a fork of snabblab-nixos which has a long lived branch that adds the secrets. |
I'd do that + encrypting the files and sharing the key only through private conversations. |
Encrypting anything seems overkill to me. Just have the secrets in a private repo, give access only to people who have to touch eiger. E.g. repo acess would be the key. |
With Hydra and snabb bot we have to store secrets besides the deployment. We don't want them to be exposed, so maybe we should consider encrypting them into git.
https://github.com/StackExchange/blackbox
The text was updated successfully, but these errors were encountered: