Skip to content

📖 Add NetworkPolicy doc #1973

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.

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
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
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
89 changes: 89 additions & 0 deletions docs/draft/api-reference/network-policies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
# NetworkPolicy in OLMv1

## Overview

OLMv1 uses [Kubernetes NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) to secure communication between components, restricting network traffic to only what's necessary for proper functionality. This document explains how `NetworkPolicy` is implemented for the core components: `catalogd` and `operator-controller`.


## NetworkPolicy Implementation

NetworkPolicy is implemented for both catalogd and operator-controller components to:

* Restrict incoming (ingress) traffic to only required ports and services
* Control outgoing (egress) traffic patterns

Each component has a dedicated NetworkPolicy that applies to its respective pod through label selectors:

* For catalogd: `control-plane=catalogd-controller-manager`
* For operator-controller: `control-plane=operator-controller-controller-manager`

### Catalogd NetworkPolicy

- Ingress Rules
Catalogd exposes three services, and its NetworkPolicy allows ingress traffic to the following TCP ports:

* 7443: Metrics server for Prometheus metrics
* 8443: Catalogd HTTPS server for catalog metadata API
* 9443: Webhook server for Mutating Admission Webhook implementation

All other ingress traffic to the catalogd pod is blocked.

- Egress Rules
Catalogd needs to communicate with:

* The Kubernetes API server
* Image registries specified in ClusterCatalog objects

Currently, all egress traffic from catalogd is allowed, to support communication with arbitrary image registries that aren't known at install time.
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about linking the code from the repo?
So, those looking can easily check the NPs by clicking on them.


### Operator-Controller NetworkPolicy

- Ingress Rules
Operator-controller exposes one service, and its NetworkPolicy allows ingress traffic to:

* 8443: Metrics server for Prometheus metrics

All other ingress traffic to the operator-controller pod is blocked.

- Egress Rules
Operator-controller needs to communicate with:

* The Kubernetes API server
* Catalogd's HTTPS server (on port 8443)
* Image registries specified in bundle metadata

Currently, all egress traffic from operator-controller is allowed to support communication with arbitrary image registries that aren't known at install time.
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about linking the code from the repo?
So, those looking can easily check the NPs by clicking on them.


## Security Considerations

The current implementation focuses on securing ingress traffic while allowing all egress traffic. This approach:

* Prevents unauthorized incoming connections
* Allows communication with arbitrary image registries
* Establishes a foundation for future refinements to egress rules

While allowing all egress does present some security risks, this implementation provides significant security improvements over having no network policies at all.

## Troubleshooting Network Issues

If you encounter network connectivity issues after deploying OLMv1, consider the following:

* Verify NetworkPolicy support: Ensure your cluster has a CNI plugin that supports NetworkPolicy
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: If the CNI does not support NP, does this not mean that the NPs applied have no effect at all? So, I mean, if my k8s is using a CNI that does not provide this support is like it does not make any difference and no network connectivity issues could be faced. Am I right?

* Check pod labels: Confirm that catalogd and operator-controller pods have the correct labels for NetworkPolicy selection
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we be more specific here?
For example, could we give the kubectl commands to help the user ensure that the labels used to do the match are present?

* Inspect logs: Check component logs for connection errors
* Test connectivity: Run test pods that attempt to communicate with OLMv1 components
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add an example here with the commands to help the user and us to know how to do those checks?


For more comprehensive information on NetworkPolicy, see:

- How NetworkPolicy is implemented with [network plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) via the Container Network Interface (CNI)
- Installing [Network Policy Providers](https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/) documentation.

## Future Enhancements

The operator-framework team plan to revisit improvements to network policies in the future, such as:

* More restrictive egress rules based on configured catalog image references
* Further securing metrics and webhook server access
* Dynamic network policy updates based on configured bundle image references
Comment on lines +81 to +87
Copy link
Contributor

@camilamacedo86 camilamacedo86 May 17, 2025

Choose a reason for hiding this comment

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

I think we do not need to add the FE part, when we enhance/if we enhance, then we update this doc with the changes applied


These initial NetworkPolicy implementations represent OLMv1's commitment to being secure by default while maintaining necessary functionality.