An attacker compromises one container in your cluster. What should your network controls prevent, and what can they not help with?

What is being tested

Whether you understand network controls as a containment layer rather than as the primary security boundary — and where their limits are.

What network controls should prevent

Lateral movement. The compromised container should be able to reach only what its function requires. Default-deny egress and ingress, with explicit allowances, means the attacker's next hop is blocked rather than free.

Reaching data stores directly. A database that accepts connections only from a specific service identity or security group cannot be reached from a compromised frontend container.

Exfiltration. This is the control most often missing. Ingress is usually restricted and egress usually is not, and egress is precisely the path data leaves by. Default-deny outbound with an allowlist of required destinations is the single highest-value network control against a successful compromise.

Reaching the control plane and metadata services. The instance metadata endpoint is a classic privilege escalation path — it can hand out credentials. It should be blocked or restricted from workload containers.

What network controls cannot help with

Identity. A network rule says "this address may connect", not "this service, with this identity, may perform this action". Anything that reaches the right network position inherits the trust. In a container environment addresses are ephemeral and shared, so network position is a weak proxy for identity.

Anything the compromised container is legitimately allowed to do. If it may read the user database, the attacker may read the user database. Network segmentation does not constrain the compromised workload's own permissions — only application-level authorisation and least-privilege credentials do.

Application-layer attacks over permitted connections: injection, deserialisation, abuse of a legitimate API.

Encrypted exfiltration to an allowed destination — for example, data pushed to a permitted cloud storage endpoint.

The layered answer

This is why the perimeter model — hard shell, soft interior — stopped being sufficient. The assumption that being inside the network means being trusted fails against remote work, cloud services, contractors, and the reality that most serious breaches involve an attacker already inside.

The alternative, articulated most clearly in Google's BeyondCorp work, derives trust from the identity of the caller and the state of the device, evaluated per request, rather than from network location. There is no privileged network; a request from the office and one from a coffee shop are authenticated and authorised identically.

In practice both layers matter and the ordering changed:

• Workload identity (mTLS, signed service identity) so services authenticate each other rather than trusting an address.
• Least-privilege credentials, short-lived, scoped to what the workload actually needs.
• Authorisation in the application, where the semantics live.
• Network controls as defence in depth, limiting what a compromise can reach next.
• Egress filtering and detection, because containment failing quietly is worse than containment failing loudly.

The point to make in a review

A design whose only protection is "it is inside the VPC" has one compromise between an attacker and everything. Network controls are cheap, coarse, enforceable independently of application code, and genuinely valuable — and insufficient alone.