-
Notifications
You must be signed in to change notification settings - Fork 30
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
[Feature] Filepath to paperkey. #40
Comments
Thanks for the feature request! I definitely like this feature and agree about this being useful if running inside Kubernetes. Are you still working on the associated PR or would you like me to take it over? |
If you wish you can take it over! I think only tests are left to check, while it is quite a small change in code, so you may decide what is best there, hehe. (It's drafted as #41) |
This is a very useful PR, but kubernetes does support injecting a secret into a container as an environment value, so that the key itself can be stored in a secret. I'm not sure if this fits your usecase, but it is an option. https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables |
Yes, secrets mounted as env variables exists and a good usecase when no alternative exists. Loosing the paperkey to a bot like this would be a huge issue, so personally I think that every possible security increase is a good thing! I understand that you had no objections to the pr and that the above was just a hint, just wanted to put my reasoning in print :) |
This is a feature request.
Background:
My production servers uses Kubernetes and I do not like to use environment variables for secure information (such as my keybase key!).
Most applications that I use in kubernetes I try to use
Secrets
mounted as a file into the containers and then load them from a file path.(Best case would be to be able to encrypt and decrypt in some way, but that is a later issue).
Implementation details:
To make this work for the Keybase sshca bot, it would require two new environment variables:
KEYBASE_PAPERKEY_PATH
KEYBASE_USERNAME_PATH
Before loading the current
KEYBASE_PAPERKEY
andKEYBASE_USERNAME
variables, a check is made to see if the*_PATH
variable/s are set. If so, the system tries to load those from disk.In case they are loaded successfully, they are used instead of the none
*_PATH
variables.If an error occurs or they are not set, the none
*_PATH
variables are used as of now and the same error handling that is implemented at the moment is used.Breaking changes:
This should not introduce any breaking changes.
I have started adding this in my fork which I will submit as a draft PR in a bit, but before I get the tests up and running, I will not submit a "real" pull request.
The text was updated successfully, but these errors were encountered: