ESO-165: Enhancement Proposal for External Secrets Operator Network Policy #1834

siddhibhor-56 · 2025-08-19T18:42:01Z

This PR implements the proposal to secure the External Secrets Operator (ESO) by introducing NetworkPolicy resources for the operands. The objective is to minimize the attack surface and ensure all components adhere to the principle of least privilege.

The approach begins with a baseline “deny-all” NetworkPolicy for ingress and egress traffic. From this baseline, only the minimal and explicitly required network flows are allowed for ESO components to function correctly.

Key allowed flows include:
API Server Access: Egress to the Kubernetes API server is permitted so ESO can reconcile resources.
Metrics Scraping(if applicable): Ingress on the metrics endpoint is allowed to enable Prometheus monitoring.
Webhook Validation (if applicable): Ingress on the webhook port is allowed to support admission review requests from the API server.

knobunc · 2025-08-20T12:19:50Z

It feels rather dangerous for the operator to manage its own NP. If something ever goes wrong with the policy (for example, in an update) that prevented the operator from connecting, how would it recover?

I think it's safer just to have the operator manage its operands and leave the operator unprotected until the OLM manifests can take NPs.

openshift-ci-robot · 2025-09-12T13:49:10Z

@siddhibhor-56: This pull request references ESO-165 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

In response to this:

This PR implements the proposal to secure the External Secrets Operator (ESO) by introducing NetworkPolicy resources for the operands. The objective is to minimize the attack surface and ensure all components adhere to the principle of least privilege.

The approach begins with a baseline “deny-all” NetworkPolicy for ingress and egress traffic. From this baseline, only the minimal and explicitly required network flows are allowed for ESO components to function correctly.

Key allowed flows include:
API Server Access: Egress to the Kubernetes API server is permitted so ESO can reconcile resources.
Metrics Scraping: Ingress on the metrics endpoint is allowed to enable Prometheus monitoring.
Webhook Validation (if applicable): Ingress on the webhook port is allowed to support admission review requests from the API server.

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 openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2025-09-12T13:51:28Z

@siddhibhor-56: This pull request references ESO-165 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

In response to this:

This PR implements the proposal to secure the External Secrets Operator (ESO) by introducing NetworkPolicy resources for the operands. The objective is to minimize the attack surface and ensure all components adhere to the principle of least privilege.

The approach begins with a baseline “deny-all” NetworkPolicy for ingress and egress traffic. From this baseline, only the minimal and explicitly required network flows are allowed for ESO components to function correctly.

Key allowed flows include:
API Server Access: Egress to the Kubernetes API server is permitted so ESO can reconcile resources.
Metrics Scraping(if applicable): Ingress on the metrics endpoint is allowed to enable Prometheus monitoring.
Webhook Validation (if applicable): Ingress on the webhook port is allowed to support admission review requests from the API server.

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 openshift-eng/jira-lifecycle-plugin repository.

bharath-b-rh

LGTM
except for couple of suggestions.

cc: @TrilokGeer @mytreya-rh for further reviews.

bharath-b-rh · 2025-09-15T11:26:14Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+    apiVersion: networking.k8s.io/v1
+    kind: NetworkPolicy
+    metadata:
+      name: allow-api-server-egress-for webhook


Suggested change

name: allow-api-server-egress-for webhook

name: allow-api-server-egress-for-webhook

bharath-b-rh · 2025-09-15T11:29:36Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+    //
+    // +kubebuilder:validation:Optional
+    // +optional 
+        NetworkPolicy []v1.NetworkPolicy `json:"networkPolicy,omitempty"`


I think we should have an ID to map the policy to help with reconciliation.

Suggested change

NetworkPolicy []v1.NetworkPolicy `json:"networkPolicy,omitempty"`

NetworkPolicy *v1.NetworkPolicy `json:"networkPolicy,omitempty"`

NetworkPolicies []NetworkPolicy `json:"networkPolicies,omitempty"`

}

type NetworkPolicy struct {

// name to assign to the created NetworkPolicy object.

// +required

Name string `json:"name,omitempty"`

NetworkPolicy *v1.NetworkPolicy `json:"networkPolicy,omitempty"`

}

siddhibhor-56 · 2025-09-16T05:34:37Z

It feels rather dangerous for the operator to manage its own NP. If something ever goes wrong with the policy (for example, in an update) that prevented the operator from connecting, how would it recover?

I think it's safer just to have the operator manage its operands and leave the operator unprotected until the OLM manifests can take NPs.

Hi @knobunc , As of now the network policy of the operand will be managed by the operator whereas the operator network policy will be managed by OLM bundle.

mytreya-rh · 2025-09-16T05:47:47Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+       kind: NetworkPolicy
+       metadata:
+         name: allow-operator-traffic
+         namespace: external-secrets-operator


So we are fixing the namespace of the operator here, right?
i think the user as of now has the option to install in a different namespace right?
Are we going to update the documentation that operator namespace should be fixed, or is it already in the docs?
Or shall we specify that if the namespace is changed, the operator network policies will not take effect

thanks @bharath-b-rh and @siddhibhor-56 for pointing me to the kustomization
Actually, the namespaces, specifically for network policy, seemed to be patched here in OLM code, right?
/lgtm

Yes correct ,
The namespace is not fixed, its user-configurable

bharath-b-rh

/lgtm

except for few nitpicks.

bharath-b-rh · 2025-09-16T12:23:30Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+
+        * **Allow Egress to API Server:** Permit egress to the API server on port 6443/TCP so it can inject CA data into other resources. 
+        * **Allow Ingress from Core Controller:** Permit ingress from the `external-secrets` controller pod for communication with the Bitwarden server.
+        * Note: The Bitwarden server is an optional integration. It is only created if explicitly enabled by user configuration.*


Suggested change

* Note: The Bitwarden server is an optional integration. It is only created if explicitly enabled by user configuration.*

* Note: The Bitwarden server is an optional integration. It is only created if explicitly enabled by user configuration. User has to additionally create a allow NetworkPolicy to interact with the external `Bitwarden Secret Manager`.

bharath-b-rh · 2025-09-16T12:24:24Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+
+    * **For the `external-secrets-bitwarden-sever` pod (`app: external-secrets`):**
+
+        * **Allow Egress to API Server:** Permit egress to the API server on port 6443/TCP so it can inject CA data into other resources. 


Suggested change

* **Allow Egress to API Server:** Permit egress to the API server on port 6443/TCP so it can inject CA data into other resources.

* **Allow Egress to API Server:** Permit egress to the API server on port 6443/TCP so it can store the secrets fetched from external `Bitwarden Secrets Manager` into a Kubernetes Secret resource.

bharath-b-rh · 2025-09-16T12:25:24Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+           - protocol: TCP
+             port: 6443 # Required: Kubernetes API server
+         ingress:
+         # Optional: expose metrics (8443 and/or 8080)


Suggested change

# Optional: expose metrics (8443 and/or 8080)

# Optional: expose metrics (8443 or 8080 based on user configuration)

bharath-b-rh · 2025-09-16T12:26:11Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+              port: 6443
+    ```
+
+3. **Allow `external-secrets-webhook` Controller Traffic:** This policy allows the API Server Access for Outbound communication to Kubernetes API server (port 6443) for resource reconciliation and Webhook Admission Control Inbound traffic from API server to webhook (port 10250) for resource validation and mutation.


Suggested change

3. **Allow `external-secrets-webhook` Controller Traffic:** This policy allows the API Server Access for Outbound communication to Kubernetes API server (port 6443) for resource reconciliation and Webhook Admission Control Inbound traffic from API server to webhook (port 10250) for resource validation and mutation.

3. **Allow `external-secrets-webhook` Controller Traffic:** This policy allows the API Server Access for Outbound communication to Kubernetes API server (port 6443) for resource reconciliation and Webhook Admission Control Inbound traffic from API server to webhook (port 10250) for resource validation.

bharath-b-rh · 2025-09-16T12:27:05Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+              port: 10250
+    ```
+
+4. **Allow `external-secrets-cert-controller` Traffic:** This policy allows the cert-controller API Server Access for outbound communication to Kubernetes API server (port 6443/TCP) for certificate lifecycle management.


Suggested change

4. **Allow `external-secrets-cert-controller` Traffic:** This policy allows the cert-controller API Server Access for outbound communication to Kubernetes API server (port 6443/TCP) for certificate lifecycle management.

4. Allow `external-secrets-cert-controller` Traffic:** This policy allows the cert-controller API Server Access for outbound communication to Kubernetes API server (port 6443/TCP) for certificate lifecycle management.

bharath-b-rh · 2025-09-16T12:27:18Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+              port: 6443
+    ```
+
+5. **Allow `external-secrets-bitwarden-server` Traffic: This policy permits the Bitwarden server to communicate with the Kubernetes API server (port 6443/TCP) for secret synchronization and certificate validation, and to receive inbound traffic from the core controller for integration workflows.


Suggested change

5. **Allow `external-secrets-bitwarden-server` Traffic: This policy permits the Bitwarden server to communicate with the Kubernetes API server (port 6443/TCP) for secret synchronization and certificate validation, and to receive inbound traffic from the core controller for integration workflows.

5. **Allow `external-secrets-bitwarden-server` Traffic: This policy permits the Bitwarden server to communicate with the Kubernetes API server (port 6443/TCP) for secret synchronization, and to receive inbound traffic from the core controller for integration workflows.

bharath-b-rh · 2025-09-16T12:29:13Z

enhancements/external-secrets-operator/external-secrets-network-policy.md

+            - protocol: TCP
+              port: 6443
+    ```  
+6. **User-Configurable Policies:** Users must configure additional policies via the API for external-secrets controller egress (to communicate with external providers). Example user configuration:


Suggested change

6. **User-Configurable Policies:** Users must configure additional policies via the API for external-secrets controller egress (to communicate with external providers). Example user configuration:

6. **User-Configurable Policies:** Users must configure additional policies via the `ExternalSecrets` custom resource to set `external-secrets` controller egress allow policy to communicate with external providers. Example user configuration:

openshift-ci · 2025-09-16T12:36:55Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

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

TrilokGeer · 2025-09-25T07:48:25Z

It'd be great to validate against some practices implemented similarly openshift/cluster-olm-operator#118

bharath-b-rh · 2025-10-03T05:27:23Z

/lgtm

siddhibhor-56 · 2025-10-06T12:45:19Z

It'd be great to validate against some practices implemented similarly openshift/cluster-olm-operator#118

Ya, Thank you for pointing it out @TrilokGeer necessary changes had been added in the EP regarding the "from" clause in metrics.

mytreya-rh · 2025-10-06T13:20:10Z

/lgtm

openshift-ci · 2025-10-06T14:10:53Z

@siddhibhor-56: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

openshift-ci bot requested review from jeffdyoung and yuqi-zhang August 19, 2025 18:42

siddhibhor-56 changed the title ~~Enhancement Proposal for External Secrets Operator Network Policy~~ [WIP]:Enhancement Proposal for External Secrets Operator Network Policy Aug 21, 2025

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 21, 2025

siddhibhor-56 force-pushed the eso branch 3 times, most recently from 5f8ee63 to f906b59 Compare September 12, 2025 12:48

Enhancement Proposal for External Secrets Operator

22fe4f3

siddhibhor-56 force-pushed the eso branch from f906b59 to 22fe4f3 Compare September 12, 2025 13:38

siddhibhor-56 changed the title ~~[WIP]:Enhancement Proposal for External Secrets Operator Network Policy~~ ESO-165: Enhancement Proposal for External Secrets Operator Network Policy Sep 12, 2025

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 12, 2025

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 12, 2025

bharath-b-rh reviewed Sep 16, 2025

View reviewed changes

mytreya-rh reviewed Sep 16, 2025

View reviewed changes

openshift-ci bot assigned mytreya-rh Sep 16, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 16, 2025

Adds the component name

addd5e2

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Sep 16, 2025

bharath-b-rh approved these changes Sep 16, 2025

View reviewed changes

openshift-ci bot assigned bharath-b-rh Sep 16, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 16, 2025

review changes

13ca0c3

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Sep 16, 2025

review changes

8c19c2d

changes

3fed27e

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 3, 2025

adds the relevant user story

9190680

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Oct 6, 2025

changes

c1e39e5

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 6, 2025

	name: allow-api-server-egress-for webhook
	name: allow-api-server-egress-for-webhook

-        NetworkPolicy []v1.NetworkPolicy `json:"networkPolicy,omitempty"`
+    NetworkPolicy *v1.NetworkPolicy `json:"networkPolicy,omitempty"`
+        NetworkPolicies []NetworkPolicy `json:"networkPolicies,omitempty"`
+}
+type NetworkPolicy struct {
+      // name to assign to the created NetworkPolicy object.
+      // +required
+      Name string `json:"name,omitempty"`
+      NetworkPolicy *v1.NetworkPolicy `json:"networkPolicy,omitempty"`
+}

	* Note: The Bitwarden server is an optional integration. It is only created if explicitly enabled by user configuration.*
	* Note: The Bitwarden server is an optional integration. It is only created if explicitly enabled by user configuration. User has to additionally create a allow NetworkPolicy to interact with the external `Bitwarden Secret Manager`.


		* For the `external-secrets-bitwarden-sever` pod (`app: external-secrets`):

		* Allow Egress to API Server: Permit egress to the API server on port 6443/TCP so it can inject CA data into other resources.

	# Optional: expose metrics (8443 and/or 8080)
	# Optional: expose metrics (8443 or 8080 based on user configuration)

	3. Allow `external-secrets-webhook` Controller Traffic: This policy allows the API Server Access for Outbound communication to Kubernetes API server (port 6443) for resource reconciliation and Webhook Admission Control Inbound traffic from API server to webhook (port 10250) for resource validation and mutation.
	3. Allow `external-secrets-webhook` Controller Traffic: This policy allows the API Server Access for Outbound communication to Kubernetes API server (port 6443) for resource reconciliation and Webhook Admission Control Inbound traffic from API server to webhook (port 10250) for resource validation.

	4. Allow `external-secrets-cert-controller` Traffic: This policy allows the cert-controller API Server Access for outbound communication to Kubernetes API server (port 6443/TCP) for certificate lifecycle management.
	4. Allow `external-secrets-cert-controller` Traffic:** This policy allows the cert-controller API Server Access for outbound communication to Kubernetes API server (port 6443/TCP) for certificate lifecycle management.

	5. **Allow `external-secrets-bitwarden-server` Traffic: This policy permits the Bitwarden server to communicate with the Kubernetes API server (port 6443/TCP) for secret synchronization and certificate validation, and to receive inbound traffic from the core controller for integration workflows.
	5. **Allow `external-secrets-bitwarden-server` Traffic: This policy permits the Bitwarden server to communicate with the Kubernetes API server (port 6443/TCP) for secret synchronization, and to receive inbound traffic from the core controller for integration workflows.

	6. User-Configurable Policies: Users must configure additional policies via the API for external-secrets controller egress (to communicate with external providers). Example user configuration:
	6. User-Configurable Policies: Users must configure additional policies via the `ExternalSecrets` custom resource to set `external-secrets` controller egress allow policy to communicate with external providers. Example user configuration:

ESO-165: Enhancement Proposal for External Secrets Operator Network Policy #1834

Are you sure you want to change the base?

ESO-165: Enhancement Proposal for External Secrets Operator Network Policy #1834

Uh oh!

Conversation

siddhibhor-56 commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

knobunc commented Aug 20, 2025

Uh oh!

openshift-ci-robot commented Sep 12, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Sep 12, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bharath-b-rh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

siddhibhor-56 commented Sep 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mytreya-rh Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

siddhibhor-56 Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-b-rh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Sep 16, 2025

Uh oh!

TrilokGeer commented Sep 25, 2025

Uh oh!

bharath-b-rh commented Oct 3, 2025

Uh oh!

siddhibhor-56 commented Oct 6, 2025

Uh oh!

mytreya-rh commented Oct 6, 2025

Uh oh!

openshift-ci bot commented Oct 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

siddhibhor-56 commented Aug 19, 2025 •

edited

Loading

openshift-ci-robot commented Sep 12, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Sep 12, 2025 •

edited by openshift-ci bot

Loading

mytreya-rh Sep 16, 2025 •

edited

Loading

siddhibhor-56 Sep 16, 2025 •

edited

Loading