RHOAIENG-57443: Permissive head NetworkPolicy egress for default-deny

[DavidAdaRH]

rh-pre-commit.version: 2.3.2
rh-pre-commit.check-secrets: ENABLED

Why are these changes needed?

When the odh.ray.io/secure-trusted-network annotation is enabled, the head pod's NetworkPolicy previously only declared PolicyTypeIngress. In clusters that also apply a namespace-level default-deny egress policy, this meant the head pod's outbound traffic was blocked — preventing the Ray autoscaler sidecar from reaching the Kubernetes API server, DNS, and worker pods, causing autoscaling to fail.

This change adds PolicyTypeEgress to the head NetworkPolicy with a single allow-all egress rule. A permissive egress rule is used rather than enumerating specific destinations because the head pod's egress requirements are platform-dependent (DNS, Kubernetes API, workers, node-local services, platform-specific OVN/SDN paths, etc.). The primary security boundary for the head pod remains the ingress rules.

Related issue number

Closes RHOAIENG-57443

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests
  • Manual tests
  • This PR is not tested :(

Manual testing performed

• Deployed custom operator build to an OpenShift cluster with network policies enabled (no Kueue)
• Verified the head NetworkPolicy is generated with policyTypes: ["Ingress", "Egress"] and egress: [{}] automatically from the annotation — no manual editing required
• Confirmed the head pod can reach the Kubernetes API server and resolve DNS through the egress rule
• Confirmed the autoscaler sidecar starts, connects to GCS and the Kubernetes API, and runs update iterations successfully

Summary by CodeRabbit

• New Features
  • Head NetworkPolicy now includes both ingress and egress; egress is configured as a single allow-all rule (no port or peer restrictions).
• Tests
  • Unit and controller tests updated to verify the head NetworkPolicy declares ingress and egress and that the egress rule permits all destinations/ports.

[coderabbitai]

Warning

Rate limit exceeded

@DavidAdaRH has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 47 minutes and 7 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 198225ea-9314-4b44-8288-03890b6bec01

📥 Commits

Reviewing files that changed from the base of the PR and between a7f5517 and f925d95.

📒 Files selected for processing (3)

• ray-operator/controllers/ray/networkpolicy_controller.go
• ray-operator/controllers/ray/networkpolicy_controller_test.go
• ray-operator/controllers/ray/networkpolicy_controller_unit_test.go

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[DavidAdaRH]

/run-kuberay-e2e

[rhods-ci-bot]

@DavidAdaRH: The following test has Succeeded:

OCI Artifact Browser URL

View in Artifact Browser

Inspecting Test Artifacts Manually

To inspect your test artifacts manually, follow these steps:

1. Install ORAS (see the ORAS installation guide).
2. Download artifacts with the following commands:

mkdir -p oras-artifacts
cd oras-artifacts
oras pull quay.io/opendatahub/odh-ci-artifacts:odh-pr-test-kuberay-tkhq4

[chipspeak]

This creates an open, broad rule as per the comments but we actually don't need it. If we use the upstream DenyAllIngress when its merged, it will achieve the same by implicitly allowing all egress. Additionally, we actually already have implicitly open egress rules as we don't define any and NetworkPolicy treats this the same as an open rule. @DavidAdaRH can you manually verify that auto-scaling works without your changes just to fact check me?