[commercialnix]

Wireguard layer-3 tunneling identity (public key) is for machines, not human users. Rolling out Wireguard in an "enterprise environment" for over 600 user laptops and desktops (mix of Linux and some macOS* and Windows*) with our existing configuration management (SaltStack/GitOps) was extremely easy to do.

Where additional layer-3 tunnels that were user or group specific were necessary, we did some very light scripting that any sophomore-level Sys Admin can handle.

We already have BeyondCorp / ZeroTrust for any layer-4 and above authentication.

>> Compare this with a commercial VPN that will directly plug into your identity system.

This would be something out of the clicky-clicky industrial complex.

[BrandoElFollito]

Thanks for the feedback.

How did you manage the IP assignment, keys revocation, ...?

How did your ZT environment worked with WG on the network level? (zScaler creates its own tunnels for instance)

[commercialnix]

Looks like I forgot to clarify the meaning of the asterisk, so here:

[*] we charge a hefty premium to manage third party OS in a sideways way by offering a 75% discount on our endpoint OS, with exception to special and authentic cases (some 3D CAD or other).

Three important points of context to highlight here:

0.] We don't hire for "butts in seats", we hire for aptitude and/or talent then also culture very carefully and if someone isn't vibing, isn't "getting it", we fire very fast (locking them out with the same stack we use to operate customers' devices).

1.] We don't use Git in the typical pedestrian centralized way (ie GitLab), Git is of a distributed and we use Git as such in an approach that gracefully is combined with other things that, like Git, do their one small thing and do it right. Our approach has been described as "nirvana for security and compliance" and is still considered somewhat novel. We would call this "bespoke", but the use of this approach has been uniform in each place.

2.] We consider our Git approach with SaltStack something that any entry-level SysAdmin or even IT Ops should be able to wrap their head around. Salt obviates a lot of Python we might otherwise write. The end customer has "engineers" who do write in some interpreted languages, maybe some languages on JVM and some C#, but they don't write software in a sane way, so they pay for our clicky clicky to talk to our API for what we have done. Ultimately, the customer doesn't really "do computer" (even though they try), they are users, "power users" at best (which is kind of worse actually). Open Source is about *source code* ie software, which is the part we are good at and the customer is not.

3.] Without the existing wealth of open source software, we would not even attempt to be playing the same ballpark we are now. Context number zero is more strongly why we are much more confident with what we have than anything in the whitelabel-option Managed Services Provider space, but this context number three is also a big part.

The BeyondCorp / ZeroTrust in place does all of its "smart" like time-of-day or some statistic/heuristic at layer-4 (TLS). The layer-3 is there too because defense-in-depth. I know we have something on the roadmap to add more smarts to the Wireguard pieces (I'd have to ask someone). The non-management Wireguard tunnels, the ones for "app", don't come up without TPM unbothered and a user's hardware key being involved. We haven't yet seen a BeyondCorp / ZeroTrust suite from a vendor we found compelling or "we really want X feature they have" that we can't easily (and more quickly than a sales cycle) do ourselves with our model.

Background:

The customer had existing IPAM, but it was too much of a mess. The kinds of customers that don't have clean IPAM also don't have IPv6. So we went ahead and used some of the IPv6 that our corp has from ARIN with proper agreements in place with customer to make using our IPv6 space "okay" and endpoints do 4in6 to reach customers' existing IPv4 subnets (mostly RFC1918).

Every device in our purview is notated as a YAML versioned by Git for SaltStack to do whatever on the device. Each machine has a unique id, similar to the /etc/machine-id concept, with data for that machine expressed as SaltStack Pillar.

Typical incident:

Suppose machine morty.foo.baz.example.net is stolen from a user's car. Upon awareness of the incident the key "status" in the YAML for morty is updated to have value "stolen" added to change management (Git). A look up is done on every public key used by the Wireguard peer named Morty, and every device that uses any of those public keys gets poked to apply the new data expressed as Salt.

Remediation:

On another device running Wireguard named Rick, the public key for Morty is now expressed in a new way by Salt Pillar and the relevant Salt State has "file.absent" for the public key. For the public key Salt already has "onchanges" to "service reload wireguard-something" (reload, not restart) via init script which changes what needs to be changed and only what needs to be changed.

  https://docs.saltproject.io/en/latest/topics/pillar/index.html#pillar

  https://docs.saltproject.io/en/latest/ref/states/requisites.html#onchanges

  https://docs.saltproject.io/en/latest/ref/states/all/salt.states.file.html#salt.states.file.absent