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

[Feature] Filepath to paperkey. #40

Open
Johannestegner opened this issue Aug 30, 2019 · 4 comments
Open

[Feature] Filepath to paperkey. #40

Johannestegner opened this issue Aug 30, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@Johannestegner
Copy link
Contributor

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 and KEYBASE_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.

@Johannestegner Johannestegner mentioned this issue Aug 30, 2019
3 tasks
@ddworken
Copy link
Contributor

ddworken commented Sep 4, 2019

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?

@Johannestegner
Copy link
Contributor Author

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.
I'll gladly finish it of when I have time later if there are more pressing things for you to fix though :)

(It's drafted as #41)

@aditsachde
Copy link

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

@Johannestegner
Copy link
Contributor Author

Yes, secrets mounted as env variables exists and a good usecase when no alternative exists.
There are though some potential issues with env variables (maybe not a huge issue in this app) which secrets as files don't have.

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 :)

@mmou mmou added the enhancement New feature or request label Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants