Kubernetes Network Policies
IOMETE services rely on specific network configurations to function properly in a Kubernetes cluster. These network policies govern how different components communicate securely and efficiently.
Spark Operator Webhook Policy
The webhook service plays a critical role in managing IOMETE resources. If resource creation times out or fails, there could be a connectivity issue between the Kubernetes API server and the webhook. This is often due to restrictive network policies that block incoming traffic.
Kubernetes API server requires access to the Spark Operator webhook service. This policy allows controlled ingress traffic to the webhook while restricting external access.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: iomete-spark-operator
spec:
podSelector:
matchLabels:
service: spark-operator
ingress:
- from:
- ipBlock:
cidr: [API_SERVER_IP]/32 # Replace with your API server's IP
egress:
- {}
policyTypes:
- Ingress
- Egress
How to Find API Server IP Use the following command to retrieve the API server IP and update the policy:
kubectl cluster-info | grep master
Replace [API_SERVER_IP] in the YAML file with the actual IP address.
IOMETE Namespaces Communication Policy
This policy ensures that all IOMETE control plane and data plane services can communicate securely across namespaces, using the label iomete.com/managed: "true".
It leaves out Jupyter Container pods. Kubernetes combines policies by allowing anything any of them allows, so a policy that selects every pod would cancel out the Jupyter Containers policy.
Use the NotIn selector below only when the Jupyter Containers policy is installed. Without it, notebooks match no policy and become fully open, so keep podSelector: {} instead.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: iomete-ingress-egress
spec:
podSelector:
matchExpressions:
- key: iomete.com/appType
operator: NotIn
values:
- jupyterContainer
ingress:
- from:
- namespaceSelector:
matchLabels:
iomete.com/managed: "true"
egress:
- {}
policyTypes:
- Ingress
- Egress
Jupyter Containers Policy
Jupyter Containers run user code, so the data plane Helm chart can install a policy named iomete-jupyter-containers in the data plane namespace and every Spark namespace. It's off by default. To turn it on, set this in values.yaml and run the Helm upgrade:
networkPolicies:
jupyterContainers:
enabled: true
The policy only restricts traffic when your cluster's network plugin enforces NetworkPolicies, so check that before relying on it.
With it:
- Only the IOMETE gateway can reach notebooks.
- Notebooks can reach DNS, your ingress controller and the internet over IPv4 and IPv6.
- Apart from DNS, your ingress controller and any
extraEgressentries, notebooks can't reach private, link-local (cloud metadata) or carrier-grade NAT addresses.
If you applied iomete-ingress-egress before, it may still select every pod and cancel this policy. Re-apply the updated version and check its podSelector uses NotIn jupyterContainer:
kubectl get networkpolicy iomete-ingress-egress -n <namespace> -o yaml
Notebooks connect to compute clusters through your ingress controller. The policy allows the istio-system, istio-ingress, ingress-nginx, openshift-ingress and traefik namespaces. If your controller runs elsewhere, or your platform host resolves to a private IP, adjust the policy in values.yaml:
networkPolicies:
jupyterContainers:
ingressNamespaces:
- my-ingress
extraEgress:
- to:
- ipBlock:
cidr: 10.20.30.40/32 # internal load balancer or private data source
ports:
- protocol: TCP
port: 443
| Setting | Use it to |
|---|---|
ingressNamespaces | List the namespaces of the ingress controller serving the platform host. Setting it replaces the default list. |
extraEgress | Allow an internal address notebooks need. |
blockedCidrs | Change which IPv4 and IPv6 ranges count as internal. |
dnsPorts | Change the ports notebooks use for DNS, for example add 5353 on OpenShift. |
enabled | Turn the policy on. |
If notebooks open but can't connect to a compute cluster, add your ingress controller's namespace to ingressNamespaces.
To apply the policy yourself instead of through the chart, save it as iomete-jupyter-containers.yaml, replace <iomete-namespace> with the data plane namespace, and apply it to the data plane namespace and every Spark namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: iomete-jupyter-containers
spec:
podSelector:
matchLabels:
iomete.com/appType: jupyterContainer
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: <iomete-namespace>
podSelector:
matchExpressions:
- key: app
operator: In
values:
- iom-gateway
- iom-gateway-dp
ports:
- protocol: TCP
port: 8888
egress:
- ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
- to:
- namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: In
values:
- istio-system
- istio-ingress
- ingress-nginx
- openshift-ingress
- traefik
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- 169.254.0.0/16
- 100.64.0.0/10
- ipBlock:
cidr: "::/0"
except:
- fc00::/7
- fe80::/10
kubectl apply -f iomete-jupyter-containers.yaml -n <iomete-namespace>
kubectl apply -f iomete-jupyter-containers.yaml -n <spark-namespace>
Applying Network Policies
The following steps explain how to apply network policies to IOMETE control plane and data plane namespaces.
- Save both
iomete-spark-operator.yamlandiomete-ingress-egress.yamlfiles. - In the
iomete-spark-operator.yaml, replace:[API_SERVER_IP]with your Kubernetes API server's IP address (obtain this usingkubectl cluster-info | grep master). - Apply the policies using
kubectlto the respective namespaces:
kubectl apply -f iomete-spark-operator.yaml -n <iomete-namespace>
kubectl apply -f iomete-ingress-egress.yaml -n <iomete-namespace>
Ensure that both policies have been applied successfully
Troubleshooting
If issues arise, follow these troubleshooting steps:
- Verify Policy Application: Ensure the policies are correctly applied:
kubectl get networkpolicies -n <namespace>
- Check API Server Access: Confirm that the API server can reach the webhook:
kubectl cluster-info | grep master
- Connectivity Issues: If errors persist, review your network policies and consult with your networking team or system administrator for potential misconfigurations.
Conclusion
Ensuring proper network communication between IOMETE components is essential for the platform's security and performance. By applying the correct network policies and monitoring connectivity, you can maintain a secure and efficient IOMETE deployment.