1
0
Fork 0
forked from Fediversity/meta

update meeting notes as per ssh meeting, feedback on design minutes

This commit is contained in:
Kiara Grouwstra 2025-04-01 12:36:14 +02:00
parent 1c617dce0c
commit a5670bb674
No known key found for this signature in database
2 changed files with 23 additions and 34 deletions

View file

@ -39,49 +39,38 @@ some notes on our current status, challenges and ways to address these
### how to use SSH on deployment ### how to use SSH on deployment
[^temp]: for now, as per the scope of #274
[^sensitive]: must be password-protected
[^agent]: thru ssh agent
[^inaccessible]: fails to handle password protection
[^propagate]: with password propagated, somehow
[^hardcoded]: hard-coded
[^explicit]: password can be passed explicitly
[^either]: unprotected, or if protected by passing it explicitly
#### user #### user
(note that `desired` columns are focused on the scope of #76, so keeping e.g. security considerations out of scope.)
| context | current | desired |
|-|-|-| |-|-|-|
| context | current | desired[^temp] |
| nixops infra | root | root | | nixops infra | root | root |
| nixops local | root | root | | nixops local | root | root |
| protected? nixops panel local | root | root | | protected? nixops panel local | root | root |
| nixops panel deployed | root | root | | nixops panel deployed | root | root |
<!-- | tf infra | root | root | --> | tf local | personal (hard-coded) | root |
| tf local | personal[^hardcoded] | root | | protected? tf panel local | personal (hard-coded) | root |
| protected? tf panel local | personal[^hardcoded] | root | | tf panel deployed | personal (hard-coded) | root |
| tf panel deployed | personal[^hardcoded] | root | | tf infra | root | root |
#### key #### key
|-|-|-|
| context | current | desired | | context | current | desired |
| nixops infra | personal[^agent] | (protected) personal key | |-|-|-|
| nixops local | personal[^agent] | personal | | nixops infra | personal (thru ssh agent) | (protected) personal key |
| nixops panel local | personal[^agent] [^inaccessible] | (unprotected) personal key | | nixops local | personal (thru ssh agent) | personal |
| nixops panel deployed | machine key[^agent] | machine key | | nixops panel local | personal (thru ssh agent, failed to handle password protection) | (unprotected) personal key |
<!-- | tf infra | n/a | (protected) personal key [^propagate] | --> | nixops panel deployed | machine key (thru ssh agent) | machine key |
| tf local | personal[^agent] [^explicit] | personal[^either] | | tf local | personal (thru ssh agent, password can be passed explicitly) | personal (unprotected, or if protected by passing it explicitly) |
| tf panel local | personal[^agent] [^explicit] | personal[^either] | | tf panel local | personal (thru ssh agent, password can be passed explicitly) | personal (unprotected, or if protected by passing it explicitly) |
| tf panel deployed | machine key[^agent] | machine key | | tf panel deployed | machine key (thru ssh agent) | machine key |
| tf infra | n/a | (protected) personal key (with password propagated, somehow) |
## solutions ## outcomes
- [x] fix ssh user in #274 added sub-tasks to:
- [ ] fix ssh access on test03
- [?] mimic strategy used with nixops for TF for ssh access from panel (deployed) - #272
- [ ] allow access by machine key? or.. how did nixops have access? - #76
- [ ] use/allow separate unprotected SSH key for test0x VMs (#272) - #274
- [ ] ensure whitelisted keys for infra are protected
- [ ] work out way to use password-protected ssh keys in TF for infra? e.g.:
- delegate to ssh agent
- pass explicitly

View file

@ -35,7 +35,7 @@ Present: {thijs,timon}@slik, {koen,kevin,kiara}@procolix
- koen: we should show those from the panel, but there are different ways to approach this as per an operator's business model - koen: we should show those from the panel, but there are different ways to approach this as per an operator's business model
- thijs: maybe hosts should get to choose how to approach this - thijs: maybe hosts should get to choose how to approach this
- koen: agree, companies will have limited resources and may prefer to not make things too granular, tho in larger set-ups one may need to be able to better justify how pricing scales - koen: agree, companies will have limited resources and may prefer to not make things too granular, tho in larger set-ups one may need to be able to better justify how pricing scales
- thijs: do we always want granular pricing? - thijs: do we always want to add a link to the price/value breakdown for every plan?
- koen: by default yes, if you don't want that, it's open-source so you can fork if you like - koen: by default yes, if you don't want that, it's open-source so you can fork if you like
- thijs: thanks - what else should we change for tomorrow? - thijs: thanks - what else should we change for tomorrow?
- koen: maybe add graphs over time on disk space and number of applications deployed - koen: maybe add graphs over time on disk space and number of applications deployed