Learning outcomes
- State which request facts a layer 4 or layer 7 control can verify.
- Match the enforcement layer to the protected resource and action.
- Trace identity through TLS termination, tunnels, and upstream connections.
- Test protocol confusion, multiplexing, long-lived connection, and bypass failures.
System and boundaries
A layer 4 control handles transport connections. It can usually see source and destination network locators, ports, transport protocol, connection state, and facts obtained before or beside the connection. A layer 7 control understands an application protocol. For HTTP, it can use the authority, method, path, headers, token context, and response status. A database-aware control could use database protocol roles and commands.
The protected resource decides which layer is sufficient. A whole TCP service can be one resource. A web application contains many paths, objects, methods, tenants, and actions. If policy needs an application fact, enforcement must run where that fact is trustworthy and visible.
TLS changes visibility. A control outside encryption sees transport metadata but not protected application data. A terminating proxy sees the application protocol and creates a new trust boundary. A tunnel can carry many later actions after one connection decision.
Request and decision flow
- Name the resource and action. Examples are "open a TCP connection to the payroll database" and "approve invoice 482."
- List the identity and context needed for the decision: user, workload, device, destination, method, path, database role, object owner, or transaction state.
- Locate where every fact becomes trustworthy and visible.
- Place a coarse connection decision at layer 4 when the whole service has one policy boundary.
- Place protocol-aware route and request decisions at layer 7 when methods, paths, hosts, identities, or protocol messages need different policy.
- Keep object and business-action authorization in the application that owns that state.
- Bind the connection or request to an authenticated upstream and collect evidence at each decision.
For a browser application, a layer 7 identity-aware proxy can decide whether a user can reach the named application and path. The application decides whether that user can change a specific record. For SSH or a database tunnel, an initial access decision can permit the connection, while the target protocol and server authorize later operations.
Failure domains
- A layer 4 allow exposes every application action available on the connection.
- A layer 7 proxy parses one protocol while an attacker smuggles or upgrades to another interpretation.
- A TLS passthrough route claims application-aware policy without seeing the protected fields.
- A terminating proxy validates the client but does not authenticate the upstream.
- A long-lived connection remains active after the user's context changes.
- One multiplexed connection carries requests for users or resources that did not receive independent decisions.
- A direct service address, alternate port, node port, or internal load balancer bypasses the intended control.
Test the exact deployed protocol. An HTTP decision does not automatically cover WebSocket frames after upgrade. A TCP allow does not inspect SQL. A CONNECT tunnel decision does not authorize every destination or action inside the tunnel unless the system adds those checks.
Design tradeoffs and residual risk
Layer 4 enforcement supports many protocols and can avoid application termination. It has less action context. Layer 7 enforcement enables precise policy and evidence but adds parsing, protocol version, encryption termination, performance, and implementation risk.
Combining layers is common. Network controls restrict reachable enforcement points. A layer 7 gateway authenticates and authorizes application routes. The application enforces object permissions. Each control has a separate claim and failure mode.
Residual risk includes parser differences, encrypted fields, connection reuse, protocol extensions, direct-origin paths, and application actions that no intermediary understands. State what each layer cannot decide.
Pomerium boundary
Pomerium provides HTTP and documented non-HTTP access modes. The available identity and request context depends on the route type and protocol. Operators must choose the mode that exposes the facts needed for policy, protect the upstream path, and keep application authorization in the owning service.
Exercise
Select a web application, PostgreSQL service, and SSH service. For each, name the protected resource, action, available layer 4 facts, available layer 7 facts, encryption boundary, decision point, connection lifetime, and object-level owner.
Run direct-origin, alternate-port, wrong-host, protocol-upgrade, and stale-connection tests. Confirm that every allowed action has a decision at a layer that can see its required facts.
Evaluation checklist
- Does each policy name a resource and action instead of only a port?
- Is every required fact visible and trustworthy at the selected enforcement layer?
- Are TLS termination, upstream authentication, tunnels, and connection reuse explicit?
- Does the application retain object and business-action authorization?
- Can no alternate route bypass the intended layer 4 and layer 7 controls?
Next learning unit
Authorization Request
Model each decision with a subject, resource, action, context, policy, and evidence instead of a user role alone.
