netgoat reverse proxy – "seriously messed up code"
- 0 Followers
- 0 Following
- 1 Posts
To be fair, the proxy engine is supposedly written in go, not in nodejs, but yeah, the ddos defense most likely is wishful thinking…
The annoyance grows with the number of hosts ;-) I still want to feel in control, which is why I’m hesitant to implement unattended decryption like with tang/clevis.
But I’m interested in the idea of not messing with the initrd-image, boot into a running system and then wait for decryption of a data-partition. Isn’t it a hassle to manually override all the relevant service declarations etc. to wait for the mount? Or how do you do that?
The passphrase should be stored and transferred encrypted, but that would basically mean reimplementing mandos, a tool that was mentioned in another reply https://lemmy.world/post/38400013/20341900. Besides that yes, that’s one way I’ve also considered. An ansible script with access to all encrypted host’s initrd-ssh-keys that tries to login; if the host is waiting for decryption, provides the key, done. Needs one webhook for notification and one for me to trigger the playbook run… Maybe I will revisit this…
oidc-based remote luks decryption – bad idea? - Lemmy.World
Hey everyone, here’s an idea, what do you think? (Please stop me…) I have a few remote servers where disk encryption is only a moderately important measure; I definitely want to keep it but I’m also annoyed by having to ssh into it during the initrd-phase to provide a passkey on every reboot. What I would like is to get a notification with a link to my idp for some device flow, allowing me to authorize the server to obtain the secrets necessary for decryption. As far as I can tell, this hasn’t been done before, or have I missed something? A naive idea would be to have custom oidc-claims for the different servers where the value is the luks-passphrase. Feels like a bad idea, though. Any ideas on the details as to how? I obviously don’t want to bloat my initrd-image, so a bash script using curl would be ideal.
It wasn’t clear to me at first glance how the mandos server gets the approval to supply the client with its desired key, but I figured it out in the meantime: that’s done through the mandos-monitor tui. However, that doesn’t quite fit my ux-expectations. Thanks for mentioning it, though. It’s an interesting project I will keep in mind.
Definitely! I have bmc/kvm everywhere (well, everywhere that matters).
I have talked myself out of this (for now), though. I think if I ever find the time to revisit this, I will try to to it by injecting some oidc-based approval (memo to myself: ciba flow?) into something like clevis/tang.
Sort of, but this seems a bit heavy. (That being said, I was also considering pkcs#11 on a net-hsm, which seems to do basically the same…)
Yes, I was thinking about storing encrypted keys, but still, using claims is clearly just wrong… Using a vault to store the key is probably the way to go, even though it adds another service the setup depends on.