ฝัง
- เผยแพร่เมื่อ 7 ธ.ค. 2021
- See how Mozilla SOPS can make your life easier, if you need to manage secrets as distributed systems engineer.
--- Related
Mozilla SOPS: github.com/mozilla/sops
Age: github.com/FiloSottile/age
--- Quick Bytes
Quick Bytes are a series of short but precise videos presenting one specific topic. The content ranges from short tutorials, tooling demonstrations and neat little tricks, to language features and basic concepts. They are not limited to rustlang as a language, but will cover other environments and languages as well.
--- Follow Me
Twitter: / jakobwesthoff
Twitch: twitch.com/mr_jakob
Github: github.com/jakobwesthoff
--- Support Me
Amazon Wishlist: www.amazon.de/hz/wishlist/ls/...
#encryption #helm #k8s - วิทยาศาสตร์และเทคโนโลยี
Hi Jakob, Thanks for sharing your experience regarding SOPS with us. I was wondering how do you share the private keys with other devs? Thanks again.
We actually don’t share the private keys. That is the beauty of asymmetric encryption. Each dev generates the private/public key combo themselves and takes care of keeping the private part secret. The public key is communicated and used for encryption.
@@MrJakob Thanks for your time. Here is what I am trying to understand. Say Dev1 encrypted a config file and pushed it to Git. Now Dev2 pulls the same repo and needs to update the config. He'll first need to decrypt it before he could update and re-encrypt the config file, correct? How will he decrypt the config file if he doesn't have the private key of Dev1.
I see. First of all there seems to be a general misconception: Nobody ever must have access to the private key of another developer. That would compromise the whole idea of asymmetric encryption. Even though I am usually doing things a little bit different, than you are describing them, let me explain how things would work out in your scenario:
Dev1 has is own private/public keypair, which he/she uses to encrypt secrets and commit them to the git repository. Once Dev2 joins the team for example, he/she communicates his *public* key to anyone with access (Dev1 in this case). Dev1 then adds the pubkey of Dev2 to the list of people with access and reencrypts the secrets file. After that Dev2 can access the file using his own private key, without the private key ever leaving his/her system.
Each change from this time on is encrypted with all the different pubkeys, which should have access. Therefore any change can automatically be used by everyone who should be able to.
I hope this clears up the idea behind the whole which key for what situation.
@@MrJakob Make sense. Thanks Jakob.
@@MrJakob Great explanation !! Appreciate it