[rm3l]

Description of the change

Adds an allow-http-egress NetworkPolicy to the chart's default NP set, allowing egress on port 80 only to cluster-internal destinations (namespaceSelector: {}).

This fixes OIDC discovery timeouts when Keycloak (or other in-cluster services) runs behind a plain HTTP route without TLS termination. The existing default-deny NPs only allow egress on ports 443, 53/5353, 5432, and 6379, which blocks port 80 traffic.

Which issue(s) does this PR fix or relate to

• Related to RHIDP-14274

How to test changes / Special notes to the reviewer

helm template my-rhdh charts/rhdh --set orchestrator.enabled=false | grep -A 20 allow-http-egress

Verify the NP has:

• namespaceSelector: {} in the to block (in-cluster only)
• Port 80/TCP

Companion operator PR: redhat-developer/rhdh-operator#3626

Checklist

• For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
• For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Run pre-commit run --all-files to run the hooks and then push any resulting changes. The pre-commit Workflow will enforce this and warn you if needed.
• JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
• Tests pass using the Chart Testing tool and the ct lint command.
• If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

[rhdh-qodo-merge]

PR Summary by Qodo

Allow cluster-internal HTTP egress for RHDH workloads

🐞 Bug fix ✨ Enhancement 🕐 Less than 10 minutes

AI Description

• Allows RHDH pods to reach HTTP services in any cluster namespace over TCP 80.
• Keeps external HTTP egress blocked while preventing in-cluster OIDC discovery timeouts.

Diagram

graph TD
  A["RHDH Pods"] --> B{"HTTP destination"} -->|Cluster namespace| C["HTTP allow policy"] -->|TCP 80| D["Internal service"]
  B -->|External endpoint| E["Default deny"]

Loading

High-Level Assessment

The additive, destination-restricted NetworkPolicy fits the chart’s existing default-deny and selective-allow model. Allowing unrestricted port 80 would weaken egress controls, while requiring every user to define a custom policy would preserve the OIDC timeout problem in common in-cluster deployments.

Files changed (1) +27 / -0

Bug fix (1) +27 / -0

network-policies.yamlPermit HTTP egress to cluster namespaces +27/-0

Permit HTTP egress to cluster namespaces

• Adds an additive egress NetworkPolicy selecting RHDH pods and allowing TCP port 80 only to destinations selected by 'namespaceSelector: {}'. The policy reuses existing chart labels, selectors, and common annotation rendering while leaving external HTTP traffic blocked.

charts/rhdh/templates/network-policies.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. The new policy has no chart release ✓ Resolved 🐞 Bug ≡ Correctness

Description

charts/rhdh/Chart.yaml remains at version 3.4.0 even though this template adds a new default
NetworkPolicy. The repository requires every updated chart to bump its semantic version, and an
unchanged version also skips chart upgrade testing, leaving the feature without a distinct release
identity or upgrade coverage.

Code

charts/rhdh/templates/network-policies.yaml[R73-76]

+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: {{ include "rhdh.fullname" . }}-allow-http-egress

Relevance

●●● Strong

Recent chart changes treat version bumps and generated documentation as required release
maintenance.

PR-#523
PR-#542

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new policy is an externally visible chart feature, while Chart.yaml still identifies the package
as 3.4.0. Repository contribution rules require a semantic-version bump for every updated chart, and
the chart test action explicitly skips upgrade tests when the version is unchanged.

charts/rhdh/templates/network-policies.yaml[69-94]
charts/rhdh/Chart.yaml[1-6]
CONTRIBUTING.md[5-10]
.github/actions/test-charts/action.yml[328-345]
.github/workflows/release.yaml[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The RHDH chart adds a new default NetworkPolicy without changing its chart version, so the release process cannot distinguish this feature from version 3.4.0 and CI skips upgrade testing.

## Fix Focus Areas
- charts/rhdh/Chart.yaml[1-6]
- charts/rhdh/README.md[35-42]

## Recommended Fix
Bump the chart version from 3.4.0 to the appropriate backward-compatible feature release, normally 3.5.0, and regenerate any documentation that embeds the chart version.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Backends reach every namespace 🔗 Cross-repo conflict ⛨ Security

Description

The new allow-http-egress policy places namespaceSelector: {} in an always-on rule, although ADR
006 assigns egress outside DNS, API, PostgreSQL, and HTTPS to flavour-conditional or user-managed
additive policies. Whenever default policies are enforced, every selected RHDH backend can connect
over TCP port 80 to pods in every namespace, including unrelated workloads, rather than only an
explicitly approved OIDC service.

Code

charts/rhdh/templates/network-policies.yaml[R90-93]

+    - to:
+        - namespaceSelector: {}
+      ports:
+        - port: 80

Relevance

●● Moderate

Evidence is mixed: broad namespace policies were rejected previously, but newer policy reviews favor
narrowing unrestricted egress.

PR-#523
PR-#544

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR adds an unconditional egress peer selecting every namespace on TCP port 80. ADR 006 limits
always-on base egress to enumerated flows and explicitly assigns additional endpoint traffic to
flavour-conditional or user-managed additive policies.

charts/rhdh/templates/network-policies.yaml[69-94]
External repo: redhat-developer/rhdh-adr, decisions/006-network-policies-for-rhdh-install-methods.md [51-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chart adds broad, always-on port 80 egress to every cluster namespace, conflicting with ADR 006's accepted model for additional customer-specific egress.

## Fix Focus Areas
- charts/rhdh/templates/network-policies.yaml[69-94]
- /cross_repos/rhdh-adr/decisions/006-network-policies-for-rhdh-install-methods.md[51-76]

## Recommended Fix
Remove the always-on HTTP policy and provide a documented additive NetworkPolicy example that users can restrict to the intended namespace and pods. If broad internal HTTP is now an intended base capability, coordinate and accept an ADR amendment before changing the chart behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. External HTTP is documented as allowed ✓ Resolved 🐞 Bug ≡ Correctness

Description

charts/rhdh/README.md still describes TCP/80 as allowed to “Any destination” solely for LCORE,
while the new rule selects only pod destinations in cluster namespaces and supports general
in-cluster HTTP. Users troubleshooting an external HTTP endpoint are therefore told it should be
reachable even though the default-deny policy and this namespace-scoped exception still block it.

Code

charts/rhdh/templates/network-policies.yaml[R90-93]

+    - to:
+        - namespaceSelector: {}
+      ports:
+        - port: 80

Relevance

●●● Strong

Recent accepted findings require README documentation to match changed chart behavior and defaults.

PR-#542

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The chart begins with default-deny egress, and the added TCP/80 exception has a namespaceSelector
rather than an unrestricted destination. The README's copied policy inventory instead labels port 80
as reaching any destination and describes it only as an LCORE-specific allowance.

charts/rhdh/templates/network-policies.yaml[1-17]
charts/rhdh/templates/network-policies.yaml[89-94]
charts/rhdh/README.md[563-580]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The NetworkPolicies documentation says TCP/80 reaches any destination, but the new policy permits only pod destinations selected through cluster namespaces and has a broader purpose than LCORE access.

## Fix Focus Areas
- charts/rhdh/README.md[563-580]
- charts/rhdh/templates/network-policies.yaml[69-94]

## Recommended Fix
Update the TCP/80 table entry and surrounding explanation to state that the always-present rule permits HTTP only to cluster-internal pod destinations, including its OIDC and plugin use cases, while external HTTP remains blocked.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Cross-repo context — repo relationships

  Explored: repo: redhat-developer/rhdh-adr (sha: 571bd0f0)

  ⚠️ Failed to retrieve: redhat-developer/rhdh-operator

Review mode: ⚖️ Balanced: This is a runtime Kubernetes NetworkPolicy change affecting egress permissions and cluster connectivity, so it warrants a complete review despite being a small, localized diff.

Tip of the day

💡 Did you know, you can choose which labels appear on a finding, and whether they show icons or text

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rhdh-qodo-merge]

Important

The /generate_labels command by Qodo is sunsetting on the 1st of October 2026 and will no longer be available. We recommend switching to the latest Qodo review capabilities. Learn more

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rm3l]

May not be needed anymore