Tom Parrott

> The reason for that is because if we detect that we have a new schema update, we can't be sure if this update is the one that introduces the...

@louiseschmidtgen please could you describe a scenario where the node name in the token payload could be abused? What impact would that have? Thanks @masnax i'd be interested to hear...

I see thanks. So the main complaint is that it is possible to derive which cluster member the join token was issued for from the join token itself and thus...

@beliaev-maksim the join token is currently made up of these elements: https://github.com/canonical/microcluster/blob/main/cluster/token_records.go#L45-L50 - The cluster member name who is joining - this is what is being proposed to be removed....

@beliaev-maksim > I could be mistaken, but it seems like the current approach protects against compromised or mocked clusters from accepting nodes. However, it doesn't guard against the opposite scenario...

The token itself is encoded (base64 iirc) so unless you're actively decoding it wouldn't make any difference to an end user admin. The docs might need improving to make it...

Join tokens were added to LXD as a more secure alternative to the long lived trust password which was historically required to join a cluster. The join tokens replaced this...

@bschimke95 its dependent on getting the MicroCloud token join stuff completed and on when MicroCeph Reef gets out. Plan is for around last days of May, first days of June...

Hi @niemeyer Thanks for the feedback. > The protocol as a whole may still be made safer, though, by changing what the cluster expects from the machine, thus making it...

Hi all, Our initial specification describing approaches to improve the microcloud cluster join process is available for review: https://discourse.ubuntu.com/t/secure-cluster-join-in-microcloud/44261 Thanks