rfc: node access #3051
rfc: node access #3051
Conversation
burgerdev
requested review from
malt3,
m1ghtym0,
3u13r,
elchead,
thomasten,
msanft and
daniel-weisse
✅ Deploy Preview for constellation-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| ### SSH with Authorized Keys | ||
|
|
||
| We could ask users to add a public key to their `constellation-conf.yaml` and add that to `/root/.ssh/authorized_keys` after joining. | ||
| This would require the cluster owner to permanently manage a second secret, and there would be no built-in way to revoke access. |
There was a problem hiding this comment.
We actually used to do this, but decided to remove it in v2.2.0.
I like the proposed design a lot better, since it makes distributing the SSH access (i.e. the SSH CA) to other nodes of the cluster a lot easier.
rfc/016-node-access.md
Outdated
|
|
||
| An OpenSSH server is added to the node image software stack. | ||
| It's configured with a `TrustedUserCAKeys` file that is empty on startup. | ||
| After initialization, the bootstrapper fills that file with the derived CA's public key. |
There was a problem hiding this comment.
Just as a side note: Worker nodes don't have access to the master secret, so we will need to generate and distribute the CA during the join process.
There was a problem hiding this comment.
Proposing to only keep the CA in the join server, ptal
rfc/016-node-access.md
Outdated
|
|
||
| ### Client-side Details | ||
|
|
||
| A new subcommand `constellation credentials ssh` is added to the CLI. |
There was a problem hiding this comment.
nit: We may want to use a different parent command name, e.g. key-gen or key so we can bundle things like data encryption key generation under this command.
credentials also works, but seems a bit less on topic for the other key gen operations.
There was a problem hiding this comment.
I left the exact placement of the subcommand open for now.
| The choice of curve allows to directly use the derived secret bytes as key. | ||
| This makes the implementation deterministic, and thus the CA key recoverable. | ||
|
|
||
| ### Server-side Details |
There was a problem hiding this comment.
We should also enable SSH host certificates on the Constellation nodes.
This should ensure a user is actually talking to a Constellation node over SSH, not just any VM that accepted the SSH key.
There was a problem hiding this comment.
Added host certs to the proposal.
rfc/016-node-access.md
Outdated
| ### Server-side Details | ||
|
|
||
| An OpenSSH server is added to the node image software stack. | ||
| It's configured with a `TrustedUserCAKeys` file that is empty on startup. |
There was a problem hiding this comment.
Should we also have some CRL-alike thing that'd enable an administrator to revoke access for a specific key? In theory, you'd have to throw away your cluster anyway, as it might've been backdoored in such a case. But for real-world scenarios, revoking keys might be handy.
There was a problem hiding this comment.
Added KRL as an option for the admin - no real complexity added for us, but as mentioned it's probably not useful in general.
|
This is good to go as far as I'm concerned. Please let me know until 2024-05-21 if you'd like to see modifications. |
Context
This RFC proposes a mechanism for accessing Constellation nodes for maintenance.
Checklist