deploy/chart: add static NetworkPolicies for CatalogSource gRPC ingress and bundle unpack egress by grokspawn · Pull Request #3863 · operator-framework/operator-lifecycle-manager

grokspawn · 2026-07-09T19:15:40Z

Summary

The Helm chart's default-deny-all-traffic NetworkPolicy blocked two traffic paths not covered by the existing static policies:

CatalogSource gRPC ingress (port 50051): Registry pods spawned per CatalogSource could not receive inbound gRPC connections. The catalog-operator reconciler does create per-CatalogSource NetworkPolicies for this dynamically, but there is a bootstrapping gap — default-deny-all-traffic takes effect immediately on install/upgrade, while the per-CatalogSource policies only exist after the controller reconciles each object.
Bundle-unpack job egress: Job pods created for bundle unpacking could not reach the Kubernetes API server or container registries. The API server port cannot be statically specified (it is implementation-defined), so a wildcard egress rule is used instead.

Two new NetworkPolicies are added to the chart:

Policy	Selector	Effect
`catalog-source-grpc-server`	pods with `olm.catalogSource` label (any value)	allow ingress on `catalogGrpcPodPort` (50051)
`bundle-unpack-egress`	pods with `olm.managed=true` + `operatorframework.io/bundle-unpack-ref` label	allow all egress

The catalog-source-grpc-server policy only lists Ingress in policyTypes, so it does not restrict egress of catalog pods (that remains under the per-CatalogSource policies from the controller). The bundle-unpack-egress policy only lists Egress, so it does not affect ingress on those pods.

Test plan

Deploy OLM via the Helm chart into a cluster with a default-deny NetworkPolicy enforcement (e.g., K3s / Rancher Desktop)
Create a CatalogSource pointing to quay.io/operatorhubio/catalog:latest; verify lastObservedState reaches READY
Create a Subscription; verify the InstallPlan completes without BundleLookupFailed
Verify catalog-source-grpc-server and bundle-unpack-egress NetworkPolicies are present in the OLM namespace after helm install

🤖 Generated with Claude Code

…ss and bundle unpack egress The Helm chart's default-deny-all-traffic policy blocked two critical traffic paths that are not covered by the existing static NetworkPolicies: 1. CatalogSource registry pods need to accept inbound gRPC connections on port 50051 from within the cluster. The catalog-operator reconciler already creates per-CatalogSource NetworkPolicies for this, but there is a bootstrapping gap between when default-deny-all-traffic is applied and when the controller first reconciles each CatalogSource. 2. Bundle-unpack Job pods need egress to reach the Kubernetes API server and container registries. The API server port is not statically specifiable because it varies across Kubernetes implementations, so a wildcard egress rule is used. Adds two new NetworkPolicies to the chart: - catalog-source-grpc-server: selects all pods carrying the olm.catalogSource label and allows ingress on the gRPC port. - bundle-unpack-egress: selects all pods carrying both the olm.managed=true and operatorframework.io/bundle-unpack-ref labels and allows unrestricted egress. Fixes: operator-framework#3676 Signed-off-by: grokspawn <jordan@nimblewidget.com>

openshift-ci · 2026-07-09T19:15:47Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign tmshort for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copilot

Pull request overview

This PR updates the OLM Helm chart’s static NetworkPolicy set to avoid connectivity failures caused by the chart’s default-deny-all-traffic policy during the bootstrapping window (before the catalog controller has reconciled per-CatalogSource policies). It specifically targets allowing gRPC ingress to CatalogSource registry pods and enabling bundle-unpack job egress.

Changes:

Add catalog-source-grpc-server NetworkPolicy to allow ingress to pods labeled olm.catalogSource on the configured gRPC port.
Add bundle-unpack-egress NetworkPolicy to allow wildcard egress from bundle-unpack job pods (selected by olm.managed=true and operatorframework.io/bundle-unpack-ref).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…ck NPs CatalogSource registry pods and bundle-unpack Jobs run in the namespace determined by .Values.catalog_namespace, not .Values.namespace. When a user overrides catalog_namespace to differ from namespace, the NetworkPolicies must be created in catalog_namespace to actually apply to those pods. Fixes review feedback on operator-framework#3863. Signed-off-by: grokspawn <jordan@nimblewidget.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

perdasilva

Code review — 3 findings on the new NetworkPolicy templates.

perdasilva · 2026-07-10T08:39:37Z

+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: catalog-source-grpc-server


NP name collision risk

The dynamic NP uses fmt.Sprintf("%s-grpc-server", catalogSource.GetName()) (see pkg/controller/registry/reconciler/helpers.go:24). A CatalogSource named catalog-source in catalog_namespace would produce a dynamic NP named catalog-source-grpc-server — identical to this static Helm NP.

Since they have different specs (matchExpressions vs matchLabels, different labels/ownerReferences), the controller will overwrite the static NP on reconciliation and Helm will fight back on upgrade, causing reconciliation churn.

Consider prefixing the static NP name, e.g. olm-static-catalog-source-grpc-server or similar, to avoid any possible collision with the <name>-grpc-server naming pattern.

The only way to truly de-fang this challenge is to use a unique construction, which would make an accidental overlap less likely but do nothing to prevent a bad actor from seeing the public construction details and manufacturing a conflict.

So how likely do we feel this would be? Do we think that we could dump the resources on the cluster and see that there's a catalogsource called 'catalog-source' and determine the network policies are impacting?

I don't want to underplay this, but I'd like to understand the goal here. Just using a more complex or static name does not avoid the issue.

perdasilva · 2026-07-10T08:39:37Z

+kind: NetworkPolicy
+metadata:
+  name: catalog-source-grpc-server
+  namespace: {{ .Values.catalog_namespace }}


NPs become no-ops when catalog_namespace != namespace

The default-deny-all-traffic NP (line 5) is created only in {{ .Values.namespace }}. These new NPs target {{ .Values.catalog_namespace }}. When these values differ, Kubernetes allows all traffic by default in catalog_namespace — the allow-style NPs grant nothing because there is no deny-all baseline to punch through.

The bootstrap gap these NPs are meant to close remains open in split-namespace configurations.

Options:

Add a default-deny-all-traffic NP in catalog_namespace when it differs from namespace

Or document this as a known limitation

perdasilva · 2026-07-10T08:39:37Z

  egress:
    - { }
+---
+# Complements per-CatalogSource NPs from the controller; covers the bootstrapping window before reconciliation.


Static broad-selector NPs persist permanently and cannot be narrowed by the controller

This NP allows TCP ingress on catalogGrpcPodPort from any source (no from restriction) for all pods with the olm.catalogSource label (Exists match). Since Kubernetes NetworkPolicies are additive (union semantics), if the controller later tightens its per-CatalogSource NPs to restrict ingress to specific source pods (e.g., only from catalog-operator), this static NP silently defeats that restriction — and the controller has no code path to delete or update Helm-managed resources.

This is acceptable if the ingress source is intentionally unrestricted long-term. Worth noting as a design constraint.

Copilot AI review requested due to automatic review settings July 9, 2026 19:15

openshift-ci Bot requested review from ankitathomas and fgiudici July 9, 2026 19:15

Copilot started reviewing on behalf of grokspawn July 9, 2026 19:16 View session

Copilot AI reviewed Jul 9, 2026

View reviewed changes

Comment thread deploy/chart/templates/0000_50_olm_01-networkpolicies.yaml

Comment thread deploy/chart/templates/0000_50_olm_01-networkpolicies.yaml

Copilot AI review requested due to automatic review settings July 9, 2026 19:44

Copilot started reviewing on behalf of grokspawn July 9, 2026 19:45 View session

Copilot AI reviewed Jul 9, 2026

View reviewed changes

perdasilva reviewed Jul 10, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

deploy/chart: add static NetworkPolicies for CatalogSource gRPC ingress and bundle unpack egress#3863

deploy/chart: add static NetworkPolicies for CatalogSource gRPC ingress and bundle unpack egress#3863
grokspawn wants to merge 2 commits into
operator-framework:masterfrom
grokspawn:fix/networkpolicy-gaps-3676

grokspawn commented Jul 9, 2026

Uh oh!

openshift-ci Bot commented Jul 9, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

perdasilva left a comment

Uh oh!

perdasilva Jul 10, 2026

Uh oh!

grokspawn Jul 10, 2026

Uh oh!

perdasilva Jul 10, 2026

Uh oh!

perdasilva Jul 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

grokspawn commented Jul 9, 2026

Summary

Test plan

Uh oh!

openshift-ci Bot commented Jul 9, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

perdasilva left a comment

Choose a reason for hiding this comment

Uh oh!

perdasilva Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

grokspawn Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

perdasilva Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

perdasilva Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants