Founder
June 2024 Update
![June update graphic](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fjun-24-update.png&w=828&q=75)
In this update:
- New feature: Conditional access policies
- New feature: Directory sync support for JumpCloud
- Blog post: Using Tauri for a cross-platform security app
- Blog post: Improving reliability for DNS Resources
- New support page for getting help with Firezone
- New changelog for tracking all releases we ship
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:
- Client location
- Client IP address
- Identity provider using for authentication
- Time of day
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
![Client location](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fclient_location.png&w=1200&q=75)
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
![Client IP](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fclient_ip.png&w=1200&q=75)
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
![Client IP](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fclient_idp.png&w=1200&q=75)
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
![Client IP](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fclient_tod.png&w=1200&q=75)
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:
- Have a cron job that runs at 3 AM and that needs access to a Resource? Set up a Policy that only allows access between 3 AM and 4 AM to restrict access outside of the hours the job runs.
- Want to prevent employees from accessing certain Resources outside of business hours? Set up a Policy that only allows access between 9 AM and 5 PM on weekdays.
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.
Directory sync support for JumpCloud
![JumpCloud directory sync](/_next/image?url=%2Fimages%2Fblog%2Fjun-2024-update%2Fjump_dir_sync.png&w=828&q=75)
In our ongoing effort to make Firezone more accessible to organizations of all sizes, we've added support for syncing your JumpCloud directory with Firezone.
This integration leverages JumpCloud's SCIM API to push user and group updates in real-time as they're made in your JumpCloud account. Set up takes only a few minutes, and once it's done, you can manage access to your Resources in Firezone using your JumpCloud groups, just like you would with any other identity provider.
Like other providers, JumpCloud directory sync is available on our Enterprise plan to ensure we can provide a smooth setup and support experience.
Blog posts
- Using Tauri for a cross-platform security app: Our Windows and Linux clients are built using Tauri, a Rust-based framework for building cross-platform desktop apps. In this post, we share our experience using Tauri and some tips for getting started with it for your own projects.
- Improving reliability for DNS Resources: We've made some changes to how we handle DNS Resources to make them more reliable and resilient to network outages. Read this to learn more about how this change may affect your Firezone deployment.
Wrapping up
That's all for this month's update! Subscribe to our newsletter below to get these updates once a month in your inbox. If you want a personalized demo to understand how Firezone can help secure your organization, fill out the form here and we'll be touch.