-
Notifications
You must be signed in to change notification settings - Fork 63
📖 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
base: main
Are you sure you want to change the base?
📖 Add NetworkPolicy doc #1973
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
### 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about linking the code from the repo? |
||
|
||
## 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we be more specific here? |
||
* Inspect logs: Check component logs for connection errors | ||
* Test connectivity: Run test pods that attempt to communicate with OLMv1 components | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
There was a problem hiding this comment.
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.