# Cloud networking, segmentation and service identity Trace ingress and egress independently. Test default-deny claims against actual CNI behavior, additive permissions and application authorization. Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress. Sources checked: 2026-10-21 ## 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. ## 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. ## 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. ## 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. ## Working sequence 1. Map permitted data flows. 2. Design ingress and egress separately. 3. Review CNI and all matching policies. 4. Test permitted and prohibited paths end to end. 5. Verify service identity and application authorization. ## 1. A one-direction boundary Ingress denial is not egress denial. CNI enforcement evidence is also required; an accepted manifest does not demonstrate isolation. Retain a legitimate-flow control. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.ingressDenied ``` ### Corrected implementation ```js s=>s.ingressDenied&&s.egressDenied&&s.cniEnforces ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "both-directions", "input": { "ingressDenied": true, "egressDenied": true, "cniEnforces": true }, "expected": true, "observed": true, "matched": true }, { "name": "egress-open", "input": { "ingressDenied": true, "egressDenied": false, "cniEnforces": true }, "expected": false, "observed": true, "matched": false }, { "name": "unsupported-plugin", "input": { "ingressDenied": true, "egressDenied": true, "cniEnforces": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "both-directions", "input": { "ingressDenied": true, "egressDenied": true, "cniEnforces": true }, "expected": true, "observed": true, "matched": true }, { "name": "egress-open", "input": { "ingressDenied": true, "egressDenied": false, "cniEnforces": true }, "expected": false, "observed": false, "matched": true }, { "name": "unsupported-plugin", "input": { "ingressDenied": true, "egressDenied": true, "cniEnforces": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## 2. Another policy permits broadly A default-deny object does not override additive allowances. Establish both the absence of another matching allowance and an observed end-to-end denial. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.denyPolicyExists ``` ### Corrected implementation ```js s=>s.denyPolicyExists&&!s.otherPolicyAllows&&s.endToEndDenied ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "denial-observed", "input": { "denyPolicyExists": true, "otherPolicyAllows": false, "endToEndDenied": true }, "expected": true, "observed": true, "matched": true }, { "name": "additive-allow", "input": { "denyPolicyExists": true, "otherPolicyAllows": true, "endToEndDenied": false }, "expected": false, "observed": true, "matched": false }, { "name": "untested-route", "input": { "denyPolicyExists": true, "otherPolicyAllows": false, "endToEndDenied": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "denial-observed", "input": { "denyPolicyExists": true, "otherPolicyAllows": false, "endToEndDenied": true }, "expected": true, "observed": true, "matched": true }, { "name": "additive-allow", "input": { "denyPolicyExists": true, "otherPolicyAllows": true, "endToEndDenied": false }, "expected": false, "observed": false, "matched": true }, { "name": "untested-route", "input": { "denyPolicyExists": true, "otherPolicyAllows": false, "endToEndDenied": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## 3. Encrypted but unauthorized TLS needs peer identity and request authority alongside it. Blocking metadata access is a separate condition of this fictional profile; the model does not test a provider path. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.tls ``` ### Corrected implementation ```js s=>s.tls&&s.peerIdentityVerified&&s.requestAuthorized&&!s.metadataReachable ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "bounded-service", "input": { "tls": true, "peerIdentityVerified": true, "requestAuthorized": true, "metadataReachable": false }, "expected": true, "observed": true, "matched": true }, { "name": "tls-only", "input": { "tls": true, "peerIdentityVerified": false, "requestAuthorized": false, "metadataReachable": true }, "expected": false, "observed": true, "matched": false }, { "name": "unauthorized-request", "input": { "tls": true, "peerIdentityVerified": true, "requestAuthorized": false, "metadataReachable": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "bounded-service", "input": { "tls": true, "peerIdentityVerified": true, "requestAuthorized": true, "metadataReachable": false }, "expected": true, "observed": true, "matched": true }, { "name": "tls-only", "input": { "tls": true, "peerIdentityVerified": false, "requestAuthorized": false, "metadataReachable": true }, "expected": false, "observed": false, "matched": true }, { "name": "unauthorized-request", "input": { "tls": true, "peerIdentityVerified": true, "requestAuthorized": false, "metadataReachable": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## Exit evidence - Source/destination/port/direction and policy-match table - Observed denial alongside legitimate-flow controls ## References - [Kubernetes · NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - [Kubernetes · RBAC good practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/)