|
| 1 | +# NetworkPolicy in OLMv1 |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +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. |
| 6 | + |
| 7 | +* The catalogd NetworkPolicy is implemented [here](https://github.com/operator-framework/operator-controller/blob/main/config/base/catalogd/manager/network_policy.yaml). |
| 8 | +* The operator-controller is implemented [here](https://github.com/operator-framework/operator-controller/blob/main/config/base/operator-controller/manager/network_policy.yaml). |
| 9 | + |
| 10 | +This document explains the details of `NetworkPolicy` implementation for the core components. |
| 11 | + |
| 12 | + |
| 13 | +## Implementation Overview |
| 14 | + |
| 15 | +NetworkPolicy is implemented for both catalogd and operator-controller components to: |
| 16 | + |
| 17 | +* Restrict incoming (ingress) traffic to only required ports and services |
| 18 | +* Control outgoing (egress) traffic patterns |
| 19 | + |
| 20 | +Each component has a dedicated NetworkPolicy that applies to its respective pod through label selectors: |
| 21 | + |
| 22 | +* For catalogd: `control-plane=catalogd-controller-manager` |
| 23 | +* For operator-controller: `control-plane=operator-controller-controller-manager` |
| 24 | + |
| 25 | +### Catalogd NetworkPolicy |
| 26 | + |
| 27 | +- Ingress Rules |
| 28 | +Catalogd exposes three services, and its NetworkPolicy allows ingress traffic to the following TCP ports: |
| 29 | + |
| 30 | +* 7443: Metrics server for Prometheus metrics |
| 31 | +* 8443: Catalogd HTTPS server for catalog metadata API |
| 32 | +* 9443: Webhook server for Mutating Admission Webhook implementation |
| 33 | + |
| 34 | +All other ingress traffic to the catalogd pod is blocked. |
| 35 | + |
| 36 | +- Egress Rules |
| 37 | +Catalogd needs to communicate with: |
| 38 | + |
| 39 | +* The Kubernetes API server |
| 40 | +* Image registries specified in ClusterCatalog objects |
| 41 | + |
| 42 | +Currently, all egress traffic from catalogd is allowed, to support communication with arbitrary image registries that aren't known at install time. |
| 43 | + |
| 44 | +### Operator-Controller NetworkPolicy |
| 45 | + |
| 46 | +- Ingress Rules |
| 47 | +Operator-controller exposes one service, and its NetworkPolicy allows ingress traffic to: |
| 48 | + |
| 49 | +* 8443: Metrics server for Prometheus metrics |
| 50 | + |
| 51 | +All other ingress traffic to the operator-controller pod is blocked. |
| 52 | + |
| 53 | +- Egress Rules |
| 54 | +Operator-controller needs to communicate with: |
| 55 | + |
| 56 | +* The Kubernetes API server |
| 57 | +* Catalogd's HTTPS server (on port 8443) |
| 58 | +* Image registries specified in bundle metadata |
| 59 | + |
| 60 | +Currently, all egress traffic from operator-controller is allowed to support communication with arbitrary image registries that aren't known at install time. |
| 61 | + |
| 62 | +## Security Considerations |
| 63 | + |
| 64 | +The current implementation focuses on securing ingress traffic while allowing all egress traffic. This approach: |
| 65 | + |
| 66 | +* Prevents unauthorized incoming connections |
| 67 | +* Allows communication with arbitrary image registries |
| 68 | +* Establishes a foundation for future refinements to egress rules |
| 69 | + |
| 70 | +While allowing all egress does present some security risks, this implementation provides significant security improvements over having no network policies at all. |
| 71 | + |
| 72 | +## Troubleshooting Network Issues |
| 73 | + |
| 74 | +If you encounter network connectivity issues after deploying OLMv1, consider the following: |
| 75 | + |
| 76 | +* Verify NetworkPolicy support: Ensure your cluster has a CNI plugin that supports NetworkPolicy. If your Kubernetes cluster is using a Container Network Interface (CNI) plugin that doesn't support NetworkPolicy, then the NetworkPolicy resources you create will be completely ignored and have no effect whatsoever on traffic flow. |
| 77 | +* Check pod labels: Confirm that catalogd and operator-controller pods have the correct labels for NetworkPolicy selection: |
| 78 | + |
| 79 | +```bash |
| 80 | +# Verify catalogd pod labels |
| 81 | +kubectl get pods -n olmv1-system --selector=control-plane=catalogd-controller-manager |
| 82 | + |
| 83 | +# Verify operator-controller pod labels |
| 84 | +kubectl get pods -n olmv1-system --selector=control-plane=operator-controller-controller-manager |
| 85 | + |
| 86 | +# Compare with actual pod names |
| 87 | +kubectl get pods -n olmv1-system | grep -E 'catalogd|operator-controller' |
| 88 | +``` |
| 89 | +* Inspect logs: Check component logs for connection errors |
| 90 | + |
| 91 | +For more comprehensive information on NetworkPolicy, see: |
| 92 | + |
| 93 | +- 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) |
| 94 | +- Installing [Network Policy Providers](https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/) documentation. |
0 commit comments