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 REQUEST] File encryption functionality for storing encrypted files on git #125

Open
mldev94 opened this issue Aug 9, 2023 · 1 comment

Comments

@mldev94
Copy link

mldev94 commented Aug 9, 2023

File encryption functionality for storing encrypted files using k8t would be very similar to "ansible-vault" and how "ansible" works.

Not every file needs to be encrypted but if there is something that needs to be encrypted while the data is at-rest. This feature can be super useful.

  • For the encrypted files, k8t would "automatically" decrypt the encrypted ".yaml.j2.enc" files in "memory" while generating the final "yaml" with "k8t gen -e production". If the file doesn't end with ".enc", it wouldn't decrypt, it would just the file as-is.

so that we could use a command like this below to run final "yaml" file on kubectl without revealing the decrypted files anywhere on the disk since everything would be done in-memory:

k8t gen -e production | kubectl apply -f -


There would be three commands for editing or viewing encrypted files if any manual operation is needed without "generating" anything with "k8t gen" or when we need to edit files

  • k8t-vault init ~/.my-secrets/k8t-key # creates the initial key that would be used for all the k8t-vault and k8t operations.
  • that key's location can be provided in config.yml. k8t wouldn't be able to decrypt and do "k8t gen" without the key existing in that location
  • k8t-vault encrypt ./repository/filename.yaml
  • k8t-vault edit ./repository/filename.yaml.enc #opens the default text editor "vi", "nano" by decrypting into a tmp directory and then encrypting and putting back to "./repository/filename.yaml.enc" and deleting the decrypted file in that tmp directory on save.
  • k8t-vault decrypt ./repository/filename.yaml.enc

With that encryption key "k8t" created once at first while initializing the k8t directory, the developers can share that key outside of the git repository(through encrypted e-mail, slack, or any other secure methods).

That key can be used by anyone who pulls the git repo of the project and let them decrypt those files automatically while using k8t-gen to create final "yaml" files

Other than that, files would stay encrypted while the data is at-rest on git repositories and would look like this:

---some-secret.j2.yaml.enc:
$ANSIBLE_VAULT;1.1;AES256
      62313365396662343061393464336163383764373764613633653634306231386433626436623361
      6134333665353966363534333632666535333761666131620a663537646436643839616531643561
      63396265333966386166373632626539326166353965363262633030333630313338646335303630
      3438626666666137650a353638643435666633633964366338633066623234616432373231333331
      6564

Example from ansible but "ANSIBLE_VAULT" can become "K8T_VAULT" as an identifier for this feature.

Whenever any of the encrypted files are pushed to a git repository, they would be pushed encrypted.

@AFriemann
Copy link
Member

AFriemann commented Aug 14, 2023

hey @mldev94 - I took a quick look at your PR and don't think this integrates too well..

The right approach, I think, would be to introduce a new secret provider that takes the .enc files, decrypts them using ansible-vault in memory and pulls keys from there. Encryption would be handled as always with ansible-vault when creating the file.

TBF though I'm not sure if we can add this. We're migrating to helm internally so there's very little time left for this project. If you'd still like to contribute this as I suggested I'd be happy to help you through that and get it merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants