Over the past few months, the Enclave engineering team has been hard at work adding several major new features to the Enclave platform; all aimed at making Enclave everyone’s favourite straight-forward Zero Trust Overlay Network, and allowing teams to really accelerate their Zero Trust journey.

I’m going to go through a bunch of the new additions, and how they can make managing your network seem surprisingly close to magic!

No idea what Enclave is? We create zero-fuss, zero-trust network connectivity between systems anywhere on the internet, without opening any of your firewalls, adding edge devices, or changing your infrastructure. It’s also free to try out at https://enclave.io

This release is the culmination of months of coordinated effort across design, back-end engineering and the front-end team, and I’m super proud of what everyone has built, I think you’re going to really like it!

Trust Requirements

Trust requirements is a brand new foundational component we’ve built, that means we can now perform real-time evaluation of the current user/device posture of a connected system, and mutate your network (extremely quickly) in response to those properties changing.

This is a big addition to the policy engine we already have; up until now, once you establish a policy in Enclave, the connectivity it defines remains available until you turn it off.

With trust requirements, we can bring connectivity up and down in response to environmental factors, or any property of the system. You can add trust requirements to individual policies, or to an entire tag, and only once all the configured requirements are met will the connectivity defined by those policies/tags come up.

At this point we have added a User Authentication trust requirement to get us started, but some examples of things you will be able to do with Trust Requirements:

• Users have to be logged in via Azure AD on their workstation before they can access any resources.
• Users in the Azure AD Group “Sysadmins” can get SSH access to servers, but all other users only get HTTP access.
• Laptops cannot access your network unless they’ve installed Windows updates.
• Any system connecting from an IP address based in Russia cannot access high-security systems.
• Make automatic live requests to an API endpoint to establish custom trust against a solution you already have.

You will be able to micro-segment your network based on all sorts of detailed requirements, all the way down to the individual ports people can access on your servers.

Trust Requirements

User Authentication

The first new trust requirement we’ve added is User Authentication; this one is sort of what it says on the tin, but the power it unlocks should not be underestimated.

Adding a user authentication trust requirement to a policy or tag means that users will need to sign-in on their local system (in the installed Enclave Agent software).

Right now, you can require that users sign-in to the Enclave Portal (limiting connectivity to portal admins), or (more usefully) you can specify an Azure AD tenant, and users will then need to login to that tenant on their local device.

The support for Azure AD extends to support for all of their own Zero-Trust evaluation mechanisms via Conditional Access Policies, and, on Windows, integration with Windows Hello, FIDO key authentication, and any other login mechanisms supported by Azure AD. So you can bring all your existing Azure AD security work directly to Enclave without needing to rebuild anything! 🤯

Because Enclave and Azure AD get on so well, you can also specify a Security Group ID against the Trust Requirement, meaning you can not only require users to login, you can also require that those users are a member of a specific Security Group. So you can micro-segment your network down to the ACL level, directly based on your existing security groupings; just like that!

Trust Requirement Azure AD Configuration

I’ll probably be blogging some more about the things you can do with Azure authentication trust requirements, but it’s really easy to set it up just from the Enclave Portal, and once I started using it in-house, it really felt like a powerful tool to micro-segment networks.

We’ll be adding more Authentication providers in the near future, such as Google and Github, but we’ll also be adding support for our Enterprise customers to use custom SAML or OIDC providers. Get in touch if you have a specific identity provider you want to integrate with.

Tag Management

Since day 1, Enclave has used tags to control which systems may be able to connect to each other, by adding tags to systems, and then to policies.

As your Enclave organisation grows, the list of tags you will have is going to grow too. To make it easier to review and manage them, we’ve added a new “Tags” page to the Enclave Portal.

Trust Requirement Azure AD Configuration

Today, you can:

• View and search your list of all tags.
• Rename a tag.
• Set a colour for each tag, to make it easier to visually categorise systems/policies.
• Add miscellaneous notes to the tag.
• View the list of Enrolment Keys, Systems, Policies and DNS records that have that tag applied.
• Remove a tag (removing a tag will take it off every system and policy, so use with care!)
• Add trust requirements to the tag.

I’ll expand on that last one a bit; when you add a trust requirement to a tag, that requirement will be required everywhere that tag is used.

As an example, if you:

• Create a trust requirement “Must be in Azure AD Developers Group”, configured with the right tenant and Security Group ID,
• Add a tag developer, to which you add your trust requirement and
• Enrol Jane’s laptop with Enclave and tag the system the developer tag.

Then any connectivity the developer tag would give Jane will automatically require Jane to be logged in as a member of that “Developers” group, without having to redefine it on every policy.

Automatic DNS Configuration on Linux

DNS configuration on Linux is, to put it mildly, complicated. With multiple different built-in resolvers, some using systemd-resolved, some not, some needing updates via Network Manager, and each variation with their own quirks, it’s a bit of a quagmire trying to configure it.

That’s why, up until now, we’ve asked users to manually configure their Linux box to use Enclave as their nameserver. But no more!

As of the latest Linux stable release, Enclave will automatically configure your local DNS settings to use Enclave as a nameserver, selecting the correct configuration mechanism to use based on the configuration we detect is already in place.

This removes one of the last challenges on Linux when setting up a docker container that needs to function as a client in a service mesh.

You can disable this behaviour in your Enclave profile file, by setting DisableAutoDns under LocalNameserver to true.

Support

If you have any questions/issues with the new features, please head over to our community forums at community.enclave.io or join us on Slack at https:/enclave.io/slack.

Happy networking!