Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
grokspawn wants to merge 2 commits into
base: master
Choose a base branch
from
+38 −0
Open

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

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8942986
deploy/chart: add static NetworkPolicies for CatalogSource gRPC ingre…
grokspawn Jul 9, 2026
b4fea33
deploy/chart: use catalog_namespace for CatalogSource and bundle-unpa…
grokspawn Jul 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions deploy/chart/templates/0000_50_olm_01-networkpolicies.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,3 +85,41 @@ spec:
- { }
egress:
- { }
---
# Complements per-CatalogSource NPs from the controller; covers the bootstrapping window before reconciliation.

@perdasilva perdasilva Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

@perdasilva perdasilva Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@grokspawn grokspawn Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

namespace: {{ .Values.catalog_namespace }}

@perdasilva perdasilva Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

spec:
podSelector:
matchExpressions:
- key: olm.catalogSource
operator: Exists
policyTypes:
- Ingress
ingress:
- ports:
- protocol: TCP
port: {{ .Values.catalogGrpcPodPort }}
---
# Wildcard egress; API server port omitted intentionally — it is implementation-defined and not statically knowable.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: bundle-unpack-egress
namespace: {{ .Values.catalog_namespace }}
spec:
podSelector:
matchExpressions:
- key: operatorframework.io/bundle-unpack-ref
operator: Exists
- key: olm.managed
operator: In
values:
- "true"
policyTypes:
- Egress
egress:
- { }