[rm3l]

Manual cherrypick of #588

[rhdh-qodo-merge]

PR Summary by Qodo

Scope Orchestrator NetworkPolicies to SonataFlow pods

🐞 Bug fix 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

---

AI Description

• Replace namespace-wide Orchestrator policies with label-scoped rules to preserve isolation for
 other pods.
• Allow required SonataFlow, RHDH, PostgreSQL, infrastructure, and monitoring traffic while
 restricting egress.
• Document the policy behavior and bump the Helm chart version to 3.4.13.

Diagram

graph TD
  Router["OpenShift router"] --> SF["SonataFlow pods"] --> DB[("PostgreSQL")]
  Infra["Infra namespaces"] --> SF --> RHDH["RHDH backend"]
  Monitoring["Monitoring"] --> SF --> External["DNS and APIs"]
  RHDH --> SF
  RHDH --> DB

Loading

High-Level Assessment

Label-scoped policies are the appropriate approach: they retain required Orchestrator connectivity without granting namespace-wide access. Retaining broad selectors would undermine isolation, while relying on separately managed policies would not provide the same chart-controlled behavior.

Files changed (6) +357 / -48

Bug fix (3) +320 / -45

network-policies.yamlAllow SonataFlow ingress to built-in PostgreSQL +34/-0

Allow SonataFlow ingress to built-in PostgreSQL

• When Orchestrator and built-in PostgreSQL are enabled, admits TCP/5432 traffic from SonataFlow-managed pods in the same or other namespaces to the database primary.

charts/rhdh/templates/network-policies.yaml

network-policies.yamlReplace namespace-wide Orchestrator access with scoped policies +283/-45

Replace namespace-wide Orchestrator access with scoped policies

• Adds default-deny policies for Data Index and Jobs Service, then selective rules for SonataFlow-managed pods. Replaces unrestricted namespace egress with rules for inter-pod traffic, RHDH, DNS, HTTPS, the Kubernetes API, PostgreSQL, infrastructure ingress, and optional metrics.

charts/rhdh/templates/orchestrator/network-policies.yaml

sonataflows.yamlLabel the database-creation Job pod for existing policies +3/-0

Label the database-creation Job pod for existing policies

• Applies RHDH selector labels to the Job pod so existing RHDH-to-PostgreSQL NetworkPolicy rules cover its database access.

charts/rhdh/templates/orchestrator/sonataflows.yaml

Documentation (2) +36 / -2

README.mdDocument Orchestrator network access and chart version +19/-2

Document Orchestrator network access and chart version

• Updates the version badge and install example. Describes label-scoped SonataFlow policies, permitted traffic, and the conditions for monitoring and built-in PostgreSQL access.

charts/rhdh/README.md

README.md.gotmplAdd Orchestrator policy guidance to the README source +17/-0

Add Orchestrator policy guidance to the README source

• Adds the NetworkPolicy traffic table and Orchestrator enablement guidance to the documentation template.

charts/rhdh/README.md.gotmpl

Other (1) +1 / -1

Chart.yamlBump chart version to 3.4.13 +1/-1

Bump chart version to 3.4.13

• Increments the Helm chart version for the NetworkPolicy release.

charts/rhdh/Chart.yaml

[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

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (2) 🔗 Cross-repo conflicts (3)

---

🔴 High

1. Database setup stalls on custom ports 🐞 Bug

Description

Adding rhdh.selectorLabels to the create-db Job pod subjects it to the backend's default-deny
egress policy, whose external-database allowance uses externalDatabase.port rather than the Job's
POSTGRES_PORT. When the Orchestrator database uses a different port, including one set through
orchestrator.sonataflowPlatform.externalDB.port, the Job cannot reach it and its database wait
loop runs until the deadline.

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 create-db Job now matches the backend's default-deny policy, but its external database port comes from a different setting than the backend's allowed egress port.

## Fix Focus Areas
- charts/rhdh/templates/orchestrator/sonataflows.yaml[103-108]
- charts/rhdh/templates/network-policies.yaml[103-135]

## Recommended Fix
Give the Job a distinct pod label and a Job-specific egress policy that permits the configured Orchestrator database destination and port. Ensure the policy's port agrees with the POSTGRES_PORT supplied to the Job.

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

Dismiss ↗ | View ↗

---

2. Cross-namespace Data Index becomes unreachable 🔗 Cross-repo conflict

Description

The new backend egress rule permits HTTP traffic only to SonataFlow-managed pods in the chart's
namespace, while the rhdh-plugins Orchestrator backend uses a configurable Data Index URL. When that
URL points to another namespace on HTTP, as in the plugin repository's configuration, its GraphQL
requests cannot use this rule or the chart's existing DNS and HTTPS egress allowances.

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 Orchestrator backend can use a cross-namespace HTTP Data Index URL, but its new egress exception selects only same-namespace pods.
## Fix Focus Areas
- charts/rhdh/templates/orchestrator/network-policies.yaml[307-317]
- charts/rhdh/templates/network-policies.yaml[1-68]
## Recommended Fix
Add an appropriately scoped cross-namespace egress path for the configured Data Index service, while retaining the existing same-namespace allowance.

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

Dismiss ↗ | View ↗

---

View medium (3)

🟠 **Medium**

3. Other namespaces gain database access 🐞 Bug

Description

db-allow-sonataflow-ingress accepts port 5432 connections from pods in every namespace based
solely on the user-settable app.kubernetes.io/managed-by label. A workload created in an unrelated
namespace can claim that label and pass the built-in PostgreSQL pod's network ingress restriction,
though database authentication still applies.

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 new PostgreSQL ingress policy accepts a generic pod label from every namespace, allowing unrelated workloads to opt into database network access.

## Fix Focus Areas
- charts/rhdh/templates/network-policies.yaml[391-402]

## Recommended Fix
Restrict the source to the release namespace by default. If cross-namespace access is required, use an explicitly configured selector for trusted namespaces instead of `namespaceSelector: {}`.

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

Dismiss ↗ | View ↗

---

4. External Kafka workflow triggers fail 🔗 Cross-repo conflict

Description

The new backend egress rule has no allowance for brokers outside the chart namespace, although the
rhdh-plugins Orchestrator backend connects to brokers supplied through orchestrator.kafka. When a
configured broker uses a port not covered by the base egress policies, the plugin's producer
connection fails and CloudEvent workflow execution cannot send its event.

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 Orchestrator backend supports configurable Kafka brokers, but the replacement for unrestricted egress provides no path to brokers on other ports or outside the namespace.
## Fix Focus Areas
- charts/rhdh/templates/orchestrator/network-policies.yaml[307-317]
- charts/rhdh/README.md.gotmpl[428-429]
## Recommended Fix
Provide a configurable or documented additive egress policy for the broker destinations and ports used by Orchestrator Kafka workflows.

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

Dismiss ↗ | View ↗

---

5. External database egress lacks allowlisting 🔗 Cross-repo conflict

Description

When built-in PostgreSQL is disabled, the new SonataFlow egress rule omits to and permits its
configured database port to every destination, contrary to rhdh-adr's external-database
CIDR-and-port model. In external-database deployments, an additive site-specific policy cannot
narrow that already-open destination set.

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 new SonataFlow external-database rule allows every destination on the configured database port, conflicting with the rhdh-adr allowlisting model.
## Fix Focus Areas
- charts/rhdh/templates/orchestrator/network-policies.yaml[218-242]
- charts/rhdh/README.md.gotmpl[418-428]
## Recommended Fix
For external databases, require a configured destination CIDR and port or leave that access to a user-managed additive policy; document the chosen deployment path.

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

Dismiss ↗ | View ↗

---

---

[rhdh-qodo-merge]

Important

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