A network rule was accepted and stored, yet the traffic it forbids still flows — what is missing?
answer
- accepted is not enforced
- a schema check promises nothing
- enforcement lives on every host
- no component means silent no-op
- prove it with a denied connection
basics
~20 sAn enforcing component on the host where the workload runs. A stored rule is only a declaration; something local to each host must translate it into packet filtering; if nothing does, the rule is stored without error and enforces nothing.
solid answer
~50 sAccepting a rule is a schema check performed by the platform's deciding half — it says the document is well formed, not that anything will act on it. Enforcement lives on **every host**: a local component reads the rules that select the workloads running there and programs the host's packet filter in the path their traffic takes. Three things therefore produce a silently unenforced rule: the platform was installed with an attachment driver that does not implement policy at all, so no component ever consults the rules; the component runs on most hosts but is crashed or out of date on the one your workload landed on; or the workload's traffic never passes the filtered path, as with a workload attached to the host's own network view. None of the three reports an error, which is why the only trustworthy verification is an actual denied connection attempt.
code
pseudocode · 13 lineson packet leaving workload W running on host H:
if no enforcing component is running on H:
deliver packet # no rule was ever consulted
rules = component.rulesSelecting(W, direction = outbound)
if rules is empty:
deliver packet # W unselected: the open default still applies
for each rule in rules:
if rule.permits(packet.destination, packet.port):
deliver packet
drop packet # selected, and nothing permitted this destinationgo deeper
Remember that writing a rule and having a rule enforced are two different events. Something on each machine has to act on it, and if nothing does, no error tells you.
Explain the split: the deciding half validates and stores, while a component on every host programs the local packet filter for the workloads placed there, so coverage depends on that component's presence and health.
Show how you would verify rather than assume — a denied connection attempt from an unpermitted peer, a permitted one for a control, per-host health of the enforcing component, and suspicion of zero drops after a default-deny rule.
Treat enforcement coverage as a platform guarantee you either offer or do not. Decide whether the estate can claim segmentation at all, and make that claim testable before any control or audit depends on it.
## A stored rule is a declaration, not a filter When you submit a rule, the platform's deciding half validates its shape and stores it. That acceptance is worth exactly what a schema check is worth. It does not confirm that any component understands the rule, that anything is watching for it, or that a single packet will ever be examined because of it. The gap between "stored" and "enforced" is the defining operational trap of this mechanism, because every observable signal — the rule exists, it is well formed, it names the right workloads — looks correct while nothing is happening. ## Where enforcement actually lives Enforcement is **distributed to every host**. On each host, a component reads the rules that select the workloads currently running locally and programs the local packet filter along the path those workloads' traffic takes. Two properties follow directly: - **Enforcement is local to placement.** Whether your rule is in force for a given replica depends on the health of the component on the host that replica landed on. The same rule can be enforced for nine replicas and not for the tenth. - **Enforcement survives the deciding half.** Once programmed, the filter keeps working if the control plane becomes unavailable; what stops is *new* rules reaching hosts and existing ones being updated as workloads move. ## Three ways a rule is silently a no-op 1. **Nothing implements policy.** The platform can be installed with an attachment driver that provides addresses and routing but no policy enforcement. Rules are still accepted and stored — they are just data nobody reads. This is the classic case and produces no warning anywhere. 2. **Partial or unhealthy coverage.** The component is present on most hosts but crashed, out of date, or not yet started on one. Coverage becomes a function of scheduling, which makes the failure intermittent and reproducible only by placement. 3. **A race at start-up.** A workload can begin serving before the local component has learned which rules select it. Implementations try to program the filter before attaching the workload's network, and they differ in how tightly they guarantee it, so a brief unprotected window is worth asking about rather than assuming away. ## Traffic that never meets the filter Even with healthy enforcement everywhere, some traffic is outside the filtered path by construction: - A workload attached to the **host's own network view** is not using the per-workload path the rules are programmed on, so rules selecting workloads generally do not describe it. - Processes running on the host outside any container are not workloads and are not selected by anything. - Traffic between containers sharing a single network view never crosses the boundary where filtering happens, so no rule sits between them. ## How to prove a rule is enforced Reading the stored rule proves nothing; the only evidence is behaviour. - **Attempt the connection that should be denied**, from a workload the rule does not permit, and confirm it fails — then repeat it from a permitted peer and confirm it succeeds, so you know you tested the rule and not a broken destination. - **Check the enforcing component reports healthy on every host**, not merely that it is installed, and that its version matches what the rules assume. - **Look for a drop signal.** Where the component records denied connections, an absence of any drops after a default-deny rule went live is more likely to mean nothing is enforcing than that nothing was denied. - **Re-test after placement changes.** A test that passed on one host proves that host, and replicas move. | Symptom | Likely cause | |---|---| | No workload is ever blocked, anywhere | Nothing implements policy on this installation | | Blocked for most replicas, not one | The component is unhealthy on that replica's host | | Blocked except for one workload | That workload is attached to the host's own network view | | Was enforced, now stale after moves | Rules are not reaching hosts, though programmed filters still run |
- If the platform's deciding half becomes unavailable, does enforcement stop?No. Filters already programmed on each host keep working, so running workloads stay protected. What stops is change: new rules do not reach hosts, edits do not take effect, and membership is not re-evaluated as workloads move, so enforcement drifts steadily further from what the stored rules say.
- Why is an absence of drop records after a default-deny rule a warning rather than a success?Because a default-deny posture applied to real workloads almost always denies something — a forgotten telemetry push, a stray client, a probe. Complete silence is more consistent with nothing evaluating the rules at all than with a dependency list that was perfect on the first attempt, so it deserves an explicit connection test before being believed.
saying these in an interview costs you the question
- Treats acceptance by the platform as proof the rule is enforced.
- Assumes every installation enforces policy because the rule was storable.
- Expects an error or warning when nothing implements the rule.
- Verifies by reading the stored rule rather than attempting a denied connection.
- Says all traffic on a host passes the per-workload filtered path.
- Claims the control plane going away stops already-programmed filtering.