Firezone June 2024 Product Update | Firezone Blog

In this update:

Conditional access policies

Policies form the basis of Firezone's access model, and in June they got a major upgrade.

In the zero-trust security model, it's all about making access as granular as possible to ensure only the right people can access the right Resources at the right time. Policy conditions continue that theme by allowing you to restrict access to four powerful access conditions:

These are evaluated at the time access is attempted by Firezone's Policy Engine. If a Client switches networks, for example, access is re-evaluated immediately based on the new conditions.

Read more about how each one works below.

Client location

Use Client location to restrict access to a Resource based on the country where the Client is located. This is useful for region-locking certain Resources or preventing Clients in certain countries from accessing sensitive systems.

How does it work?

The Client's location is determined by its IP address using Google's Regional external Application Load Balancer API. The load balancer reports this data to Firezone's control plane API based on the remote IP address of the Client's control plane connection. If the Client switches IPs, the control plane connection is re-established and the location is updated, invalidating all previously authorized Policies.

We deliberately avoided using Client-provided location data such as device GPS. These can be trivially spoofed by a malicious Client.

Client IP

Another way to restrict access to a Resource is by the Client's IP or CIDR address.

You can use it as an allowlist, for example, to allow employees to access a Resource from only a particular branch office.

Or, you can use it as a denylist to block access from malicious IP addresses or networks you explicitly don't want to allow access to your Resources.

Identity provider

If you've configured an identity provider, you can also require users to have signed into that identity provider in order to access the Resource in question.

This functions well for MFA enforcement -- restrict access to an identity provider with MFA enabled to enforce MFA across your workforce for all Firezone-managed Resources.

And since Firezone supports adding multiple identity providers to your account, you can configure multiple SSO applications in your identity provider -- each with their own set of authentication requirements -- for even more flexibility over access to your Resources.

Time of day

Finally, you can restrict access to a Resource based on the time of day.

The time of day is determined by the locality defined in the Policy and not by the Client, so it's important to ensure your Policy's locality is set correctly to match the time zone you want to enforce access based on.

Time-based access policies open the door for interesting use cases. For example:

By locking down access to Resources based on the time of day, you add another tool to your security arsenal to prevent unauthorized access to your Resources.

Blog posts

Wrapping up

That's all for this month's update!