feat(rhdh): make OKP opt-in and add NetworkPolicies [RHIDP-16949]

[maysunfaisal]

Description of the change

Adds NetworkPolicies for the Intelligent Assistant OKP workload when OKP is active:

Makes OKP-backed RHDH documentation retrieval optional and disabled by default on OpenShift and Kubernetes.

• Intelligent Assistant remains enabled.
• Without OKP, LCORE uses lightspeed-stack-no-okp.yaml; no OKP resources, RAG configuration, or OKP_SERVICE_URL are rendered.
• Users opt in with intelligentAssistant.okp.enabled=true.
• Documents the large OKP image and potentially longer installation time.
• Adds NetworkPolicies protecting the OKP workload:
  • Default-deny OKP ingress.
  • Allow RHDH/LCORE and the platform router/Ingress controller to reach OKP.
  • Add conditional RHDH egress for HTTP or internal-Service access.
  • Reuse the existing HTTPS egress policy for HTTPS Routes/Ingresses.

The chart version is bumped from 2.4.0 to 2.5.0.

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

https://redhat.atlassian.net/browse/RHIDP-16949

How to test changes / Special notes to the reviewer

Run static validation:

pre-commit run --all-files
helm lint charts/rhdh
ct lint --config ct-lint.yaml --charts charts/rhdh

Deploy with Intelligent Assistant enabled using the platform-specific commands in docs/intelligent-assistant.md, then verify:

kubectl get networkpolicy -n <namespace> | grep okp
kubectl get pods -n <namespace>

OKP configuration, Verify these scenarios using docs/intelligent-assistant.md:

1. OpenShift and Kubernetes with IA enabled and OKP disabled:
   • No OKP workload, networking resources, RAG configuration, or OKP_SERVICE_URL.
2. OpenShift with OKP enabled:
   • OKP Deployment, Service, Route, RAG configuration, and HTTPS OKP_SERVICE_URL are present.
3. Kubernetes with OKP enabled:
   • OKP Deployment, Service, Ingress, registry pull secret, RAG configuration, and OKP_SERVICE_URL are present.
4. When OKP is active:
   • The expected OKP NetworkPolicies are created.
   • The public OKP Route/Ingress is reachable.

Verified on OpenShift with and without OKP. Helm rendering was verified for OpenShift and Kubernetes with and without OKP. Kind rendered the complete HTTPS opt-in configuration and the OKP endpoint returned HTTP 200.

Network Policies:

• OpenShift or Kubernetes HTTPS Ingress: three OKP-specific policies are created. LCORE uses the existing RHDH TCP 443 egress allowance.
• Kubernetes HTTP Ingress: a fourth policy permits RHDH egress on TCP 80.
• Internal Service fallback: the fourth policy permits RHDH egress on TCP 8080.
• The configured OKP_SERVICE_URL and the public OKP Route/Ingress return HTTP 200.

Verified on OpenShift and Kind with both HTTP and HTTPS OKP endpoints. A Backstage-labeled test client successfully reached the public OKP Ingress under the generated policies.

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.

[maysunfaisal]

@rm3l PTAL when you have a chance, thank you

[maysunfaisal]

@rm3l Covered OKP opt in here with this PR as discussed on Slack.

[rm3l]

/agentic_review

[rhdh-qodo-merge]

Code Review by Qodo

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

1. Portal pods allow all egress 🔗 Cross-repo conflict ⛨ Security

Description

The okp-default-deny policy declares only Ingress, conflicting with the accepted rhdh-adr
decision that every managed workload receives component-appropriate default-deny and selective-allow
egress. When rhdh.intelligentAssistant.okp.active is true on a cluster enforcing NetworkPolicy,
any process in an OKP pod can initiate connections to arbitrary destinations instead of only traffic
required by the feature.

Code

charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[R17-18]

+  policyTypes:
+    - Ingress

Relevance

●●● Strong

Default-deny architecture explicitly requires egress isolation; omitting Egress leaves OKP
unrestricted.

PR-#523

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR policy selects OKP pods but places them under ingress isolation only. The accepted
architecture in rhdh-adr explicitly applies default-deny with selective allowances to every
managed workload and requires component-specific egress restrictions, including DNS where needed.

charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[13-18]
charts/rhdh/templates/_helpers.tpl[327-331]
External repo: redhat-developer/rhdh-adr, decisions/006-network-policies-for-rhdh-install-methods.md [25-39]

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 OKP default-deny policy isolates ingress only, leaving outbound connections unrestricted in violation of the accepted cross-repository network-policy architecture.

## Fix Focus Areas
- charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[13-18]

## Recommended Fix
Add `Egress` to the OKP default-deny policy and add narrowly scoped egress allowances only for connections that the OKP workload initiates. Do not add an egress rule merely for Route or Ingress response traffic, because NetworkPolicy permits replies to allowed ingress connections.

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

---

2. Backend reaches arbitrary port-8080 services 🐞 Bug ⛨ Security

Description

The okp-allow-backstage-egress policy omits a destination selector when the OpenShift
internal-Service fallback only needs to reach the colocated OKP pods. When
openshift.clusterRouterBase is unset, every selected RHDH pod can therefore connect to any
reachable service or pod on TCP port 8080 rather than only the OKP workload.

Code

charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[R40-43]

+  egress:
+    - ports:
+        - port: {{ ternary 80 8080 $usesHttpIngress }}
+          protocol: TCP

Relevance

●● Moderate

Scoped egress is least privilege, but recent reviews rejected closely related OKP policy tightening.

PR-#523

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new rule selects the RHDH pods and provides only a port, which Kubernetes interprets as allowing
that port to every destination. The chart otherwise applies ingress-and-egress default deny to those
pods, while the internal fallback URL specifically names the same-namespace OKP Service, so a pod
selector can preserve the intended isolation.

charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[20-43]
charts/rhdh/templates/network-policies.yaml[1-18]
charts/rhdh/templates/_helpers.tpl[359-379]
charts/rhdh/templates/intelligent-assistant/okp-service.yaml[14-20]

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 OpenShift internal-Service fallback adds an unrestricted TCP port 8080 egress rule to RHDH pods even though the generated service URL targets only the chart's OKP workload.

## Fix Focus Areas
- charts/rhdh/templates/intelligent-assistant/okp-network-policies.yaml[40-43]

## Recommended Fix
For the `$usesInternalService` branch, add a `to.podSelector` using `rhdh.intelligentAssistant.okp.selectorLabels` so port 8080 egress reaches only OKP pods in the release namespace. Keep any separately required HTTP-Ingress behavior in its own conditional rule.

ⓘ 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: 02b1e659)

  Explored: repo: redhat-developer/rhdh-must-gather (sha: f253551c)

Review mode: ⚖️ Balanced: This changes Helm runtime behavior and Kubernetes NetworkPolicy enforcement across OpenShift and vanilla Kubernetes, with meaningful connectivity and security blast radius but not enough independent logic density to warrant extended review.

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rm3l]

A small question about the default-deny NP. And the Qodo comments above make sense to address IMO.

[rm3l]

Suggested change

	- Ingress
	- Ingress
	- Egress

Default deny should include both Ingress and Egress by default. Then if needed, you can selectively allow certain destinations like DNS. But I'm curious, does OKP itself need to initiate any outbound connections, given that it's an "Offline Knowledge Portal" serving pre-bundled docs?

[maysunfaisal]

Good point, addressed in latest commit!

[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