conformance: verify CNP ingress/egress directional isolation

[vpbh]

What type of PR is this?

/kind test

What this PR does / why we need it:

The existing ClusterNetworkPolicy ingress/egress rule conformance tests only probe
traffic in the same direction as the rules under test — the ingress-rule tests probe
traffic toward the subject, the egress-rule tests probe traffic from the subject. They
never verify the API's directional-independence guarantee:

CNPs with no egress rules do not affect egress traffic
CNPs with no ingress rules do not affect ingress traffic

So an implementation with a cross-direction side-effect (e.g. one that treats "the
subject is selected by a policy" as "isolate the pod in both directions", the way plain
NetworkPolicy's policyTypes works) could pass the entire suite while silently breaking
the subject's traffic in the unspecified direction.

This PR closes that gap. For both the Admin and Baseline tiers it adds:

• an ingress-only CNP, and verifies the subject's egress is unaffected; and
• an egress-only CNP, and verifies the subject's ingress is unaffected.

Each test first asserts a positive control (the one-directional rule is actually
enforced) so the isolation assertions are meaningful, then probes the opposite
direction to namespaces the policy does not reference.

New tests (all gated on the standard ClusterNetworkPolicy feature):

• CNPAdminTierIngressRulesEgressUnaffected
• CNPAdminTierEgressRulesIngressUnaffected
• CNPBaselineTierIngressRulesEgressUnaffected
• CNPBaselineTierEgressRulesIngressUnaffected

Which issue(s) this PR fixes:

Fixes #103

Special notes for your reviewer:

• The isolation probes deliberately target ravenclaw and hufflepuff —
  namespaces the policy never references — so the connection's reply path cannot be
  affected by the rule under test and confound the result (e.g. a deny-to-slytherin
  egress rule could affect the reply path of an inbound connection from slytherin on
  a stateless dataplane). Using unreferenced peers isolates the property cleanly.
• I implemented these as dedicated tests + minimal single-direction manifests
  rather than appending probes to the existing *-rules.go tests, because those tests
  mutate their policy mid-run (PatchClusterNetworkPolicy rule-reordering), which would
  make appended probes order-dependent. Happy to fold them into the existing files
  instead if you'd prefer — the probe logic is identical.
• Scope: TCP only, since directional isolation is protocol-independent. Glad to add
  UDP/SCTP variants if you'd like them.
• No API or codegen changes — purely additive conformance tests.

Does this PR introduce a user-facing change?

NONE

[k8s-ci-robot]

@vpbh: The label(s) kind/test cannot be applied, because the repository doesn't have them.

Details

In response to this:

What type of PR is this?

/kind test

What this PR does / why we need it:

The existing ClusterNetworkPolicy ingress/egress rule conformance tests only probe
traffic in the same direction as the rules under test — the ingress-rule tests probe
traffic toward the subject, the egress-rule tests probe traffic from the subject. They
never verify the API's directional-independence guarantee:

CNPs with no egress rules do not affect egress traffic
CNPs with no ingress rules do not affect ingress traffic

So an implementation with a cross-direction side-effect (e.g. one that treats "the
subject is selected by a policy" as "isolate the pod in both directions", the way plain
NetworkPolicy's policyTypes works) could pass the entire suite while silently breaking
the subject's traffic in the unspecified direction.

This PR closes that gap. For both the Admin and Baseline tiers it adds:

• an ingress-only CNP, and verifies the subject's egress is unaffected; and
• an egress-only CNP, and verifies the subject's ingress is unaffected.

Each test first asserts a positive control (the one-directional rule is actually
enforced) so the isolation assertions are meaningful, then probes the opposite
direction to namespaces the policy does not reference.

New tests (all gated on the standard ClusterNetworkPolicy feature):

• CNPAdminTierIngressRulesEgressUnaffected
• CNPAdminTierEgressRulesIngressUnaffected
• CNPBaselineTierIngressRulesEgressUnaffected
• CNPBaselineTierEgressRulesIngressUnaffected

Which issue(s) this PR fixes:

Fixes #103

Special notes for your reviewer:

• The isolation probes deliberately target ravenclaw and hufflepuff —
  namespaces the policy never references — so the connection's reply path cannot be
  affected by the rule under test and confound the result (e.g. a deny-to-slytherin
  egress rule could affect the reply path of an inbound connection from slytherin on
  a stateless dataplane). Using unreferenced peers isolates the property cleanly.
• I implemented these as dedicated tests + minimal single-direction manifests
  rather than appending probes to the existing *-rules.go tests, because those tests
  mutate their policy mid-run (PatchClusterNetworkPolicy rule-reordering), which would
  make appended probes order-dependent. Happy to fold them into the existing files
  instead if you'd prefer — the probe logic is identical.
• Scope: TCP only, since directional isolation is protocol-independent. Glad to add
  UDP/SCTP variants if you'd like them.
• No API or codegen changes — purely additive conformance tests.

Does this PR introduce a user-facing change?

NONE

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[netlify]

✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!

Name	Link
🔨 Latest commit	896ee81
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-network-policy-api/deploys/6a3441ae7cd3940008375a18
😎 Deploy Preview	https://deploy-preview-386--kubernetes-sigs-network-policy-api.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vpbh
Once this PR has been reviewed and has the lgtm label, please assign tssurya for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @vpbh!

It looks like this is your first PR to kubernetes-sigs/network-policy-api 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/network-policy-api has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @vpbh. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: vpbh / name: Vinay Pai (896ee81)