How to find peer `id` properly in `clever ng leave`?

[RemiBardon]

Context

When a user joins a networkgroup, we add an external peer with an id. When he leaves, we delete the associated external peer.

As @Keruspe had proposed, it would be great to have a dedicated clever ng leave that allows the user to leave a networkgroup if something bad happened and the external peer hasn't been removed as planned.

Problem

The problem is that we do not have a way to find the id outside of the clever ng join command.

Remark: As discussed in ovd#27 (internal GitLab), we cannot use the host name to uniquely identify a peer.

Proposed solutions

I have different propositions, let me know what you think works best:

1. We do like wg-quick which stores a <name_of_wg_conf>.name file somewhere which contains the name of the associated interface: We would have a <name_of_wg_conf>.id in /tmp/com.clever-cloud.com/networkgroups which would contain the peer_id associated to the computer.
2. 1. ~~We get the computer's IP address (inside the VPN) from the WireGuard® configuration file.~~
   2. ~~We call the API to retrieve the peers list, and we search through it to find the id of the external peer.~~
3. ~~We create a new endpoint to the Networkgroups API which does the search from point 2., and which returns the id.~~
4. We let the user automate idrecovery or we let them do it by hand (find themselves in clever ng peers list), but it remove the magic of it 🧙
5. 1. We take the private key from the WireGuard® configuration file (assuming it hasn't been deleted when something bad happened).
   2. We transform it to a public key.
   3. We add an endpoint to the Networkgroups API which allows removing a peer from its public key (and ng_id of course).

[RemiBardon]

With @moyowi, we rejected 2. and 3. for security reasons.

An example would be:

1. Someone joins a networkgroup with IP address XXX.XXX.XXX.12
2. They crash
3. They are removed for some reason
4. Someone else joins and gets the same IP address (we cycled through all adresses available for example)
5. User 1 asks to be removed
6. User 2 is removed instead

QED.

[RemiBardon]

For now, we'll use the first option. If needed, we'll switch to option 5..

[RemiBardon]

I just thought about something: If a user joins a networkgroup, has a problem, then joins it again, the <name_of_wg_conf>.id file will be overwritten.

I have two propositions in mind:

1. Create a <name_of_wg_conf>.ids file instead, with one peer_id by line. It would allow fast reading but needs appending text and doesn't easily allow removing only one peer_id.
2. Create multiple <name_of_wg_conf>-<random>.id files. It would be harder to find all the peer_ids, but we would be able to delete them one by one more easily.

Since we don't need to delete peer_ids one by one, I would suggest option 1.. What do you think?

[divarvel]

I'm just lurking, and i'm curious about all the files mentioned. Where are they stored? On clever-cloud instances, or on the machine running clever-tools?

[RemiBardon]

It's not released yet, but we're talking about files on the machine running clever-tools. They will be stored in one's OS temporary folder (e.g. /tmp) and automatically deleted either by the OS or clever-tools.

[RemiBardon]

We would have preferred not storing files, but unfortunately WireGuard®'s wg-quick command doesn't take in-memory files 😕

[divarvel]

ah, so it's not possible to use file descriptors :-( but they're only used temporarily, just to call wg-quick and are not kept from run to run :relieved:

[divarvel]

thanks for taking the time to indulge my curiosity!

[RemiBardon]

Glad I could help 🙂

[RemiBardon]

https://github.com/CleverCloud/clever-tools/issues/457#issuecomment-778221352

@Keruspe What's your thought on this?