| 10 Feb 2022 |
Zhaofeng Li | * An alternative solution is with short-lived SSH certificates, signed by an SSH CA that relies on some other authentication methods (OIDC, GitHub, etc.). Instead of allowing specific keys, the servers will simply trust the CA. | 04:21:30 |
Zhaofeng Li | That said, some "hardware crypto wallet"-like thing would definitely be cool | 04:22:08 |
Buckley | I just unlock the smartcard and it works until i yank it out | 04:22:10 |
Zhaofeng Li | ... perhaps a little LCD display that shows you the hostname and the command | 04:23:23 |
Winter (she/her) | In reply to @buckley310:matrix.org I just unlock the smartcard and it works until i yank it out ~~but then random software can use it~~ | 04:26:22 |
Buckley | its not perfect | 04:26:47 |
Winter (she/her) | seems like no solution is | 04:42:50 |
Winter (she/her) | which is what i'm complaining about, lol
isn't ideal but it's what we have, ig | 04:43:10 |
Winter (she/her) | the SSH certificate thing looks cool, i'll definitely look into it -- how do you handle stuff like Git forges who won't trust CAs, tho? do you just have a key for those? | 04:44:23 |
Zhaofeng Li | For the random software problem, perhaps we need stronger compartmentization between applications, like in Qubes and lately SpectrumOS (with Nix) | 04:44:48 |
Zhaofeng Li | In reply to @winterqt:nixos.dev the SSH certificate thing looks cool, i'll definitely look into it -- how do you handle stuff like Git forges who won't trust CAs, tho? do you just have a key for those? True, for those use cases you would still need a regular key 🙁 | 04:45:38 |
Winter (she/her) | how well does Vault work as a CA, btw? | 04:56:30 |
Zhaofeng Li | In reply to @winterqt:nixos.dev how well does Vault work as a CA, btw? Fairly usable I'd say. The user experience is slightly awkward for the client certificate, because you pretty much need a helper script or alias to avoid typing the long vault ssh ... or vault login && vault write ... && ssh incantation | 05:10:23 |
Zhaofeng Li | I followed this blog post for the setup: https://brian-candler.medium.com/using-hashicorp-vault-as-an-ssh-certificate-authority-14d713673c9a | 05:11:35 |
Winter (she/her) | hm, neat. | 13:33:51 |
@github:maunium.net | [zhaofengli/colmena] pinpox opened
issue
#57: Option to remove secrets
Would it be possible to add some mechanism to remove secrets when they are removed from the configuration?
Consider two configured secrets like this:
keys = {
"test-secret1" = {
keyCommand = [ "pass" "show" "nixos-secrets/ahorn/borg/passphrase" ];
destDir = "/var/src/colmena-keys";
};
};
| 14:01:20 |
@github:maunium.net | [zhaofengli/colmena] pinpox edited
issue
#57: Option to remove secrets
| 14:03:44 |
@github:maunium.net | [zhaofengli/colmena] pinpox edited
issue
#57: Option to remove secrets
| 14:06:04 |
| pinpox joined the room. | 14:16:35 |
pinpox | Whops, sorry for the "edited issue.." spam. | 14:17:32 |
pinpox | Hey, does anyone have a solution on how to make sure secrets no longer present in deployment.keys are deleted? | 16:03:29 |
pinpox | Can I use system.activationScripts for it? | 16:03:42 |
Jane Jasperous | Maybe you can deploy into tmpfs and use impermanence module | 16:11:53 |
Zhaofeng Li | In reply to @pinpox:matrix.org Can I use system.activationScripts for it? I commented with a potential solution. | 18:57:37 |
Zhaofeng Li | In reply to @pinpox:matrix.org Whops, sorry for the "edited issue.." spam. No worries - I'm planning to replace the bot regardless since it's pretty spammy even in the normal case (3 link previews for a message) | 18:58:17 |
| 11 Feb 2022 |
pinpox | Zhaofeng Li: Just saw it, thank you! | 07:43:22 |
pinpox | That is a possible solution, but wouldn't it be nice to have an option to execute commands preo/post deployment anyways? I imagine that could come in handy regardless of secrets | 07:44:10 |
| Chinchilla Washington joined the room. | 07:51:13 |
@github:maunium.net | [zhaofengli/colmena] Repo forked into lheckemann/colmena | 14:41:31 |
@github:maunium.net | [zhaofengli/colmena] lheckemann opened
pull request
#58: streaming evaluator: respect eval-nodes-limit
| 14:42:02 |