Learning outcomes
- Baseline every user, workload, protocol, identity, route, and application action.
- Define explicit policy and upstream isolation before cutover.
- Migrate in stages with positive, negative, bypass, and failure tests.
- Remove obsolete network access, credentials, exceptions, and recovery paths.
Operating objective
One application moves from implicit location-based access to named resource and action policy without losing required users, automation, protocols, application identity, availability, evidence, or recovery. The migration removes the old path instead of adding a permanent parallel gateway.
Signals and evidence
Baseline DNS names, addresses, ports, protocols, clients, identities, groups, devices, workloads, service credentials, routes, methods, object actions, direct paths, dependencies, traffic volume, errors, latency, owners, evidence, emergency access, and recovery. Observe dormant and scheduled clients, not only current traffic.
Response and recovery
- Name the resource and required actions.
- Define human and workload identity and lifecycle.
- Design default-deny route and application policy.
- Place the enforcement point and restrict the upstream to it.
- Build positive, negative, direct-path, stale-context, dependency-failure, and rollback tests.
- Run a shadow or bounded pilot without treating observed traffic as complete authorization intent.
- Cut over in stages and monitor gateway and application results.
- Remove old DNS, firewall, VPN, credential, account, route, exception, and recovery paths.
- Prove the old path fails and the new path recovers from known-good state.
Design tradeoffs and residual risk
Parallel operation reduces cutover risk and leaves bypass. Traffic-derived policy finds real use and can encode historic excess authority. Fast removal closes exposure and can miss dormant clients. Rollback improves recovery and can reopen implicit trust.
Residual risk includes unknown clients, application-local accounts, hard-coded credentials, direct origins, unsupported protocols, and downstream authorization gaps.
Pomerium boundary
Pomerium can provide the named route and route-level identity-aware policy. Operators own discovery, identity-provider and client changes, upstream isolation, application authorization, protocol coverage, old-path removal, support, and recovery.
Exercise
Migrate one staging application with a browser user, API client, administrator, and scheduled workload. Capture the baseline and policy, then cut over. Test another user, wrong object, stale group, direct origin, identity outage, gateway outage, and rollback.
Evaluation checklist
- Does the baseline cover every client, protocol, identity, action, and recovery path?
- Is the new route default deny and tied to named resources and actions?
- Does the upstream reject all old and direct paths?
- Can required service recover without restoring implicit trust?
- Are obsolete credentials, accounts, DNS, routes, rules, and exceptions removed?
Next learning unit
Zero Trust
Zero trust does not assume that every user or device is malicious.
