Access Policy Best Practices

[ChrispyBacon-dev]

New Wiki Page: Access-Policy-Best-Practices.md

Access Policy Best Practices

DockFlare provides powerful tools to manage Cloudflare Access policies, but following best practices ensures your services remain secure and manageable. This guide covers key strategies for a robust Zero Trust setup.

1. The Wildcard "Safety Net" Policy

The single most important best practice for any Cloudflare Access setup is to create a "catch-all" or wildcard policy. This acts as a safety net, ensuring that no service can be accidentally exposed to the public.

Why it's essential:
Without a wildcard policy, if you create a new DNS record (manually or via DockFlare) but forget to assign an Access Policy, that endpoint will be publicly accessible. A wildcard policy ensures that by default, everything is denied access unless you explicitly allow it.

How to create a *.yourdomain.com policy:

1. Navigate to the Cloudflare Zero Trust Dashboard.
2. Go to Access -> Applications and click Add an application.
3. Choose Self-hosted.
4. In the "Application Domain" field, enter your wildcard domain, for example: *.example.com.
5. Give the policy a name, like "Default Deny" or "My Personal Access".
6. Create a policy rule. A good starting point is an Allow rule for your personal email address.
7. Crucially, Cloudflare automatically adds a "Deny" rule at the end for everyone else. This is the safety net.
8. Save the application.

Now, any subdomain like random-app.example.com will automatically be protected and require a login.

2. Setting Up Identity Providers (IdPs)

To grant access to users, you need to connect Cloudflare to an Identity Provider (IdP). This can be a social provider like Google or GitHub, or a corporate one like Microsoft Entra ID.

How to add an IdP (high-level):

1. In the Cloudflare Zero Trust Dashboard, go to Settings -> Authentication.
2. Under the "Login methods" card, click Add new.
3. Select your desired provider (e.g., Google, GitHub, SAML, OIDC).
4. The dashboard will provide step-by-step instructions. This usually involves:
   • Going to the developer portal of your chosen provider (e.g., Google Cloud Console, GitHub Developer Settings).
   • Creating a new OAuth application.
   • Copying the Client ID and Client Secret from the provider into Cloudflare.
   • Copying the callback URL from Cloudflare into the provider's application settings.
5. Save the configuration in both Cloudflare and the provider.

For detailed, official guides, please refer to the Cloudflare Zero Trust documentation.

3. How DockFlare Supports These Practices

DockFlare is designed to work seamlessly with these best practices, giving you both declarative security and interactive flexibility.

Leveraging the Wildcard Policy

You can instruct DockFlare to rely on your wildcard "safety net" for any specific rule.

• Label: Use dockflare.access.policy=default_tld.
• Behavior: When this label is used, DockFlare will not create a specific Access Application for that hostname. It assumes your wildcard policy (*.yourdomain.com) will cover it. This is perfect for internal tools that you only want accessible to yourself.

Declarative Security with Labels

You can define the entire security posture of a service directly in your docker-compose.yml.

• bypass: Creates a public application, explicitly overriding the wildcard deny policy. Use this for services you truly want open to the public.
• authenticate: Creates a specific application requiring a login. This is useful if you want different access rules for a specific app than your general wildcard policy provides.
• custom_rules: For advanced scenarios, you can define precise JSON-based rules on a label.

UI for Flexibility and Overrides

While labels are great for defining the initial state, the Web UI is perfect for managing exceptions and daily operations.

• Quick Policy Changes: Instantly change a service's policy from authenticate to bypass for a temporary test without editing any files.
• Persistent Overrides: Changes made in the UI are saved and take precedence over labels, so your interactive changes are not lost on a container restart. The "UI Override" badge makes it clear which rules are in this state.
• Revert to Code: The "Revert to Labels" button gives you a simple way to return to your declarative, code-based configuration, ensuring your docker-compose.yml remains the source of truth when you want it to be.

By combining a strong, default-deny wildcard policy in Cloudflare with DockFlare's flexible label and UI-based controls, you can build a secure, manageable, and easily understood Zero Trust environment for all your self-hosted services.
https://github.com/ChrispyBacon-dev/DockFlare/wiki/Access-Policy-Best-Practices.md

[MattHodge]

Just wanted to share my setup + learnings to help others.

My scenario:

• Using the "Wildcard" policy didn't work for me, as I have another service running in Cloudflare Tunnels
• I wanted to have 2 potential policies to apply to services I want to expose to via the tunnels:
  • An allow list of particular countries
  • The country allow list AND to require auth with specific email validation

I ended up building these policies in Terraform to use later with Dockflare:

resource "cloudflare_zero_trust_access_group" "allowed_countires" {
  name    = "Allow specific countries"
  zone_id = "xxxx"
  include = [
    {
      geo = {
        country_code = "NL"
      }
    },
    {
      geo = {
        country_code = "AU"
      }
    }
  ]
  require = []
  exclude = []
}


resource "cloudflare_zero_trust_access_policy" "allowed_emails" {
  account_id       = "yyy"
  name             = "Allowed Countries and Emails"
  session_duration = "8h"
  decision         = "allow"
  include = [
    {
      email = {
        email = "[email protected]"
      }
    },
    {
      email = {
        email = "[email protected]"
      }
    }
  ]
  require = [
    {
      group = {
        id = resource.cloudflare_zero_trust_access_group.allowed_countires.id
      }
    }
  ]
  exclude = []
}

resource "cloudflare_zero_trust_access_policy" "allowed_countries" {
  account_id       = "yyy"
  name             = "Allowed Countries"
  session_duration = "8h"
  decision         = "allow"
  include = [
    {
      everyone = {}
    }
  ]
  require = [
    {
      group = {
        id = resource.cloudflare_zero_trust_access_group.allowed_countires.id
      }
    }
  ]
  exclude = []
}

output "cloudflare" {
  description = "The output to use as a docker label for protection of a public site "
  value = {
    "dockflare" = {
      "allowed_countries_and_emails" = {
        "dockflare.access.custom_rules" = [
          {
            id         = resource.cloudflare_zero_trust_access_policy.allowed_emails.id
            precedence = 0
          }
        ]
        }
      "allowed_countries" = {
        "dockflare.access.custom_rules" = [
          {
            id         = resource.cloudflare_zero_trust_access_policy.allowed_countries.id
            precedence = 0
          }
        ]
      }
    },
  }
}

That provides a nice Terraform output, letting you know what to use for dockflare.access.custom_rules:

cloudflare = {
  "dockflare" = {
    "allowed_countries" = {
      "dockflare.access.custom_rules" = [
        {
          "id" = "guid-123"
          "precedence" = 0
        },
      ]
    }
    "allowed_countries_and_emails" = {
      "dockflare.access.custom_rules" = [
        {
          "id" = "guid-xyz"
          "precedence" = 0
        },
      ]
    }
  }
}

When I label my containers:

# When I want allowed list countries only
dockflare.access.custom_rules: '[{"id":"guid-123","precedence":0}]'
# When I want allow list countries AND allowed emails
dockflare.access.custom_rules: '[{"id":"guid-xyz","precedence":0}]'

[ChrispyBacon-dev]

this goes into a similar direction to this issue:

#137