Add NetworkPolicy controller to restrict operator pod traffic by ompushkara · Pull Request #110 · securesign/model-validation-operator

ompushkara · 2026-08-10T09:01:30Z

Introduce a self-healing NetworkPolicy reconciler that enforces ingress (9443, 8081) and egress (DNS, HTTPS, K8s API) rules on the operator pod. The controller watches for drift and recreates or updates the policy automatically. Includes RBAC permissions, POD_NAMESPACE downward API injection, unit tests, and test utility updates for NetworkPolicy scheme.

qodo-for-securesign · 2026-08-10T09:02:42Z

PR Summary by Qodo

Add self-healing NetworkPolicy reconciler for operator pod traffic

✨ Enhancement ⚙️ Configuration changes 🧪 Tests 🕐 20-40 Minutes

AI Description

• Add a controller that continuously reconciles a restrictive NetworkPolicy for the operator pod.
• Inject operator namespace via Downward API and grant RBAC for NetworkPolicy management.
• Add unit coverage and test utilities for NetworkPolicy objects; compute OLM upgrade version in CI.

Diagram

graph TD
  E["config/manager/manager.yaml"] --> A["cmd/main.go"] --> B["NetworkPolicyReconciler"] --> D{{"K8s API"}} --> C[("NetworkPolicy")]
  F["config/rbac/role.yaml"] --> D --> C
  G["networkpolicy_controller_test.go"] --> H["testutil fake client"] --> B
  subgraph Legend
    direction LR
    _f["File/Module"] ~~~ _ext{{"K8s API"}} ~~~ _res[("K8s resource")]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Ship NetworkPolicy as a static manifest only (kustomize/OLM-owned)

➕ Simpler: no extra controller logic or RBAC beyond install-time apply
➕ Less runtime churn; avoids reconcile loops fighting user edits
➖ No self-healing: deletions/drift persist until manual intervention or reinstall
➖ Harder to guarantee enforcement if users/automation mutate the object

2. Enforce via cluster policy tooling (Gatekeeper/Kyverno)

➕ Centralized governance; can enforce across namespaces/operators consistently
➕ Can prevent drift by rejecting non-compliant changes
➖ Requires extra cluster components and admin ownership; not always available
➖ More operational complexity than an operator-scoped reconciler

Recommendation: The reconciler approach is appropriate if the goal is operator-scoped, self-healing enforcement even under drift/deletion. To reduce the chance of conflicting with intentional customization, consider documenting the policy as operator-managed (labels already help) and whether an opt-out/override mechanism is desired for advanced deployments.

Files changed (7) +470 / -1

Enhancement (2) +231 / -0

main.goRegister NetworkPolicy controller and detect operator namespace +29/-0

Register NetworkPolicy controller and detect operator namespace

• Adds logic to detect the operator namespace via POD_NAMESPACE (preferred) or the serviceaccount namespace file. Conditionally wires up the NetworkPolicyReconciler so local runs without a namespace skip this controller.

cmd/main.go

networkpolicy_controller.goAdd self-healing NetworkPolicy reconciler with ingress/egress allowlist +202/-0

Add self-healing NetworkPolicy reconciler with ingress/egress allowlist

• Introduces a controller-runtime reconciler that CreateOrUpdate's a fixed NetworkPolicy named controller-manager in the operator namespace. The policy restricts ingress to webhook (9443), health (8081), and metrics (8443) with peer scoping, and restricts egress to DNS and the Kubernetes API server.

internal/controller/networkpolicy_controller.go

Tests (2) +217 / -0

networkpolicy_controller_test.goAdd unit tests for NetworkPolicy reconciliation behavior +213/-0

Add unit tests for NetworkPolicy reconciliation behavior
• Adds Ginkgo/Gomega tests covering creation, updates from a wrong spec, idempotency, and recreation after external deletion. Validates key peer selectors, ports, policy types, and labels.
internal/controller/networkpolicy_controller_test.go

testutil.goRegister NetworkingV1 scheme in fake client test utilities +4/-0

Register NetworkingV1 scheme in fake client test utilities
• Extends the shared fake-client setup to include networking.k8s.io/v1 types. This enables controller tests to create/get/delete NetworkPolicy objects without custom scheme wiring per test.
internal/testutil/testutil.go

Other (3) +22 / -1

test-e2e.ymlCompute OLM upgrade version dynamically in e2e workflow +6/-1

Compute OLM upgrade version dynamically in e2e workflow

• Removes the hardcoded OLM_UPGRADE_VERSION and computes the next patch version from the Makefile VERSION. This reduces manual maintenance and keeps upgrade tests aligned with the repo versioning.

.github/workflows/test-e2e.yml

manager.yamlInject POD_NAMESPACE into manager pod +5/-0

Inject POD_NAMESPACE into manager pod

• Adds a Downward API env var mapping metadata.namespace to POD_NAMESPACE. This enables the manager to determine its namespace reliably at runtime.

config/manager/manager.yaml

role.yamlGrant RBAC permissions for NetworkPolicy reconciliation +11/-0

Grant RBAC permissions for NetworkPolicy reconciliation
• Adds networking.k8s.io NetworkPolicy permissions (get/list/watch/create/update/patch). This allows the controller to self-heal the policy in-cluster.
config/rbac/role.yaml

codecov-commenter · 2026-08-10T09:05:55Z

Codecov Report

❌ Patch coverage is 80.53097% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 36.34%. Comparing base (44aadb0) to head (3a72618).

Files with missing lines	Patch %	Lines
cmd/main.go	0.00%	18 Missing ⚠️
internal/controller/networkpolicy.go	97.84%	1 Missing and 1 partial ⚠️
internal/testutil/testutil.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #110      +/-   ##
==========================================
+ Coverage   33.68%   36.34%   +2.65%     
==========================================
  Files          19       20       +1     
  Lines        1879     1992     +113     
==========================================
+ Hits          633      724      +91     
- Misses       1202     1223      +21     
- Partials       44       45       +1

Flag	Coverage Δ
unit	`36.34% <80.53%> (+2.65%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

qodo-for-securesign · 2026-08-10T09:07:22Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Apiserver selector incorrect~~ ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New

Description

NetworkPolicy desiredSpec() models Kubernetes API server traffic as coming from/going to pods in the
"default" namespace via a NamespaceSelector, which does not reliably match apiserver endpoints and
can break webhook admission (9443) and/or operator->API connectivity (443/6443) when NetworkPolicy
enforcement is active. The unit test codifies the same assumption, so drift won’t be caught.

Code

internal/controller/networkpolicy_controller.go[R89-92]

+						NamespaceSelector: &metav1.LabelSelector{
+							MatchLabels: map[string]string{
+								"kubernetes.io/metadata.name": "default",
+							},

Relevance

●● Moderate
Substantive NetworkPolicy semantics change; likely needs cluster-specific confirmation, and no
similar accepted/rejected history found.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The reconciler restricts webhook ingress and API egress to NamespaceSelector
kubernetes.io/metadata.name: default, and the test asserts that exact selector; meanwhile the
webhook service targets port 9443 on the operator pods, so blocking apiserver->webhook would break
admission calls.
internal/controller/networkpolicy_controller.go[85-99]
internal/controller/networkpolicy_controller.go[155-170]
internal/controller/networkpolicy_controller_test.go[60-66]
internal/controller/networkpolicy_controller_test.go[91-95]
config/components/webhook/webhook-service.yaml[1-13]

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 NetworkPolicy peers for webhook ingress and Kubernetes API egress are scoped to `kubernetes.io/metadata.name: default`, which selects pods in the default namespace rather than the Kubernetes apiserver endpoints.

### Issue Context
This policy is intended to restrict operator traffic but must still allow:
- kube-apiserver -> webhook service (targetPort 9443)
- operator pod -> kube-apiserver (443/6443)

### Fix Focus Areas
- internal/controller/networkpolicy_controller.go[85-99]
- internal/controller/networkpolicy_controller.go[156-170]
- internal/controller/networkpolicy_controller_test.go[62-67]
- internal/controller/networkpolicy_controller_test.go[91-96]

### Suggested direction
Use a platform-appropriate way to allow apiserver connectivity (e.g., explicit `ipBlock` for the apiserver endpoint/CIDR, or support a configurable list of namespaces/selectors for common distributions, and update tests accordingly).

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

2. ~~Metrics ingress blocked~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NetworkPolicyReconciler.desiredSpec() allows ingress only on 9443 and 8081, so the
controller-manager metrics endpoint on 8443 will be denied once this policy applies to the operator
pods. This breaks metrics scraping/monitoring because the default manifests bind and expose metrics
on 8443.

Code

internal/controller/networkpolicy_controller.go[R83-88]

+		Ingress: []networkingv1.NetworkPolicyIngressRule{
+			{
+				Ports: []networkingv1.NetworkPolicyPort{
+					{Port: &port9443, Protocol: &protocolTCP},
+					{Port: &port8081, Protocol: &protocolTCP},
+				},

Relevance

●●● Strong
Clear functional break: NetworkPolicy would block metrics scraping on 8443; teams usually fix such
port mismatches.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The operator is configured to bind and expose metrics on port 8443, but the newly introduced
enforced NetworkPolicy only permits ingress to 9443 and 8081 for the same pods, so metrics requests
to 8443 will be dropped when NetworkPolicy enforcement is active.
internal/controller/networkpolicy_controller.go[63-105]
config/default/metrics_service.yaml[10-18]
config/default/manager_metrics_patch.yaml[1-4]

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 reconciled NetworkPolicy denies inbound traffic to the operator’s metrics endpoint because it does not permit TCP 8443, even though the deployment is configured to bind metrics on 8443 and a Service targets that port.

### Issue Context
- The manager is configured to expose metrics on `:8443` and a `controller-manager-metrics-service` targets `8443`.
- The new controller-enforced NetworkPolicy selects the controller-manager pods but only allows ingress on 9443 and 8081.

### Fix Focus Areas
- internal/controller/networkpolicy_controller.go[63-106]
- config/default/metrics_service.yaml[10-18]
- config/default/manager_metrics_patch.yaml[1-4]

### Suggested fix
Update `desiredSpec()` to also allow ingress to TCP 8443.
- If you want to keep metrics locked down, mirror the existing repo policy approach by adding a dedicated ingress rule for 8443 with a `from` `namespaceSelector` (e.g., `metrics: enabled`).
- Otherwise, at minimum, add `{Port: &port8443, Protocol: &protocolTCP}` so existing metrics traffic continues to work.

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

3. NetworkPolicy controller skipped 🐞 Bug ⛨ Security ⭐ New

Description

main() starts the manager even when it cannot determine the operator namespace, silently skipping
NetworkPolicy reconciliation; in any non-local deployment missing POD_NAMESPACE and the
serviceaccount namespace file, this fail-open behavior leaves the intended traffic restrictions
unenforced. This also means an existing policy will not be repaired/recreated under drift in that
scenario.

Code

cmd/main.go[R324-327]

+		setupLog.Info("operator namespace not found, skipping NetworkPolicy controller (set POD_NAMESPACE for local runs)")
+	} else {
+		npReconciler := &controller.NetworkPolicyReconciler{
+			Client:    mgr.GetClient(),

Relevance

●● Moderate
Behavior change (fail-open vs fail-fast) is security-relevant but could be kept for local/dev UX; no
precedent.
PR-#16
PR-#104

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new startup path explicitly skips controller setup when getOperatorNamespace() returns empty;
while the default manager manifest sets POD_NAMESPACE, the code path remains a fail-open if that env
var (and the namespace file) are absent.

cmd/main.go[322-335]
config/manager/manager.yaml[60-73]

Agent prompt

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

### Issue description
If the operator namespace cannot be determined, the NetworkPolicy controller is skipped but the operator continues running.

### Issue Context
The default manifest injects `POD_NAMESPACE`, but alternative deployments (or hardened pods that disable SA token mounts) can still hit this path and unintentionally disable NetworkPolicy enforcement.

### Fix Focus Areas
- cmd/main.go[322-335]

### Suggested direction
- Detect in-cluster execution (e.g., `KUBERNETES_SERVICE_HOST` set) and **exit with an error** if namespace is unavailable.
- Keep the current skip behavior only for explicit local/dev mode (e.g., a `--disable-networkpolicy-controller` flag), and log at Error/Warn level with remediation steps.

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

4. Brittle version parsing 🐞 Bug ☼ Reliability ⭐ New

Description

The workflow computes OLM_UPGRADE_VERSION via grep/cut/awk without validating that exactly one
semver-like VERSION was extracted, so Makefile formatting changes (or unexpected VERSION content)
can produce a malformed upgrade version and fail later steps with confusing errors. The awk
expression also assumes exactly three dot-separated numeric components and only increments the patch
segment.

Code

.github/workflows/test-e2e.yml[R68-70]

+          CURRENT=$(grep '^VERSION ?=' Makefile | cut -d= -f2 | tr -d ' ')
+          NEXT=$(echo "$CURRENT" | awk -F. '{print $1"."$2"."$3+1}')
+          echo "OLM_UPGRADE_VERSION=$NEXT" >> "$GITHUB_ENV"

Relevance

●● Moderate
Repo often rejects robustness hardening in CI/scripts unless clearly needed; no exact precedent for
VERSION parsing.
PR-#16
PR-#104

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow step derives CURRENT from the Makefile and immediately computes NEXT and exports it,
but the Makefile is a free-form text file and the script does not validate the extracted value prior
to exporting it as OLM_UPGRADE_VERSION.

.github/workflows/test-e2e.yml[66-71]
Makefile[1-7]

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 workflow parses `VERSION ?= ...` from the Makefile and computes the next version without checking for empty/multiple matches or non-`X.Y.Z` formats.

### Issue Context
If VERSION ever changes format (e.g., comments, prerelease metadata), the job may export an invalid `OLM_UPGRADE_VERSION` and later steps (bundle/catalog build) will fail.

### Fix Focus Areas
- .github/workflows/test-e2e.yml[66-71]

### Suggested direction
- Extract VERSION with a single-purpose awk/sed that returns exactly one value.
- Validate with a strict `^[0-9]+\.[0-9]+\.[0-9]+$` check before writing to `$GITHUB_ENV`.
- Fail fast with a clear error message if validation fails.
- Optionally add a Makefile target (e.g., `make print-version`) and use that instead of parsing.

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

5. ~~Local run now exits~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

main() now exits if it cannot determine the operator namespace via POD_NAMESPACE or the in-cluster
serviceaccount namespace file, which makes the documented make run workflow fail by default on a
developer machine. This termination happens before starting the manager, so local development
becomes blocked unless developers manually set POD_NAMESPACE.

Code

cmd/main.go[R323-326]

+	operatorNamespace := getOperatorNamespace()
+	if operatorNamespace == "" {
+		setupLog.Error(fmt.Errorf("operator namespace not found"), "set POD_NAMESPACE env var or run in-cluster")
+		os.Exit(1)

Relevance

●●● Strong
Blocks documented local make run; likely they’ll add dev-friendly fallback instead of exiting.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new startup path exits when namespace discovery fails, and make run executes `go run
./cmd/main.go` without setting POD_NAMESPACE, so local execution will terminate immediately unless
the developer sets the env var manually.

cmd/main.go[323-357]
Makefile[160-163]

Agent prompt

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

### Issue description
`cmd/main.go` hard-fails startup when it can’t resolve the operator namespace. This breaks `make run` locally because that target does not set `POD_NAMESPACE` and the in-cluster namespace file is absent.

### Issue Context
- In-cluster: `config/manager/manager.yaml` injects `POD_NAMESPACE`, so prod is fine.
- Local: `Makefile` `run` target does not set `POD_NAMESPACE`, causing immediate exit.

### Fix Focus Areas
- cmd/main.go[323-357]
- Makefile[160-163]

### Suggested fix
Choose one:
1) Add a flag like `--operator-namespace` (or reuse an existing namespace flag if present) and have `make run` set it.
2) If namespace cannot be determined, log a warning and **skip** setting up the NetworkPolicy controller (so local runs still work), rather than exiting.

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

View medium (1)

6. ~~Policy peers too broad~~ ✓ Resolved 🐞 Bug ⛨ Security

Description

The reconciled NetworkPolicy rules specify only ports and omit ingress from and egress to,
meaning peers are not scoped (e.g., any reachable source can connect to 9443/8081 and egress on
443/6443 is allowed to any destination). This undercuts the controller’s stated intent of
restricting traffic to only required endpoints.

Code

internal/controller/networkpolicy_controller.go[R83-86]

+		Ingress: []networkingv1.NetworkPolicyIngressRule{
+			{
+				Ports: []networkingv1.NetworkPolicyPort{
+					{Port: &port9443, Protocol: &protocolTCP},

Relevance

●● Moderate
Peer scoping is more opinionated/security-hardening; may be deferred unless requirements mandate
strict selectors.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The generated policy defines ingress/egress rules with Ports only and no peer selectors, while an
existing repo NetworkPolicy uses from+namespaceSelector to explicitly scope allowed
peers—highlighting that the controller policy currently doesn’t enforce peer restrictions.

internal/controller/networkpolicy_controller.go[83-104]
config/network-policy/allow-metrics-traffic.yaml[19-27]

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 enforced NetworkPolicy restricts by port only; it does not constrain which sources may hit the operator (ingress) or which destinations the operator may reach (egress). If the goal is to minimize peer scope, this needs explicit `from`/`to` selectors.

### Issue Context
The repo already demonstrates peer scoping via `namespaceSelector` in `config/network-policy/allow-metrics-traffic.yaml`, but the controller-generated policy currently does not use similar selectors.

### Fix Focus Areas
- internal/controller/networkpolicy_controller.go[72-105]
- config/network-policy/allow-metrics-traffic.yaml[19-27]

### Suggested fix
In `desiredSpec()`:
- Add `Ingress[].From` constraints (e.g., namespaceSelector/podSelector) appropriate for 9443 (webhook) and 8081 (health probes), if peer restriction is desired.
- Add `Egress[].To` constraints for DNS (e.g., kube-system DNS pods) and Kubernetes API as appropriate for your deployment model.
- Keep the existing port restrictions, but scope peers to match the threat model you’re aiming for.

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

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous review results

Review updated until commit 3a72618

Results up to commit 31ef8fa ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Metrics ingress blocked~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NetworkPolicyReconciler.desiredSpec() allows ingress only on 9443 and 8081, so the
controller-manager metrics endpoint on 8443 will be denied once this policy applies to the operator
pods. This breaks metrics scraping/monitoring because the default manifests bind and expose metrics
on 8443.

Code

internal/controller/networkpolicy_controller.go[R83-88]

+		Ingress: []networkingv1.NetworkPolicyIngressRule{
+			{
+				Ports: []networkingv1.NetworkPolicyPort{
+					{Port: &port9443, Protocol: &protocolTCP},
+					{Port: &port8081, Protocol: &protocolTCP},
+				},

Relevance

●●● Strong
Clear functional break: NetworkPolicy would block metrics scraping on 8443; teams usually fix such
port mismatches.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The operator is configured to bind and expose metrics on port 8443, but the newly introduced
enforced NetworkPolicy only permits ingress to 9443 and 8081 for the same pods, so metrics requests
to 8443 will be dropped when NetworkPolicy enforcement is active.
internal/controller/networkpolicy_controller.go[63-105]
config/default/metrics_service.yaml[10-18]
config/default/manager_metrics_patch.yaml[1-4]

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 reconciled NetworkPolicy denies inbound traffic to the operator’s metrics endpoint because it does not permit TCP 8443, even though the deployment is configured to bind metrics on 8443 and a Service targets that port.

### Issue Context
- The manager is configured to expose metrics on `:8443` and a `controller-manager-metrics-service` targets `8443`.
- The new controller-enforced NetworkPolicy selects the controller-manager pods but only allows ingress on 9443 and 8081.

### Fix Focus Areas
- internal/controller/networkpolicy_controller.go[63-106]
- config/default/metrics_service.yaml[10-18]
- config/default/manager_metrics_patch.yaml[1-4]

### Suggested fix
Update `desiredSpec()` to also allow ingress to TCP 8443.
- If you want to keep metrics locked down, mirror the existing repo policy approach by adding a dedicated ingress rule for 8443 with a `from` `namespaceSelector` (e.g., `metrics: enabled`).
- Otherwise, at minimum, add `{Port: &port8443, Protocol: &protocolTCP}` so existing metrics traffic continues to work.

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

2. ~~Local run now exits~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

main() now exits if it cannot determine the operator namespace via POD_NAMESPACE or the in-cluster
serviceaccount namespace file, which makes the documented make run workflow fail by default on a
developer machine. This termination happens before starting the manager, so local development
becomes blocked unless developers manually set POD_NAMESPACE.

Code

cmd/main.go[R323-326]

+	operatorNamespace := getOperatorNamespace()
+	if operatorNamespace == "" {
+		setupLog.Error(fmt.Errorf("operator namespace not found"), "set POD_NAMESPACE env var or run in-cluster")
+		os.Exit(1)

Relevance

●●● Strong
Blocks documented local make run; likely they’ll add dev-friendly fallback instead of exiting.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new startup path exits when namespace discovery fails, and make run executes `go run
./cmd/main.go` without setting POD_NAMESPACE, so local execution will terminate immediately unless
the developer sets the env var manually.

cmd/main.go[323-357]
Makefile[160-163]

Agent prompt

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

### Issue description
`cmd/main.go` hard-fails startup when it can’t resolve the operator namespace. This breaks `make run` locally because that target does not set `POD_NAMESPACE` and the in-cluster namespace file is absent.

### Issue Context
- In-cluster: `config/manager/manager.yaml` injects `POD_NAMESPACE`, so prod is fine.
- Local: `Makefile` `run` target does not set `POD_NAMESPACE`, causing immediate exit.

### Fix Focus Areas
- cmd/main.go[323-357]
- Makefile[160-163]

### Suggested fix
Choose one:
1) Add a flag like `--operator-namespace` (or reuse an existing namespace flag if present) and have `make run` set it.
2) If namespace cannot be determined, log a warning and **skip** setting up the NetworkPolicy controller (so local runs still work), rather than exiting.

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

3. ~~Policy peers too broad~~ ✓ Resolved 🐞 Bug ⛨ Security

Description

The reconciled NetworkPolicy rules specify only ports and omit ingress from and egress to,
meaning peers are not scoped (e.g., any reachable source can connect to 9443/8081 and egress on
443/6443 is allowed to any destination). This undercuts the controller’s stated intent of
restricting traffic to only required endpoints.

Code

internal/controller/networkpolicy_controller.go[R83-86]

+		Ingress: []networkingv1.NetworkPolicyIngressRule{
+			{
+				Ports: []networkingv1.NetworkPolicyPort{
+					{Port: &port9443, Protocol: &protocolTCP},

Relevance

●● Moderate
Peer scoping is more opinionated/security-hardening; may be deferred unless requirements mandate
strict selectors.
PR-#67

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The generated policy defines ingress/egress rules with Ports only and no peer selectors, while an
existing repo NetworkPolicy uses from+namespaceSelector to explicitly scope allowed
peers—highlighting that the controller policy currently doesn’t enforce peer restrictions.

internal/controller/networkpolicy_controller.go[83-104]
config/network-policy/allow-metrics-traffic.yaml[19-27]

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 enforced NetworkPolicy restricts by port only; it does not constrain which sources may hit the operator (ingress) or which destinations the operator may reach (egress). If the goal is to minimize peer scope, this needs explicit `from`/`to` selectors.

### Issue Context
The repo already demonstrates peer scoping via `namespaceSelector` in `config/network-policy/allow-metrics-traffic.yaml`, but the controller-generated policy currently does not use similar selectors.

### Fix Focus Areas
- internal/controller/networkpolicy_controller.go[72-105]
- config/network-policy/allow-metrics-traffic.yaml[19-27]

### Suggested fix
In `desiredSpec()`:
- Add `Ingress[].From` constraints (e.g., namespaceSelector/podSelector) appropriate for 9443 (webhook) and 8081 (health probes), if peer restriction is desired.
- Add `Egress[].To` constraints for DNS (e.g., kube-system DNS pods) and Kubernetes API as appropriate for your deployment model.
- Keep the existing port restrictions, but scope peers to match the threat model you’re aiming for.

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

Signed-off-by: ompushkara <omotilal@redhat.com> Add OLM upgrade version logic instead of manually hardcoding

Signed-off-by: ompushkara <omotilal@redhat.com>

ompushkara · 2026-08-10T10:16:58Z

NetworkPolicy Controller

Adds a self-healing NetworkPolicyReconciler that enforces a static NetworkPolicy on the operator pod, limiting network access to the minimum required endpoints. The controller recreates or corrects the policy if it is deleted or tampered with.

Ingress (allowed inbound traffic)

Port	Protocol	Source	Purpose
9443	TCP	`default` namespace (API server)	Webhook calls
8081	TCP	Same namespace pods	Health/readiness probes
8443	TCP	Same namespace pods + namespaces labeled `metrics: enabled`	Metrics scraping

All other inbound traffic is denied.

Egress (allowed outbound traffic)

Port	Protocol	Destination	Purpose
53	TCP/UDP	`kube-system` + `openshift-dns` namespaces	DNS resolution
443	TCP	`default` namespace (kubernetes service)	Kubernetes API (HTTPS)
6443	TCP	`default` namespace (kubernetes service)	Kubernetes API

All other outbound traffic is denied.

Additional changes

Graceful local dev: skips the NetworkPolicy controller with a warning when POD_NAMESPACE is unset, so make run works without the in-cluster namespace file
OLM upgrade version: computed automatically from Makefile VERSION + patch bump to avoid duplicate bundle collisions in the FBC catalog
RBAC: added networkpolicies permissions (get, list, watch, create, update, patch)

qodo-for-securesign · 2026-08-10T11:48:42Z

Code review by qodo was updated up to the latest commit 8c4b9ef

Signed-off-by: ompushkara <omotilal@redhat.com>

ompushkara · 2026-08-12T11:33:08Z

NetworkPolicy Summary

The operator dynamically creates a controller-manager NetworkPolicy in its namespace to restrict traffic to/from the operator pod.

Ingress (incoming traffic to operator pod)

Port	Protocol	From	Allowed	Purpose
9443	TCP	Anywhere (no selector)	✅	Webhook — API server uses host network, can't be matched by selector
8443	TCP	Same-namespace pods	✅	Metrics scraping
8443	TCP	Namespaces labeled `metrics=enabled`	✅	Metrics scraping (e.g. Prometheus)
8443	TCP	Other namespaces without label	❌	Blocked
8081	TCP	Same-namespace pods	✅	Health/readiness probes
8081	TCP	Other namespaces	❌	Blocked
Any other	Any	Anywhere	❌	Blocked

Egress (outgoing traffic from operator pod)

Port	Protocol	To	Allowed	Purpose
53	TCP/UDP	`kube-system` namespace	✅	DNS resolution (vanilla K8s)
53	TCP/UDP	`openshift-dns` namespace	✅	DNS resolution (OpenShift)
443	TCP	Anywhere (no selector)	✅	API server — uses host network, can't be matched
6443	TCP	Anywhere (no selector)	✅	API server (OpenShift default port)
Any other	Any	Anywhere	❌	Blocked

Self-healing

The controller watches the NetworkPolicy resource and automatically recreates it if deleted or modified.

miyunari

thanks @ompushkara, almost looking good to me. Only one thing we may should re-think. If the operator comes up and sets up a network policy for itself, I think we dont need an extra networkpolicy reconciler?

Lets run a simple routine at startup to install the NP. wdyt?

Instead of a dedicated controller that watches and reconciles the NetworkPolicy, install it once at operator startup using a direct client call. This simplifies the codebase while achieving the same result — the operator's NetworkPolicy is created or updated before the manager starts. Signed-off-by: ompushkara <omotilal@redhat.com>

ompushkara · 2026-08-14T10:53:40Z

@miyunari , Yeah good one 💯 Replaced the reconciler with a simple startup routine that installs the NetworkPolicy when the operator comes up and tested in 4.21

qodo-for-securesign Bot reviewed Aug 10, 2026

View reviewed changes

Comment thread internal/controller/networkpolicy.go

ompushkara marked this pull request as draft August 10, 2026 09:08

Add peer selectors and metrics port to NetworkPolicy

a75aa92

Signed-off-by: ompushkara <omotilal@redhat.com> Add OLM upgrade version logic instead of manually hardcoding

ompushkara force-pushed the add/network-policies branch from 4058d9a to a75aa92 Compare August 10, 2026 09:49

Allow same-namespace pods to reach metrics port in NetworkPolicy

8c4b9ef

Signed-off-by: ompushkara <omotilal@redhat.com>

ompushkara marked this pull request as ready for review August 10, 2026 11:41

qodo-for-securesign Bot reviewed Aug 10, 2026

View reviewed changes

Comment thread internal/controller/networkpolicy_controller.go Outdated

Drop namespace selectors for apiserver NetworkPolicy rules

d92a973

Signed-off-by: ompushkara <omotilal@redhat.com>

ompushkara requested a review from miyunari August 12, 2026 11:42

miyunari reviewed Aug 13, 2026

View reviewed changes

Navigation Menu

Uh oh!

Add NetworkPolicy controller to restrict operator pod traffic - #110

Add NetworkPolicy controller to restrict operator pod traffic#110
ompushkara wants to merge 5 commits into
mainfrom
add/network-policies

ompushkara commented Aug 10, 2026

Uh oh!

qodo-for-securesign Bot commented Aug 10, 2026 •

edited

Loading

Uh oh!

codecov-commenter commented Aug 10, 2026 •

edited

Loading

Uh oh!

qodo-for-securesign Bot commented Aug 10, 2026 •

edited

Loading

Uh oh!

Uh oh!

ompushkara commented Aug 10, 2026

Uh oh!

Uh oh!

qodo-for-securesign Bot commented Aug 10, 2026

Uh oh!

ompushkara commented Aug 12, 2026

Uh oh!

miyunari left a comment

Uh oh!

ompushkara commented Aug 14, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ompushkara commented Aug 10, 2026

Uh oh!

qodo-for-securesign Bot commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary by Qodo

Uh oh!

codecov-commenter commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

qodo-for-securesign Bot commented Aug 10, 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!

ompushkara commented Aug 10, 2026

NetworkPolicy Controller

Ingress (allowed inbound traffic)

Egress (allowed outbound traffic)

Additional changes

Uh oh!

Uh oh!

qodo-for-securesign Bot commented Aug 10, 2026

Uh oh!

ompushkara commented Aug 12, 2026

NetworkPolicy Summary

Ingress (incoming traffic to operator pod)

Egress (outgoing traffic from operator pod)

Self-healing

Uh oh!

miyunari left a comment

Choose a reason for hiding this comment

Uh oh!

ompushkara commented Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

qodo-for-securesign Bot commented Aug 10, 2026 •

edited

Loading

codecov-commenter commented Aug 10, 2026 •

edited

Loading

qodo-for-securesign Bot commented Aug 10, 2026 •

edited

Loading

ompushkara commented Aug 14, 2026 •

edited

Loading