This changes our install strategy by first creating the ssh keys, disk-encryption keys and other machine-specific secrets locally, allowing sops secrets to be reencrypted for the host before deploying it. Also the ssh keys will be consistent even with reinstalls, which lowers the effort required.
This changes our install strategy by first creating the ssh keys, disk-encryption keys and other machine-specific secrets locally, allowing sops secrets to be reencrypted for the host before deploying it. Also the ssh keys will be consistent even with reinstalls, which lowers the effort required.
Iam wondering a bit why the introduction of keepass is necessary for this. Besides bringing in a second secret managment solution i fear unsolvable merge conflicts due to the binary nature of keepass db.
By looking at scripts/add_new_host_keys.sh and scripts/remote-install-encrypt.sh it seems that all the functionality can also be implemented using pure sops files encrypted with the admin keys. Is there any specific reason for going with keepass here that i overlooked?
Iam wondering a bit why the introduction of keepass is necessary for this. Besides bringing in a second secret managment solution i fear unsolvable merge conflicts due to the binary nature of keepass db.
By looking at scripts/add_new_host_keys.sh and scripts/remote-install-encrypt.sh it seems that all the functionality can also be implemented using pure sops files encrypted with the admin keys. Is there any specific reason for going with keepass here that i overlooked?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
kalipso
This changes our install strategy by first creating the ssh keys, disk-encryption keys and other machine-specific secrets locally, allowing sops secrets to be reencrypted for the host before deploying it. Also the ssh keys will be consistent even with reinstalls, which lowers the effort required.
Todo: Move all other hosts to db
Iam wondering a bit why the introduction of keepass is necessary for this. Besides bringing in a second secret managment solution i fear unsolvable merge conflicts due to the binary nature of keepass db.
By looking at scripts/add_new_host_keys.sh and scripts/remote-install-encrypt.sh it seems that all the functionality can also be implemented using pure sops files encrypted with the admin keys. Is there any specific reason for going with keepass here that i overlooked?
You are right. I changed the scripts to use sops
Nice thats great, thanks a lot!
@@ -13,3 +13,3 @@- &machine_overwatch age1psj6aeu03s2k4zdfcte89nj4fw95xgk4e7yr3e6k6u2evq84ng3s57p6f0- &machine_vpn age1v6uxwej4nlrpfanr9js7x6059mtvyg4fw50pzt0a2kt3ahk7edlslafeuh- &machine_fanny age136sz3lzhxf74ryruvq34d4tmmxnezkqkgu6zqa3dm582c22fgejqagrqxk- &machine_fanny age1u6ljjefkyy242xxtpm65v8dl908efnpt4txjkh0c9emvagdv8etqt22wllI wonder if you generated new host keys for fanny? I could also enter the existing ones so we dont have to do fresh install again
Yes, pulling the existing keys is better but since fanny is down currently that'll have to wait
Alright makes sense. Fanny is currently booting, so this can be taken care of soon!
merged manually
Pull request closed