Network, Edge, and Zero-Trust Architecture

The refund webhook now has an identity and a secret. It also has a route. Traffic from the payment provider crosses the public edge, reaches a verifier, changes refund state, and may cause a worker to call the provider again. Operators need a different route to diagnose that work. The deployment pipeline needs another to replace it. Logs and traces observe all three.

Calling those systems “internal” hides the most important facts. If the verifier is compromised, can it scan peer services, query the database directly, reach a cloud control endpoint, or send customer data to an arbitrary host? If an administrator is phished, does the same network path lead to the cluster API and the production database? A private address answers none of those questions.

Treat connectivity as a collection of explicit paths. Every allowed path needs a caller, destination, purpose, policy, enforcement point, evidence, owner, and end condition. Everything else should be unreachable. That is the useful network expression of zero trust.

Begin with paths, then draw zones

Start the review with an observed request, not a cloud diagram. For the refund webhook, record the provider as the caller, the public hostname and exact route, the ingress component, the verifier workload, and the state-changing operation. Continue through every downstream call. A line that ends at “application network” has stopped before the security decision.

Zones still give the map useful shape. The public edge receives hostile traffic. The ingress tier terminates and constrains that traffic. Application workloads perform product work; assume any one of them may eventually be compromised. The data tier holds the authority and information those workloads seek. The management plane can change the other planes, while the build plane can change what runs in them. The observability plane sees sensitive events and determines what an investigation can recover.

Those names are warnings, not permissions. Membership in an application subnet must not grant the verifier broad access to its peers or the data tier. A build runner should have a deployment path, not a general production path. A log collector may need to receive events without gaining a route back into the workloads that emitted them. Development and staging should not inherit production reachability merely because their addresses are private.

For each connection, keep a small reachability record. The modeled refund path would begin like this:

caller: payment-provider webhook delivery
destination: refund verifier /webhooks/refunds
purpose: authenticate and enqueue a refund-state transition
identity: provider signature verified with named secret version
network enforcement: approved public route -> ingress -> verifier only
application policy: accepted event type, bounded body, replay window, idempotency key
evidence: edge request id, verification result, route decision, verifier trace
owner: payments platform
review or expiry: on integration change; remove with provider integration
negative proof: peers, data stores, management endpoints, and other routes are unreachable

This record is more useful than an inventory of ports. It binds reachability to the action that justified it and says how to prove both the permission and the denial.

Zero trust makes each connection earn its place

Zero trust does not mean distrusting everything rhetorically or buying a particular gateway. It removes the assumption that network location, device ownership, or prior admission is enough. A subject requests a resource; policy uses identity and relevant context to decide; an enforcement point permits only the requested access; telemetry informs later decisions and containment.

The subject may be a person, workload, device, pipeline, or third party. The resource may be an API operation, queue, database role, administrative function, or deployment action. Naming both prevents a rule such as “application subnet may reach database subnet” from standing in for authorization.

Identity policy and network policy do different work. Workload identity lets the refund verifier prove which software is calling. Application authorization limits what that identity may do. Segmentation limits which enforcement points it can reach at all and reduces options after code execution. Encryption protects the connection in transit. Logs make the decision inspectable. No one control absorbs the others.

Context should change a decision only when the system can obtain and trust it. A managed-device signal can strengthen a privileged administration policy; an unverified client header cannot. Re-evaluation also needs a consequence. If a workload identity is revoked or a device falls out of policy, define which new connections fail, which existing sessions end, and how quickly enforcement points learn the change.

Make the public entrance narrower than the application

The provider needs one webhook route, not general access to the refund service. Publish only the expected hostname, protocol, method, and path. Terminate TLS with certificates that are inventoried and renewed. Reject unexpected methods, ambiguous framing, oversized bodies, invalid content types, and malformed requests before expensive application work begins. Preserve the raw bytes needed for signature verification without copying the secret or sensitive body into edge logs.

Rate limits should reflect the resource being protected. Source-address limits can absorb some noise, but provider retries may come from many addresses and many legitimate deliveries may share one. Add limits for the route, provider account, verified identity, tenant, and costly operation where those identities exist. Bound concurrency, queues, parsing work, and downstream calls as well as requests per second. An edge filter or WAF can reject known-bad traffic; it does not repair an authorization or parsing defect in the verifier. Volumetric attacks need capacity and upstream mitigation before traffic saturates the system’s own link. Decide explicitly whether expected automation is allowed, identified, isolated on another route, challenged, or blocked; a generic bot score is not a business policy.

The network exposure review should identify every public hostname and route, its business owner, TLS and edge policy, expected automation, abuse budget, upstream dependencies, logs, and removal condition. Compare that inventory with DNS, load-balancer, gateway, firewall, and cloud configuration. An endpoint that appears only in discovered infrastructure is still exposed; an entry that no longer resolves may still have a forgotten path elsewhere.

Segment the first compromised workload

Now assume the verifier has been compromised. Its legitimate job requires it to verify an event and place a bounded message on a refund queue. It does not need to enumerate services, open an administrator console, query arbitrary database tables, fetch deployment credentials, or read raw observability storage.

Express that design as allowed relationships between named callers and named destinations. Public traffic reaches approved ingress. Ingress reaches the verifier route. The verifier reaches the queue under its workload identity. A refund worker reaches the narrow data operation and the provider API. The deployment pipeline reaches the deployment controller with a distinct pipeline identity. Administrators enter through a separate privileged path. Production does not accept unsolicited connections from development or staging.

This relationship map performs the segmentation matrix’s real job without pretending every boundary has equal weight. Review the dangerous chains first: public-to-management, workload-to-credential service, workload-to-data, service-to-service lateral movement, build-to-production, observability-to-source, and nonproduction-to-production. Tenant-specific network paths belong here too, but network location cannot replace the tenant checks that Chapter 17 will carry through queries, jobs, caches, exports, and support tools.

Generate firewall, security-group, gateway, and service-policy rules from a reviewed source when the platform permits it. Test positive and negative paths from the caller’s actual runtime identity and network location. A successful verifier-to-queue test proves availability; it does not prove that verifier-to- database and verifier-to-management traffic is denied. Alert on unexpected denials during rollout, because they often reveal an undeclared dependency, but do not convert each discovery into permanent broad access.

Outbound traffic is another authority boundary

The refund worker’s call to the payment provider is necessary egress. A request to an arbitrary host is not. If compromised code can choose any destination, it gains a path for exfiltration, command and control, and requests to internal or platform endpoints that were never meant to be application interfaces.

For stable dependencies, allow the worker to reach the provider’s approved service through a controlled route. Record the workload identity, destination and account, protocol, data classes sent, credential scope, encryption, proxy or firewall policy, DNS behavior, owner, incident contact, and review condition. Collect destination, policy decision, workload identity, time, and useful volume signals without logging credentials or payloads indiscriminately.

Domain allow-lists require more care than matching a string. Resolution can change, redirects can escape the approved destination, and a user-controlled URL may resolve to local, private, link-local, or otherwise protected services. Validate the business input, restrict schemes, control redirects, resolve and enforce the destination at the network layer, and give the calling workload no ambient route to sensitive internal endpoints. When a product genuinely calls customer-selected destinations, isolate that fetcher and its credentials rather than granting the main application arbitrary egress.

Legacy systems may not tolerate default-deny egress immediately. Begin by observing destinations and assigning owners, then separate known dependencies, unknown traffic, and destinations carrying sensitive data. Move high-consequence workloads first. Visibility is a migration step, not the final policy.

Administration takes a different road

An operator investigating a failed refund should not approach production by the public webhook route or by a permanent office-network exception. Administrative access needs a controlled broker or equivalent access layer, named accounts, phishing-resistant authentication for privileged remote access, managed-device or posture checks where they are reliable, time-bounded elevation, and a policy for the exact production resource and action.

Keep public administrative panels, SSH, database consoles, cluster APIs, and other control interfaces off the open internet. Record privileged sessions and high-impact actions at a level that supports investigation, while protecting sensitive console content and credentials. Separate approval from use for the most consequential operations. A shared administrator account makes both policy and evidence weaker.

Recovery needs an independent break-glass path because the ordinary identity or access layer may be the failed component. Limit its authority and lifetime, protect and monitor retrieval, test it without normalizing routine use, and review every activation. If an emergency requires a temporary direct route, name the condition, approver, source and destination, compensating detection, removal command, and automatic expiry before opening it.

Make exceptions decay

Flat networks usually return one exception at a time. A debugging rule admits a broad source range. A migration connects staging to production. A new vendor gets unrestricted egress until its addresses are known. The service recovers, but the route remains.

Treat an exception as a change to attack paths. It needs an owner, exact source and destination, business reason, risk, approval, start and end time, compensating control, validation, rollback, and evidence of removal. Prefer enforcement systems that expire the rule automatically. After expiry, test that the formerly allowed path fails and inspect whether another rule still permits the same reachability.

Broad rules, public administration, unprotected platform endpoints, and unowned outbound destinations are not separate hygiene findings. Each gives a compromised identity or workload another step in a chain. Review them by asking what the attacker can reach next.

Trace one path in both directions

Before release, follow the refund webhook from the provider to the edge, verifier, queue, worker, data operation, and provider egress. At each hop, name the caller identity, requested action, enforcement point, transport protection, log, owner, and expiry or review trigger. Then begin with a compromised verifier and try the routes it must not have: peer discovery, direct data access, management, build, observability, nonproduction, arbitrary egress, and protected platform services.

Include the workload’s platform identity or metadata endpoint in those negative tests. A least-privilege workload identity is weakened if unrelated workloads can obtain its credentials or if compromised code can request broader authority through an unprotected local platform service.

Run the same review for privileged administration. Confirm the public internet cannot reach the control interface directly; the operator must enter through the controlled path; authentication, posture, elevation, authorization, and session evidence work; revocation closes access; and break-glass use produces an immediate, reviewable event.

The architecture is ready when the team can explain why every allowed path exists, demonstrate the corresponding denial, and remove either one without redrawing the system from memory. Chapter 17 takes the next step: proving that even an allowed path cannot silently cross from one tenant’s work into another’s.