HARBOR CLOUD / 04 / PRACTICE GUIDE

Cloud networking, segmentation and service identity

Trace ingress and egress independently. Test default-deny claims against actual CNI behavior, additive permissions and application authorization.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

A one-direction boundary / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.ingressDenied

Ingress denial is not egress denial. CNI enforcement evidence is also required; an accepted manifest does not demonstrate isolation. Retain a legitimate-flow control.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Isolation in both directions

Ingress restriction alone does not prevent outbound data flow. Record source, destination, port/protocol, DNS and dependencies in a flow table. Enforcement needs a supporting CNI; accepting a policy object does not prove packet denial. Verify provider/environment-specific paths such as metadata or management endpoints separately. Capture the initiating source Pod and observed destination outcome.

02 / EXPLANATION

Read additive permissions

Kubernetes NetworkPolicy allowances combine for the selected Pod and direction. A default-deny object does not override another policy’s broad allowance. Evaluate namespace/Pod selectors, all matching policies and both required directions together. network-review.json is only an initial isolation example for both directions; it omits DNS and required service allowances. Applying it to a real cluster is not part of this workshop.

03 / EXPLANATION

TLS, identity and request authority

TLS provides encrypted transport, not authority over every application object. Peer identity verification and request/resource authorization are separate controls. With a service mesh, examine traffic paths bypassing proxies as well. “Mesh enabled” or “443 open” is not an authorization-test outcome. Keep wrong service identity and correct-identity/wrong-tenant requests as distinct negative cases.

04 / EXPLANATION

Worked example: the open egress path

Suppose the Harbor web Pod admits ingress only from the API. If another policy permits all egress, a closed outbound-boundary claim is unsupported. ingressDenied=true and egressDenied=false expose the distinction. An actual plan should list allowed API/DNS and denied internet/management destinations and verify them with the cluster’s plugin. Do not treat timeout alone as policy success: use controls for routing, DNS and destination health. Demonstrate both working legitimate service and denied prohibited traffic.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · ENTest plan and expected resultsMarkdown · ENFinding and retest recordMarkdown · ENRelease decision and evidence traceMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.