chore: Updating Orchestrator flavour NetworkPolicies to SonataFlow-specific labels

[OpinionatedHeron]

Description of the change

The Orchestrator flavour NetworkPolicies currently use podSelector: {} (namespace-wide), which conflicts with the ADR's "default deny with selective allow" and "label-scoped policies" principles.

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

• RHDHBUGS-3716

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.

[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]

/cc

[rm3l]

/agentic_review

[rm3l]

/cherrypick release-2.1

[openshift-cherrypick-robot]

@rm3l: once the present PR merges, I will cherry-pick it on top of release-2.1 in a new PR and assign it to you.

Details

In response to this:

/cherrypick release-2.1

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.

[rhdh-qodo-merge]

Code Review by Qodo

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

1. Orchestrator loses database access 🔗 Cross-repo conflict ≡ Correctness

Description

Removing allow-intra-network leaves bundled PostgreSQL’s default-deny policy admitting TCP/5432
traffic only from RHDH backend pods; the replacement policy admits traffic only to SonataFlow
destinations on port 80. With the default postgresql.enabled=true, the database-creation Job
cannot create the sonataflow database, and Data Index and Job Service cannot connect to the
PostgreSQL dependency also specified by rhdh-operator.

Code

charts/rhdh/templates/orchestrator/network-policies.yaml[73]

-      - podSelector: {}

Relevance

●●● Strong

Concrete PostgreSQL regression: SonataFlow Job and services lose required port 5432 access under the
new label-scoped policies.

PR-#523

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The removed rule admitted traffic from any pod in the namespace, but its replacement selects only
SonataFlow destinations on port 80. Built-in PostgreSQL is enabled by default, and its policy admits
ingress on port 5432 only from backend-labeled pods; the Orchestrator templates direct the
database-creation Job and both generated services to that database, consistent with the dependency
declared in rhdh-operator.

rhdh-chart -> rhdh-operator
charts/rhdh/templates/orchestrator/network-policies.yaml[68-80]
charts/rhdh/templates/network-policies.yaml[283-316]
charts/rhdh/templates/orchestrator/sonataflows.yaml[40-79]
charts/rhdh/templates/orchestrator/sonataflows.yaml[120-138]
charts/rhdh/values.yaml[464-468]
charts/rhdh/templates/network-policies.yaml[287-324]
charts/rhdh/templates/orchestrator/sonataflows.yaml[40-77]
charts/rhdh/templates/orchestrator/sonataflows.yaml[104-136]
charts/rhdh/templates/orchestrator/sonataflows.yaml[200-210]
charts/rhdh/templates/orchestrator/network-policies.yaml[92-106]
External repo: redhat-developer/rhdh-operator, config/profile/rhdh/plugin-deps/sonataflow.yaml [40-71]

Agent prompt

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

## Issue description
Removing the namespace-wide ingress allowance blocks the Orchestrator database-creation Job, Data Index, and Job Service from bundled PostgreSQL.

## Fix Focus Areas
- charts/rhdh/templates/orchestrator/network-policies.yaml[68-106]
- charts/rhdh/templates/network-policies.yaml[283-324]
- charts/rhdh/templates/orchestrator/sonataflows.yaml[40-113]

## Recommended Fix
When Orchestrator and bundled PostgreSQL are enabled, add a narrowly scoped PostgreSQL ingress allowance on TCP/5432 for the SonataFlow service pods and database-creation Job. Give the Job pod a specific label and include it in the ingress allowance, while retaining the existing RHDH backend allowance without restoring namespace-wide access. Test that the Job and both services can connect.

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

Dismiss ↗ | View ↗

---

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) — View relationship

  Explored: repo: redhat-developer/rhdh-operator (sha: 36d43adf) — View relationship

Review mode: Auto: ⚖️ Balanced: NetworkPolicy behavior changes carry security risk across multiple traffic paths.

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rm3l]

@OpinionatedHeron I agree with Qodo's review comment here.. Looks like the Sonataflow data-index and job services can no longer connect to the DB because of the new orch NPs:

and should not be used anymore.
2026-10-06 14:33:15,160 ERROR [io.qua.run.Application] (main) Failed to start application: java.lang.RuntimeException: Failed to start quarkus
        at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
        at io.quarkus.runtime.Application.start(Application.java:101)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:119)        
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:80)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:51)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:144)
        at io.quarkus.runner.GeneratedMain.main(Unknown Source)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:69)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:37)
Caused by: org.flywaydb.core.internal.exception.sqlExceptions.FlywaySqlUnableToConnectToDbException: Unable to obtain connection from database: Acquisition timeout while waiting for new connection
-----------------------------------------------------------------------------------------------
SQL State  : null
Error Code : 0
Message    : Acquisition timeout while waiting for new connection

        at org.flywaydb.core.internal.jdbc.JdbcUtils.openConnection(JdbcUtils.java:70)
        at org.flywaydb.core.internal.jdbc.JdbcConnectionFactory.<init>(JdbcConnectionFactory.java:76)     
        at org.flywaydb.core.FlywayExecutor.execute(FlywayExecutor.java:142)
        at org.flywaydb.core.Flyway.migrate(Flyway.java:186)
        at io.quarkus.flyway.runtime.FlywayRecorder.doStartActions(FlywayRecorder.java:150)
        at io.quarkus.runner.recorded.FlywayProcessor$startActions1575138505.deploy_0(Unknown Source)      
        at io.quarkus.runner.recorded.FlywayProcessor$startActions1575138505.deploy(Unknown Source)        
        ... 9 more
Caused by: java.sql.SQLException: Acquisition timeout while waiting for new connection
        at io.agroal.pool.ConnectionPool.handlerFromSharedCache(ConnectionPool.java:394)
        at io.agroal.pool.ConnectionPool.getConnection(ConnectionPool.java:308)
        at io.agroal.pool.DataSource.getConnection(DataSource.java:86)
        at io.agroal.api.AgroalDataSource_83v3mgZs1bc75ou7lAXNtJCAcLA_Synthetic_ClientProxy.getConnection(Unknown Source)
        at org.flywaydb.core.internal.jdbc.JdbcUtils.openConnection(JdbcUtils.java:65)
        ... 15 more
Caused by: java.util.concurrent.TimeoutException
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
        at io.agroal.pool.ConnectionPool.handlerFromSharedCache(ConnectionPool.java:372)
        ... 19 more