Best practices
Learn best practices for building scalable Access applications and policies.
Access groups are reusable sets of rules that you can quickly apply across multiple applications. This could be a definition such as "corporate users", which has both device posture check requirements and specific emails, or just “developers”, which references a group in your identity provider. If you have many applications that will need identical policy structure, we recommend building an Access group and referencing it across multiple applications.
To create an Access group:
-
In Zero Trust ↗, go to Access > Access Groups.
-
Select Add a Group.
-
Enter a name for the group (for example,
Lisbon-team). -
Specify as many rules as needed to define your user group. For example, the following rules define a team based in Lisbon, Portugal:
Rule type Selector Value Include Country PortugalRequire Emails Ending In @team.com -
Select Save.
Send a POST request to the /access/groups endpoint:
curl https://api.cloudflare.com/client/v4/accounts/{account_id}/access/groups \--header "X-Auth-Email: <EMAIL>" \--header "X-Auth-Key: <API_KEY>" \--header "Content-Type: application/json" \--data '{ "name": "Lisbon-team", "include": [ { "geo": { "country_code": "PT" } } ], "exclude": [], "require": [ { "email_domain": { "domain": "team.com" } } ], "is_default": false}'You can now select this group in the Access policy builder.
Access applications have an inherently flexible and powerful domain structure capability. Your domain structure should achieve your application security goals without being overly permissive or overly restrictive. Before designing applications for production, review the Application paths documentation to understand how path definitions work and how to use wildcards.
Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make onboarding to a Zero Trust Web Access service difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses.
If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment using Terraform or another Infrastructure as Code (IaC) service.