Back to Firezone

Create Policies

website/src/app/kb/deploy/policies/readme.mdx

1.0.55.5 KB
Original Source

import Alert from "@/components/DocsAlert"; import SupportOptions from "@/components/SupportOptions"; import PlanBadge from "@/components/PlanBadge"; import NextStep from "@/components/NextStep"; import Image from "next/image";

<PlanBadge plans={["starter", "team", "enterprise"]}>

Create Policies

</PlanBadge>

Policies are what grant users access to Resources.

To define a Policy, go to Policies -> Add Policy.

Policies define a single Group's access to a single Resource.

<Alert color="warning"> **Note:** To preserve audit trails, Policy details cannot be changed once a Policy is created. Double-check to ensure the Group, Resource, and/or conditions are correct before creating the Policy. </Alert>

<PlanBadge plans={["team", "enterprise"]}>

Conditional access policies

</PlanBadge>

On Team and higher plans, you may restrict access further based on the below conditions.

Client location

<Image src="/images/kb/deploy/policies/client_location.png" alt="Client location" width={600} height={600} className="mx-auto shadow-sm rounded-sm" />

Restrict access only to Clients connecting from specific countries. When this is specified, the Client's IP address will be used to lookup the country of origin.

Client IP address or CIDR

<Image src="/images/kb/deploy/policies/client_ip.png" alt="Client IP address or CIDR" width={600} height={600} className="mx-auto shadow-sm rounded-sm" />

Restrict access to a specific IP address or range of Client IP addresses.

Identity provider

<Image src="/images/kb/deploy/policies/client_idp.png" alt="Identity provider" width={600} height={600} className="mx-auto shadow-sm rounded-sm" />

Restrict access based on the authentication provider that was used to authenticate the Client. This is useful when you want to apply a stricter set of authentication requirements for certain Groups or Resources using a separate SSO app in your identity provider.

Client verification

<Image src="/images/kb/deploy/policies/client_verification.png" alt="Client verification" width={600} height={600} className="mx-auto shadow-sm rounded-sm" />

Restrict access only to verified Clients. When enabled, any Client being used by the Actors in the group will not be able to access the Resource unless it has been explicitly marked as verified in the admin portal.

The Client is identified for verification by their unique device IDs, which are retrieved from the following sources depending on the platform:

PlatformSourceNotes
MacOSHardware IDMatches the hardware ID found in the system report
MacOSHardware serialMatches the hardware serial found in the system report
iOSApp installation IDA unique UUIDv4 generated by the system upon app installation. Note: This ID will be reset if the app is uninstalled and reinstalled.
AndroidApp installation IDA unique UUIDv4 generated by the system upon app installation. Note: This ID will be reset if the app is uninstalled and reinstalled.
Windows, LinuxDevice IDThe BIOS UUID retried from SMBIOS
Windows, LinuxMotherboard serialThe mainboard serial retried from SMBIOS

This feature acts as a lightweight device management solution, ideal for organizations looking to enforce device policies (e.g., preventing mobile device access to production databases) without requiring a full-fledged MDM system to be in place.

Time of day

<Image src="/images/kb/deploy/policies/client_tod.png" alt="Time of day" width={600} height={600} className="mx-auto shadow-sm rounded-sm" />

Restrict access to certain time windows throughout the week based on the 24hr time and specified time zone.

The time zone determines the offset used when determining whether to allow access for a particular Client. For example, if you specify a time window of 08:00-17:00 and time zone of Eastern, Clients in the Pacific timezone 3 hours behind will be allowed access from 05:00-14:00 Eastern time.

How conflicting policies are resolved

The policy engine resolves access on a boolean OR basis. That means when two or more policies with conflicting conditions apply to a given Actor-Resource pair, access will be allowed to the Resource if any of the policies evaluate true.

As an example, consider the following policies:

PolicyGroupResourceCondition
AEngineeringProduction DBTime of day: 08:00-17:00
BDevOpsProduction DBNone

If an Actor is a member of both the Engineering and DevOps groups, they will be able to access the Production DB at any time of day since Policy B will always evaluate to true.

<NextStep href="/kb/deploy/clients">Next: Install Clients</NextStep>

<SupportOptions />