Generate configuration for non-Ansible peers

[ypid]

Similar to #63, cc @joneskoo but the other way around.

What do you think about an option where the role could generate ready to use WireGuard configuration files that are not Ansible managed (for example phones). The convenient way to do this is to generate the private key, template the configuration and then provide it to the end device.

For implementation, I am thinking about adding those hosts actually to the Ansible inventory but with connection local. Then run the role against them and have the config redirected into a "secret" directory on the Ansible controller. I have done something like this with https://github.com/ypid/ansible-packages already. Works.

See also #65 (comment) and #66 for my background.

[joneskoo]

What I had in mind is to dump all Ansible managed peers to a file - that only includes the public keys and requires generating the top part of the config externally. Outside of this role responsibility.

Maybe with better understanding of use cases it's easier to say where this falls short and whether it is relevant to keep that complexity in this role or not.

I'd suggest to not include to this role anything where the controller has private keya of any host for philosophical and best practices reasons but ultimately this judgement call can only be made by the maintainer of the project.

With all the information it's easier to make the right call so maybe you can elaborate?

[ypid]

What I had in mind is to dump all Ansible managed peers to a file

So the workflow would look like this:

1. Run this role against managed hosts. The role dumps the public keys and other needed information somehow. Ansible local facts dumped to files come to my mind. Ref: Add save_ansible_facts.yml playbook for saving facts "in-tree" fboender/ansible-cmdb#168
2. Run some external script that reads the JSON files, generates private keys? and templates a configuration file.
3. The script would also need to write the generated public keys back to Ansible so that the role can deploy them to the managed hosts for them to accept the new "unmanaged" hosts. I guess you are thinking of doing it manually with Add support for unmanaged WireGuard peers #63 or using some lookup plugin?

One downside I see here is that the config template would need to be duplicated. Another one that it requires an external tool.

I'd suggest to not include to this role anything where the controller has private keya of any host for philosophical and best practices reasons

I talked about my view on this in #65 (comment). What is your threat model where it helps that the Ansible controller does not have the private keys? I can only think of one right now: Where the managed hosts is one time configured and then the Ansible controller cannot access it again. Otherwise, the Ansible controller will remain to have (root) access and could retrieve the key as needed. I expect that the Ansible controller is adequately protected by encryption and the like. Am I missing something?

With all the information it's easier to make the right call so maybe you can elaborate?

Add unmanaged peers like phones to WireGuard VPNs.

But there is a second use case. There was discussion over at StreisandEffect/discussions#63 if DebOps could be the foundation for the project. I also have this in the back of my mind as WireGuard support for DebOps should also support this.

[joneskoo]

Basically, with the controller having private keys it changes what would otherwise require an active attack to just making a copy of the private keys passively. The less stored the better. The window of attack is reduced, and potentially active attack may leave more trail. The one shot configuration you described is plausible too.

My use case for unmanaged peers is e.g. laptops etc that I don't configure as Ansible. Being able to paste/concatenate the peers to a config is sufficient. Currently I gather that manually from two hosts, but ideally ansible should write the peers config optionally to a local file. I guess that's exactly this issue?

The flow you describe is not needed. If you want to make another role that works together with this, you would:

1. Generate private key for external client - no changes in this role
2. Configure it as unmanaged peer in this role - execute this role only once
3. Complete the external config by concatenating the ansible managed peers to the stub config from 1.

For what I wanted, export sufficient information (example for generating peers section, or write it as local file).

For you, you'd additionally generate the private key as I just described. This role would not include the private key on host, it would be external code. I don't see any benefit including that logic in this role; it's specific to how you use this, and someone else could do something different.

[ypid]

The less stored the better.

I agree with that statement. It is basically the principle of least authority.

That said, it is difficult to exclude the Ansible controller from the TCB because it probably has root access to managed hosts. Still, the WireGuard role is special here because it configures VPN services which could be more interesting to an attacker. I am not against the principle of least authority, it is just that for me it has more downsides than advantages, refer to #65 (comment):

So I would at least propose a second mode where private keys are generated/stored on the Ansible controller and distributed from there.

And just to finish the threat model that you nicely started. A "passive" attack, copying the clear text content of the Ansible controller, would be devastating even without this role writing secret keys there. Remember that I am proposing to store the private keys using some form of file-level encryption on the Ansible controller obviously. With such an attack, the attacker would also have your SSH keys and similar. I hope you see my point. That is why the Ansible controller needs to be protected in other additional ways. Such a passive attack cannot be allowed.

Also, the second mode should not be default following the principle of least authority.

I guess that's exactly this issue?

👍

I don't see any benefit including that logic in this role

The benefit I see is sharing code. For example the template and key generation code. Can all be shared with my proposal of adding the unmanaged peers to the Ansible inventory. Anyway, I guess I will need to provide code to make that more obvious. But the code will make use of DebOps concepts, so be warned :) But it will be easy to use this without the full DebOps stack. The flow as I have it in mind will only need one role run and job done. No manual fiddling required.

[ypid]

For reference, I implemented this as I suggested: https://github.com/ypid/ansible-wireguard/tree/prepare-for-debops