Best practices

  2 min read

Learn best practices for building scalable Access applications and policies.

​​ Use Access groups

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:

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.

​​ Define your domain structure

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.

​​ Multiple domains in an application

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.