Policy
Policies allow Administrators to centrally define which Managed systems in their account should be connected to one another and under what conditions.
Production use
Changes to policies take effect immediately and Enclave will quickly build direct connectivity between enrolled systems impacted by each Policy.
Policy Types¶
There are two types of Policy:
- Direct Access Policies, which enable direct, peer-to-peer connectivity between two devices running Enclave.
- Gateway Access Policies, which route traffic to peers via an Enclave Gateway. These can be useful when you can't install Enclave on a device (e.g. a printer).
Direct Access Policies¶
Each Direct Access Policy is composed of Tags which are assigned to one of two roles: a Sender role and a Receiver role. Traditional firewalls are often configured to permit outbound traffic but block all inbound or unsolicited traffic. In much the same way, Enclave will allow systems in the Sender role to originate traffic to systems in the Receiver role but not the reverse.
Systems are grouped together under common Tags and Tags are attached to Policies. As an example, consider the following policy:
| Policy Name | Sender Tags | Receiver Tags |
|---|---|---|
| Kubernetes access | developers contractors |
kubernetes-pods |
Any system which is a member of either the developers or contractors Tags will be connected to any system in the kubernetes-pods Tag, but systems in the developers Tag will not be connected to other developers or contractors by this Policy. More generally, connectivity is established between the systems with membership in Tags attached on the Sender and Receiver side, but never between systems on the same side.
Systems in the kubernetes-pods Tag will be unable to initiate outbound connections to developers or contractors systems, as the Receiver role prohibits unsolicited traffic and only allows responses to traffic which originated from a system with the Sender role.
Unlike the public Internet, without an Enclave connection in place between two peers, no traffic can be send across an Enclave link; this means access controls can be exclusively Receiver defined. There is no way to apply sender-side restrictions to an Enclave peer to prohibit what can or can't be sent to other peers, all access controls are applied by the Receiver and govern what each system is willing to accept.
Depending on how Administrators arrange Tags in each a Policy they may create either partially connected or fully connected mesh topologies.
Partially Connected mesh¶
In a partially connected mesh, only specific systems connect to one another across the policy. This assumes that no systems belong to Tags on multiple sides of the Policy.
| Policy Name | Sender Tags | Receiver Tags |
|---|---|---|
| Server access for Workstations | workstations | servers |
Fully Connected mesh¶
Full mesh connectivity arises when multiple systems are members of Tags on both sides of a Policy, all affected systems are connected to one another. In the following example a Policy defines connectivity between systems tagged as servers.
| Policy Name | Sender Tags | Receiver Tags |
|---|---|---|
| Servers full mesh | servers | servers |
Fully connected mesh networks may create large numbers of connections between participating systems. The number of connections in a fully connected mesh is equal to Nā(Nā1)/2 (i.e. number of systems times the number of systems minus 1, divided by 2).
A fully connected mesh of 16 systems will create 120 connections, where as a mesh twice the size with 32 participants will create 496 connections. You should consider the capabilities of your underlying network infrastructure when deploying a fully connected mesh as some stateful network appliances impose limits on the maximum number of connections they can track or support.
Gateway Access Policies¶
Gateway Access Policies are composed of Sender tags, like Direct Access Policies, and a list of Gateway devices and their subnets. Traffic can flow from senders to destination IP addresses within these subnets, but devices on the routed subnets cannot initiate connectivity back to the senders.
The precise list of receiving devices is unknown - any device within the subnets routed by the policy is a valid receiver of traffic.
You can find more information about Gateway Access Policies here.
Access control¶
Access Control Rules¶
Once you have indicated which systems should be communicating, you then want to define what traffic is allowed to move between Senders and Receivers. You can control this per-policy with Access Control Rules.
Access Control Rules allow you to define which protocol and port(s) you want to allow into systems on the receiving side of the Policy.
Applying Access Controls at the Receiver side of a policy makes the entire system much easier to reason about. You can set up traffic rules in a similar way to setting up firewall rules to allow access to a service. The way rules are applied should feel pretty intuitive, but fundamentally:
- If you don't specify any rules on your policy, no traffic will flow (default deny)
- Each ACL rule only applies to connections between the senders and receivers of the policy where it was defined.
- Different rules on different policies affecting the same systems are combined, but still respecting rule #2.
When you create a new policy, by default we add a rule that allows All Traffic to flow between Senders and Receivers. Remove this rule to restrict the set of traffic you want to allow.
Sender Trust Requirements¶
You can apply trust requirements directly to policies, which indicate requirements for all systems on the sender side of the policy. Systems must meet all the specified requirements before their connectivity granted by this policy can establish.
If a sender originally meets all the requirements, but subsequently stops meeting one or more requirements (e.g. by logging out on the device), the policy stops taking effect (including any existing connections).
Info
If a policy doesn't have trust requirements applied, connectivity is Always On. More specifically, connectivity will always be established before a user logs into a device, enabling Active Directory integration.
Active Hours¶
Each policy can have a set of "Active Hours"; namely the hours of the day, and days of the week, in which a policy will take effect. This can be useful if you want to:
- Only allow connectivity for backups for one hour every day when backups are meant to run.
- Ensure that contractors only working two days a week do not have access on other days.
- Ensure that a user laptop stolen on a Friday cannot be used to reach your on-prem resources over the weekend without your IT team realising it.
When specifying Active Hours, you can indicate the start and end time on each day for the policy to become active, and on which days of the week. Hours can wrap over to the next day, so you can easily specify 11pm to 1am (for example).
You can also specify a custom timezone, to help when thinking about the hours you apply when your users are not in your timezone.
Tip
Don't forget that policies are additive; if you want some connectivity to be active between 14:00 and 16:00, and also between 18:00 and 23:00, you can define two policies for the different active hour periods, and you will get the desired outcome.
Auto Expiry¶
You can configure Policies (as well as Systems and Enrolment Keys) to Auto Expire. With Auto Expiry, you can specify a point in time for our platform to automatically disable or permanently delete the policy for you.
This can be really useful if you want to turn on some connectivity for a Just-In-Time access use-case, but don't want to have to remember to turn it back off again once you're done.
As well as specifying an exact time from within the policy edit pane, there are also shortcut "Enable For" and "Disable After" options in the policy table, reached by clicking on the options button on the right-hand side of the row, which give you one-click expiry options to automatically disable after some typical time periods.
Naming¶
The Enclave access control model is defined by the Receiver role of each Policy, so Policy names should normally reflect the resource accessed and consumer(s) in an X for Y pattern.
For example if a Policy defines access to a GitLab server for Developers, naming the policy GitLab for Developers provides a clear and concise description.
Separate policies may grant access to the same resource or set of resources. For example, one Policy may grant Developers to access Database Servers during working hours and a separate policy may grant the Site Reliability Engineering (SRE) team 24/7 access to the same Database Servers.
Database Servers for DevelopersDatabase Servers for SRE