Add identity, devices, and policy

Three separate layers control who reaches what in this architecture. Collapsing them into one mental bucket is how over-broad access happens.

Device enrollment decides who may connect a device to your Zero Trust organization. Passing enrollment means the device is inside the front door. It says nothing about what the device may do next.

A network route says where matching traffic can go. Advertising 10.0.1.0/24 through a Tunnel tells enrolled clients that Cloudflare can carry traffic toward that range. It does not say every enrolled user should reach every destination in it.

Authorization is the third layer, and it is the one people skip. Gateway and Access policies can look at identity, destination, port, and device posture. They run for every connection, at the edge, before traffic reaches your network.

The pattern I want you to copy is this. Start with a catch-all block for the private range. Then add narrow allow rules above it for the users and services that need access:

priority  action  who                destination      port
1         allow   [email protected]    10.0.1.100/32    22
2         allow   dev-team group     10.0.2.0/24      443
3         block   everyone           10.0.0.0/8       any

Policies evaluate in priority order, and the first match wins. So the specific allows fire before the blanket block. Anything you never explicitly allowed gets denied by rule 3. Ana can SSH into one host. The dev team can reach HTTPS on one subnet. Nobody else gets anything.

Device posture deserves a sentence. A policy can require an up-to-date OS version or a corporate certificate before allowing a connection. Access follows the person and the state of the machine. A raw WireGuard key can never express that, because a key only proves possession.

Now the failure mode without that block rule. It is quiet and common. Enrollment plus a route means every enrolled device reaches the entire advertised range. The intern’s laptop can reach the database port. Nothing errors, nothing warns. It surfaces later, in an audit or an incident, when someone asks “who could reach this?” and the honest answer is “everyone”.

Here is the mental test I use. Take any enrolled user and any address in the routed range. Can you name the rule that allows or denies that pair? If the answer is “there is no rule, so it is allowed”, you are missing the block.

We will verify all this in the lab lesson. The principle is worth stating now: test one allowed identity and one denied identity, and read the policy logs to see which rule matched each connection. A policy nobody has watched matching is a policy nobody understands.