ADR-006: Tailored NetworkPolicies for RHDH deployments [RHDHPLAN-1032] by rm3l · Pull Request #8 · redhat-developer/rhdh-adr

rm3l · 2026-06-01T08:37:19Z

Summary

Proposes adding default-deny NetworkPolicies scoped to RHDH-labeled pods for both operands and Helm chart deployments as well as base policies for known traffic.
Leverages the additive nature of NetworkPolicies for user extensibility. Users create their own policies for site-specific traffic, no CRD change needed
Covers disconnected environments, Lightspeed, Orchestrator, and external database scenarios

Assisted-by: Claude

@polasudo For the "OCI registry egress in base policies", yes, it makes sense to add a note about that, especially when the default deployment would need to fetch plugins from registry.access.redhat.com or quay.io or even ghcr.io for community plugins. I'll add a note about that in the ADR. Anyway, we have a spike task to analyze and map RHDH traffic flows, which would help concretely define the base policies rules.
As for the "common plugin egress" policy template, do you mean something users can copy and customize when configuring their own policy rules? If so, that could be a great addition to the Documentation bullet point, I think.

polasudo · 2026-06-01T12:06:06Z

I have few points as a reminder Include OCI registry egress in base policies or some sort of egress from registry Add a "common plugin egress" policy template
that is my concern that I can think of. What do you think about it ?

@polasudo For the "OCI registry egress in base policies", yes, it makes sense to add a note about that, especially when the default deployment would need to fetch plugins from registry.access.redhat.com or quay.io or even ghcr.io for community plugins. I'll add a note about that in the ADR. Anyway, we have a spike task to analyze and map RHDH traffic flows, which would help concretely define the base policies rules. As for the "common plugin egress" policy template, do you mean something users can copy and customize when configuring their own policy rules? If so, that could be a great addition to the Documentation bullet point, I think.

Yes I was thinking abut some sort of policy template that would guide users to to pull plugins from ghcr for example or from some registry

…to docs Add OCI (registry.access.redhat.com, quay.io) and NPM (npm.registry.redhat.com) plugin registries to base egress policies. Mention ready-to-use NetworkPolicy templates for common scenarios in the documentation guidance. Assisted-by: Claude Co-authored-by: Martin Polaško <50864147+polasudo@users.noreply.github.com>

rm3l · 2026-06-01T12:13:20Z

I have few points as a reminder Include OCI registry egress in base policies or some sort of egress from registry Add a "common plugin egress" policy template
that is my concern that I can think of. What do you think about it ?

@polasudo For the "OCI registry egress in base policies", yes, it makes sense to add a note about that, especially when the default deployment would need to fetch plugins from registry.access.redhat.com or quay.io or even ghcr.io for community plugins. I'll add a note about that in the ADR. Anyway, we have a spike task to analyze and map RHDH traffic flows, which would help concretely define the base policies rules. As for the "common plugin egress" policy template, do you mean something users can copy and customize when configuring their own policy rules? If so, that could be a great addition to the Documentation bullet point, I think.

Yes I was thinking abut some sort of policy template that would guide users to to pull plugins from ghcr for example or from some registry

makes sense. Updated in 734221b (this PR).

gazarenkov

Classification makes it more clear, thanks.

2 things:

I guess I miss some decision details to understand how exactly we are going to implement it in each case (static manifest to provide, dynamicaly created etc)
I would not totally reject CNP (as discussed)

gazarenkov · 2026-06-19T10:12:10Z

+- **Clear boundary between base and user-managed policies**: The base policies shipped by the Operator and Helm chart cover DNS, API server access, PostgreSQL, broad HTTPS egress for the RHDH backend, and Orchestrator cross-namespace traffic. Egress on non-standard ports or to destinations not reachable over HTTPS (e.g., corporate proxies on custom ports) is the user's responsibility to allow via additive policies.
+- **User-extensible via additive policies**: This split is possible because Kubernetes NetworkPolicies are **additive**: once a default-deny policy selects a pod, any additional NetworkPolicy matching that pod can only add more allow rules, never remove existing ones. Users who need to allow additional site-specific traffic simply create their own NetworkPolicy resources in the same namespace. These compose naturally with the base policies without any CRD or Helm values change. The base NetworkPolicies are always present and cannot be disabled. On clusters without NetworkPolicy enforcement, they simply have no effect
+- **Documentation**: Clear documentation is essential to make this approach work in practice. Users need to understand which base policies are shipped, what traffic they allow and deny, how to create additional NetworkPolicies for their site-specific needs, and how to troubleshoot connectivity issues caused by policies. Documentation should also clarify the requirement for a NetworkPolicy-capable CNI plugin on non-OCP platforms, and provide ready-to-use NetworkPolicy templates for common plugin egress scenarios (e.g., GitHub/GitLab SCM access, Quay/Artifactory registries, OIDC providers) that users can copy and adapt for their environment
+- **Label-scoped policies**: Since RHDH is a layered product deployed into potentially shared namespaces, policies use `podSelector` with RHDH-specific labels rather than namespace-wide selectors, following the OCP best practice for layered products


I believe the values are stable (even if not the same for Chart and Operator) and have to be specified and known outside of implementation so to me it is definitely a part of decision.

gazarenkov · 2026-06-19T10:44:30Z

+Additionally, RHDH is supported across multiple Kubernetes platforms (OCP, EKS, AKS, GKE), each with different levels of default NetworkPolicy enforcement. OCP enforces NetworkPolicies out of the box, but other platforms may require users to configure a compatible CNI plugin.
+
+### Disconnected/airgapped environments
+


I do not think we can hardcode specific destinations in non-airgap as well, CIDRs in cloud services tend to change.

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

Document the exact labels used by each install method to scope NetworkPolicies to a specific component of a specific instance: Operator uses rhdh.redhat.com/app, Helm uses app.kubernetes.io/instance combined with app.kubernetes.io/component. Co-authored-by: Gennady Azarenkov <gazarenkov@gmail.com> Assisted-by: Claude

OCP team confirmed operators are expected to ship standard NetworkPolicies, not ANP. ANP is for cluster admins to override or tighten operator-shipped policies as needed. Assisted-by: Claude

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

Move key paragraphs (multi-platform support, plugin-driven unpredictable egress, disconnected environments) from the problem statement into Key constraints, reordered by impact. Rename ADR title from "Install Methods" to "Application Workloads" to avoid confusion with the Operator itself. Summarize user-extensible policies section, add CNP to Alternative 5, clarify Lightspeed as default since 1.10, replace em dashes with semicolons, and use CR-specific/release-specific terminology for label-scoped policies. Assisted-by: Claude

Add three example policies to the Decision section illustrating the label-scoped approach for both Operator and Helm chart paths: default-deny (Helm), allow Router ingress (Operator, OCP-specific), and DNS-only egress for PostgreSQL (Operator, cross-platform). Assisted-by: Claude

Address threat model finding about insecure Prometheus metrics port by explicitly documenting port 9464 ingress restriction to the monitoring namespace and adding a corresponding NetworkPolicy example. Assisted-by: Claude

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

Add a note that the NetworkPolicy examples are illustrative and that both Operator and Helm chart will ship equivalent policies OOTB. Add a note about reviewing future NetworkPolicy changes against this ADR as part of the standard PR review process. Co-authored-by: Kim Tsao <ktsao@redhat.com> Assisted-by: Claude

zdrapela · 2026-07-13T14:49:24Z

/agentic_review

rhdh-qodo-merge · 2026-07-13T14:51:46Z

Code Review by Qodo

Sorry, something went wrong

We weren't able to complete the code review on our side. Please try again

zdrapela · 2026-07-13T14:52:05Z

/agentic_review

rhdh-qodo-merge · 2026-07-13T15:40:40Z

Code Review by Qodo

Context used

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

1. ~~ADR numbering CI will fail~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

This PR adds decisions/007-..., but the repo’s ADR CI check enforces using the lowest missing ADR
number; with ADR 005 present and no ADR 006 file, the next available number is 006 so the workflow
will fail and block merges.

Code

decisions/007-network-policies-for-rhdh-install-methods.md[1]
+# ADR: Tailored NetworkPolicies for RHDH Application Workloads

Evidence
The ADR Number Check workflow runs scripts/suggest-next-adr.sh --ci-suggest and fails the job if
the script detects a mismatch. The script explicitly selects the lowest missing ADR number (gap) and
errors if the changed ADR filename’s 3-digit prefix differs; with an existing ADR numbered 005 and
this PR introducing 007, the next missing number is 006, so 007-... will be rejected.
.github/workflows/adr-number-check.yaml[1-50]
scripts/suggest-next-adr.sh[3-76]
decisions/005-crd-version-management.md[1-2]
decisions/007-network-policies-for-rhdh-install-methods.md[1-2]

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 ADR numbering check workflow validates that the ADR filename prefix matches the next available ADR number (lowest missing gap). Adding `decisions/007-...` when `006` is the next available number causes CI to fail.

## Issue Context
- The workflow runs `scripts/suggest-next-adr.sh --ci-suggest ...` on PRs that touch `decisions/**`.
- The script computes the next ADR number as the lowest missing `NNN` in `decisions/*.md` and fails when the changed ADR filename’s `NNN` doesn’t match.

## Fix Focus Areas
- decisions/007-network-policies-for-rhdh-install-methods.md[1-204]

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

View more (4)

2. Misleading no-action claim 🐞 Bug ⛨ Security ⭐ New

Description

The ADR states that on non-OCP clusters enforcing NetworkPolicies there is “No user action
required”, but earlier it says non-OCP platforms may require users to configure a
NetworkPolicy-capable CNI (and later notes policies may be non-enforced). This can create a false
sense of security about enforcement on EKS/AKS/GKE deployments.

Code

decisions/006-network-policies-for-rhdh-install-methods.md[185]
+- ✅ Works transparently on OCP and non-OCP clusters that enforce NetworkPolicies. No user action required

Relevance

●●● Strong
Team often accepts wording fixes preventing misleading docs/inconsistent claims in ADRs.
PR-#2
PR-#4
PR-#5

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Line 185 claims no user action is required, while earlier the ADR explicitly states non-OCP
platforms may require CNI configuration to enforce NetworkPolicies and later reiterates that lack of
enforcement means no protection.
decisions/006-network-policies-for-rhdh-install-methods.md[17-17]
decisions/006-network-policies-for-rhdh-install-methods.md[185-185]
decisions/006-network-policies-for-rhdh-install-methods.md[193-193]
decisions/006-network-policies-for-rhdh-install-methods.md[199-199]

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 ADR’s “No user action required” claim for non-OCP deployments is inconsistent with the ADR’s own constraint that non-OCP users may need to configure a NetworkPolicy-capable CNI for enforcement.

## Issue Context
This is a documentation correctness/security-signaling issue: the policies can be created without errors, but they may not be enforced unless the cluster has a NetworkPolicy-capable CNI.

## Fix Focus Areas
- decisions/006-network-policies-for-rhdh-install-methods.md[185-185]

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

3. Ingress note incomplete 🐞 Bug ≡ Correctness ⭐ New

Description

The non-OCP note suggests using namespaceSelector: {} as a generic workaround, but that only
matches pod sources and is not a universal solution for ingress topologies (e.g., ingress
controllers using hostNetwork or other non-pod source representations). This can cause the
documented example to be copy/pasted yet still fail to allow ingress on port 7007 in some
environments.

Code

decisions/006-network-policies-for-rhdh-install-methods.md[95]

+  > **Note**: This example uses the OCP-specific label `policy-group.network.openshift.io/ingress: ""` to identify the ingress controller namespace. On non-OCP platforms (EKS, AKS, GKE), the `namespaceSelector` must be adapted to match the namespace where the platform's ingress controller runs, or use `namespaceSelector: {}` to allow ingress on port 7007 from any namespace.

Relevance

●● Moderate
No prior reviews on namespaceSelector/hostNetwork caveat; only general doc-clarity acceptances seen.
PR-#2

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The example acknowledges that hostNetwork traffic may need to be allowed, but the note’s suggested
fallback (namespaceSelector: {}) only selects pods-by-namespace and does not address non-pod
traffic sources.
decisions/006-network-policies-for-rhdh-install-methods.md[86-88]
decisions/006-network-policies-for-rhdh-install-methods.md[95-95]

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 ADR presents `namespaceSelector: {}` as a broadly applicable workaround for non-OCP ingress, but it does not cover all source types/topologies (notably cases where traffic is not attributable to a source pod).

## Issue Context
The example itself already hints this complexity by mentioning hostNetwork traffic. The note should either (a) qualify when `namespaceSelector: {}` is sufficient, or (b) provide alternative patterns (e.g., allow-all sources on the port by omitting `from`, or using an `ipBlock`/node CIDRs, depending on the platform).

## Fix Focus Areas
- decisions/006-network-policies-for-rhdh-install-methods.md[95-95]

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

4. ~~Router ingress label mismatch~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In the OpenShift router ingress example, the namespaceSelector.matchLabels key
(policy-group.network.openshift.io/ingress) conflicts with the following note claiming
network.openshift.io/policy-group: ingress, making the ADR internally inconsistent and likely to
be copy-pasted incorrectly.

Code

decisions/007-network-policies-for-rhdh-install-methods.md[R83-92]

+          # OCP-specific: matches the namespace where the OpenShift Router runs.
+          # May also allow all hostNetwork traffic.
+          - namespaceSelector:
+              matchLabels:
+                policy-group.network.openshift.io/ingress: ""
+        ports:
+          - port: 7007
+            protocol: TCP
+  ```
+  > **Note**: This example uses the OCP-specific label `network.openshift.io/policy-group: ingress` to identify the ingress controller namespace. On non-OCP platforms (EKS, AKS, GKE), the `namespaceSelector` must be adapted to match the namespace where the platform's ingress controller runs, or use `namespaceSelector: {}` to allow ingress on port 7007 from any namespace.

Evidence

The YAML example and the subsequent note in the same section name different label keys/values for
selecting the router namespace, so the document contradicts itself at the point where users will
copy the selector.

decisions/007-network-policies-for-rhdh-install-methods.md[83-92]

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 ADR’s OpenShift router ingress example and its explanatory note reference different namespace label selectors for identifying the ingress/router namespace.

## Issue Context
- The YAML example uses `policy-group.network.openshift.io/ingress: ""`.
- The note immediately after says the label is `network.openshift.io/policy-group: ingress`.

## Fix Focus Areas
- decisions/007-network-policies-for-rhdh-install-methods.md[83-92]

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

5. Unexplained tracker key switch 🐞 Bug ⚙ Maintainability ⭐ New

Description

The ADR references HPSTRAT-104 as a “parent outcome” while the surrounding threat-model references
use OCPSTRAT-* keys, with no explanation of the cross-project relationship. This reduces
traceability and makes it harder for readers to follow the decision provenance.

Code

decisions/006-network-policies-for-rhdh-install-methods.md[168]

+- **Approach**: Ship ANP/BANP (or their planned successor CNP) resources with labels selecting all possible RHDH workloads, created once when the Operator is installed. Since OLM cannot install NetworkPolicies OOTB (due to the backport issues mentioned in [RHDHPLAN-351](https://redhat.atlassian.net/browse/RHDHPLAN-351)), the ANP/BANP resources would be provided as an external manifest that users apply after installing the Operator. This was considered as seems to be implied by the parent outcome [HPSTRAT-104](https://redhat.atlassian.net/browse/HPSTRAT-104).

Relevance

●●● Strong
Team historically accepts traceability/link-clarification in ADRs (e.g., adding JIRA context/links).
PR-#4

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The ADR frames the threat model under OCPSTRAT (e.g., OCPSTRAT-819) but later cites HPSTRAT-104 as a
parent outcome without any bridging explanation.
decisions/006-network-policies-for-rhdh-install-methods.md[7-7]
decisions/006-network-policies-for-rhdh-install-methods.md[168-168]

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 ADR switches from OCPSTRAT-* references to HPSTRAT-104 without explaining whether this is intentional (cross-project parent) or a typo.

## Issue Context
This is a documentation traceability issue; clarify the relationship or adjust the reference if needed.

## Fix Focus Areas
- decisions/006-network-policies-for-rhdh-install-methods.md[168-168]

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

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 5087562

Results up to commit bbdf08a

1. ~~ADR numbering CI will fail~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

This PR adds decisions/007-..., but the repo’s ADR CI check enforces using the lowest missing ADR
number; with ADR 005 present and no ADR 006 file, the next available number is 006 so the workflow
will fail and block merges.

Code

decisions/007-network-policies-for-rhdh-install-methods.md[1]
+# ADR: Tailored NetworkPolicies for RHDH Application Workloads

Evidence
The ADR Number Check workflow runs scripts/suggest-next-adr.sh --ci-suggest and fails the job if
the script detects a mismatch. The script explicitly selects the lowest missing ADR number (gap) and
errors if the changed ADR filename’s 3-digit prefix differs; with an existing ADR numbered 005 and
this PR introducing 007, the next missing number is 006, so 007-... will be rejected.
.github/workflows/adr-number-check.yaml[1-50]
scripts/suggest-next-adr.sh[3-76]
decisions/005-crd-version-management.md[1-2]
decisions/007-network-policies-for-rhdh-install-methods.md[1-2]

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 ADR numbering check workflow validates that the ADR filename prefix matches the next available ADR number (lowest missing gap). Adding `decisions/007-...` when `006` is the next available number causes CI to fail.

## Issue Context
- The workflow runs `scripts/suggest-next-adr.sh --ci-suggest ...` on PRs that touch `decisions/**`.
- The script computes the next ADR number as the lowest missing `NNN` in `decisions/*.md` and fails when the changed ADR filename’s `NNN` doesn’t match.

## Fix Focus Areas
- decisions/007-network-policies-for-rhdh-install-methods.md[1-204]

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

View more (1)

2. ~~Router ingress label mismatch~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In the OpenShift router ingress example, the namespaceSelector.matchLabels key
(policy-group.network.openshift.io/ingress) conflicts with the following note claiming
network.openshift.io/policy-group: ingress, making the ADR internally inconsistent and likely to
be copy-pasted incorrectly.

Code

decisions/007-network-policies-for-rhdh-install-methods.md[R83-92]

+          # OCP-specific: matches the namespace where the OpenShift Router runs.
+          # May also allow all hostNetwork traffic.
+          - namespaceSelector:
+              matchLabels:
+                policy-group.network.openshift.io/ingress: ""
+        ports:
+          - port: 7007
+            protocol: TCP
+  ```
+  > **Note**: This example uses the OCP-specific label `network.openshift.io/policy-group: ingress` to identify the ingress controller namespace. On non-OCP platforms (EKS, AKS, GKE), the `namespaceSelector` must be adapted to match the namespace where the platform's ingress controller runs, or use `namespaceSelector: {}` to allow ingress on port 7007 from any namespace.

Evidence

The YAML example and the subsequent note in the same section name different label keys/values for
selecting the router namespace, so the document contradicts itself at the point where users will
copy the selector.

decisions/007-network-policies-for-rhdh-install-methods.md[83-92]

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 ADR’s OpenShift router ingress example and its explanatory note reference different namespace label selectors for identifying the ingress/router namespace.

## Issue Context
- The YAML example uses `policy-group.network.openshift.io/ingress: ""`.
- The note immediately after says the label is `network.openshift.io/policy-group: ingress`.

## Fix Focus Areas
- decisions/007-network-policies-for-rhdh-install-methods.md[83-92]

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

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

- Add OOTB constraint for default base NetworkPolicies - Replace "layered product" wording with clearer description of RHDH workloads coexisting with unrelated workloads - Fix Helm pod labels to use app.kubernetes.io/name (developer-hub, postgresql) instead of app.kubernetes.io/component - Fix router ingress label inconsistency in the note - Rewrite Alternative 5 with concrete approach and 3 numbered rejection reasons from team discussion - Update positive consequence to include non-OCP clusters Assisted-by: Claude

Assisted-by: Claude

rm3l · 2026-07-21T10:22:12Z

/agentic_review

rhdh-qodo-merge · 2026-07-21T10:25:51Z

Code review by qodo was updated up to the latest commit 636250e

Assisted-by: Claude

rm3l · 2026-08-03T15:51:08Z

Merging as discussed.

…to-the-install-methods-operands-and-helm-chart

ADR: Tailored NetworkPolicies for RHDH Install Methods

048ad85

Proposes adding default-deny NetworkPolicies scoped to RHDH-labeled pods for both Operator operands and Helm chart deployments, leveraging the additive nature of NetworkPolicies for user extensibility. Assisted-by: Claude

openshift-ci Bot added the do-not-merge/work-in-progress label Jun 1, 2026

rm3l and others added 6 commits June 1, 2026 10:51

Clarify boundary between base and user-managed policies

c1b7ff6

Base policies cover only core traffic flows common to all deployments. All deployment-specific egress is the user's responsibility via additive NetworkPolicy resources. Assisted-by: Claude

Replace em dashes with clear punctuation, fix broken link, add OCPSTR…

52429fe

…AT-819 reference Assisted-by: Claude

minor style update

2e426f7

Updated section headers and improved documentation clarity regarding NetworkPolicies for RHDH.

Rename Implementation approach to Key design principles

2b9e946

Assisted-by: Claude

update

9025e54

Updated sections on disconnected environments, advanced deployment scenarios, and key constraints to improve clarity and organization.

rm3l marked this pull request as ready for review June 1, 2026 09:18

openshift-ci Bot removed the do-not-merge/work-in-progress label Jun 1, 2026

rm3l changed the title ~~ADR: Tailored NetworkPolicies for RHDH Install Methods~~ ADR: Tailored NetworkPolicies for RHDH deployments Jun 1, 2026

openshift-ci Bot requested review from durandom and kadel June 1, 2026 09:53

openshift-ci Bot requested review from Fortune-Ndlovu, OpinionatedHeron, gazarenkov, subhashkhileri and zdrapela June 1, 2026 09:54

subhashkhileri reviewed Jun 1, 2026

View reviewed changes

Comment thread decisions/007-network-policies-for-rhdh-install-methods.md Outdated

subhashkhileri reviewed Jun 1, 2026

View reviewed changes

Comment thread decisions/007-network-policies-for-rhdh-install-methods.md Outdated

rm3l and others added 2 commits June 1, 2026 13:45

Clarify effect on existing deployments when upgrading

7c16b8d

Co-authored-by: Subhash Khileri <subhashkhileri2@gmail.com> Assisted-by: Claude

clarify the effect on sidecar containers like Lighstpeed

8b001d4

Co-authored-by: Subhash Khileri <subhashkhileri2@gmail.com> Assisted-by: Claude

rm3l requested a review from gazarenkov June 18, 2026 16:15

gazarenkov requested changes Jun 19, 2026

View reviewed changes

gazarenkov changed the title ~~ADR: Tailored NetworkPolicies for RHDH deployments [RHDHPLAN-1032]~~ ADR-007: Tailored NetworkPolicies for RHDH deployments [RHDHPLAN-1032] Jun 24, 2026

rm3l and others added 6 commits June 25, 2026 18:31

Merge remote-tracking branch 'upstream/main' into RHDHPLAN-1032--add-…

e8148e4

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

Update ANP/BANP alternative with OCP team clarification

174a857

OCP team confirmed operators are expected to ship standard NetworkPolicies, not ANP. ANP is for cluster admins to override or tighten operator-shipped policies as needed. Assisted-by: Claude

Merge remote-tracking branch 'upstream/main' into RHDHPLAN-1032--add-…

5546a2a

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

rm3l requested a review from gazarenkov July 2, 2026 16:57

rm3l and others added 3 commits July 3, 2026 13:47

Merge remote-tracking branch 'upstream/main' into RHDHPLAN-1032--add-…

f7620bc

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

rm3l force-pushed the RHDHPLAN-1032--add-tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart branch from e5cc8cc to bbdf08a Compare July 13, 2026 11:48

rhdh-qodo-merge Bot reviewed Jul 13, 2026

View reviewed changes

Comment thread decisions/006-network-policies-for-rhdh-install-methods.md

Comment thread decisions/007-network-policies-for-rhdh-install-methods.md Outdated

rm3l added 3 commits July 21, 2026 11:32

Merge remote-tracking branch 'upstream/main' into RHDHPLAN-1032--add-…

fcb3a0e

…tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart

Rename ADR 007 to 006 to match next available number

636250e

Assisted-by: Claude

rm3l changed the title ~~ADR-007: Tailored NetworkPolicies for RHDH deployments [RHDHPLAN-1032]~~ ADR-006: Tailored NetworkPolicies for RHDH deployments [RHDHPLAN-1032] Jul 21, 2026

Replace OOTB acronym with full term

e786a8a

Assisted-by: Claude

Merge branch 'main' into RHDHPLAN-1032--add-tailored-networkpolicies-…

5087562

…to-the-install-methods-operands-and-helm-chart

rm3l merged commit a3c4726 into redhat-developer:main Aug 3, 2026
1 check passed

rm3l deleted the RHDHPLAN-1032--add-tailored-networkpolicies-to-the-install-methods-operands-and-helm-chart branch August 3, 2026 15:52

		Additionally, RHDH is supported across multiple Kubernetes platforms (OCP, EKS, AKS, GKE), each with different levels of default NetworkPolicy enforcement. OCP enforces NetworkPolicies out of the box, but other platforms may require users to configure a compatible CNI plugin.

		### Disconnected/airgapped environments

Uh oh!

Conversation

rm3l commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related

Uh oh!

rm3l commented Jun 1, 2026

Uh oh!

openshift-ci Bot commented Jun 1, 2026

Uh oh!

rm3l commented Jun 1, 2026

Uh oh!

polasudo commented Jun 1, 2026

Uh oh!

Uh oh!

Uh oh!

rm3l commented Jun 1, 2026

Uh oh!

polasudo commented Jun 1, 2026

Uh oh!

rm3l commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gazarenkov left a comment

Choose a reason for hiding this comment

Uh oh!

gazarenkov Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gazarenkov Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

zdrapela commented Jul 13, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 13, 2026

Code Review by Qodo

Sorry, something went wrong

Uh oh!

zdrapela commented Jul 13, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

Uh oh!

Uh oh!

rm3l commented Jul 21, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 21, 2026

Uh oh!

rm3l commented Aug 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

rm3l commented Jun 1, 2026 •

edited

Loading

rm3l commented Jun 1, 2026 •

edited

Loading

rhdh-qodo-merge Bot commented Jul 13, 2026 •

edited

Loading