Configure network policies

Configure network policies to restrict Pod-to-Pod traffic for the Che components and for each workspace. The Che Operator can manage the NetworkPolicy resources for the Che components automatically, and the DevWorkspace Operator provisions a NetworkPolicy for each workspace. Both network policy features are disabled by default.

Network policies

By default, all Pods in a Kubernetes cluster can communicate with each other across namespaces. In Che, this allows a workspace Pod in one user namespace to send traffic to workspace Pods in other user namespaces.

Network policies restrict network traffic to only the flows required by Che components and workspaces.

Custom rules for workspace network policies

The ingress and egress fields of the spec.devEnvironments.networking.networkPolicy CheCluster field accept standard Kubernetes NetworkPolicy rules and behave as follows:

When ingress is not specified, the default ingress rules of the DevWorkspace Operator apply, and the Che Operator adds one rule allowing traffic from the Che components. On OpenShift, the default rules allow traffic from the DevWorkspace Operator namespace and from the OpenShift monitoring, ingress, host-network, and console namespaces. On Kubernetes, the default allows all ingress because the DevWorkspace Operator cannot identify the namespace of the cluster ingress controller; define custom ingress rules to restrict ingress.
When ingress is specified as an empty list, all ingress traffic to the workspace Pods is denied.
When ingress is specified as a non-empty list, exactly those rules apply: the default rules are replaced, and the rule allowing traffic from the Che components is not added automatically. If the Che components must communicate with the workspaces, include a corresponding ingress rule.

The egress field behaves the same way. When it is not specified, the default egress rule of the DevWorkspace Operator applies, which allows all egress traffic. When it is specified as an empty list, all egress traffic from the workspace Pods is denied. When it is specified as a non-empty list, exactly those rules apply.

Enable Operator-managed network policies

Enable Operator-managed network policies to restrict ingress traffic to the Che components, such as the gateway, server, dashboard, and registries. The Che Operator creates and manages the NetworkPolicy resources automatically. This feature is controlled by the spec.networking.networkPolicy.enabled CheCluster field and is disabled by default.

The NetworkPolicies are created in the Che namespace and apply only to the Pods labeled with app.kubernetes.io/part-of=che.eclipse.org. When this field is set to false, the NetworkPolicies previously created by the Operator are removed.

This setting also drives network isolation for workspaces: when spec.devEnvironments.networking.networkPolicy.enabled is not set, it inherits the value of spec.networking.networkPolicy.enabled. Enabling it therefore also isolates workspaces, which changes traffic behavior on clusters with running workspaces. To protect the Che components without isolating the workspaces, explicitly set spec.devEnvironments.networking.networkPolicy.enabled to false in step 2. See Configure network policies.

Prerequisites

An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

Procedure

Enable Operator-managed network policies:

kubectl patch checluster/eclipse-che \
  --namespace eclipse-che \
  --type merge \
  --patch '{"spec":{"networking":{"networkPolicy":{"enabled":true}}}}'

Optional: To protect the Che components without isolating the workspaces, disable network isolation for workspaces:

kubectl patch checluster/eclipse-che \
  --namespace eclipse-che \
  --type merge \
  --patch '{"spec":{"devEnvironments":{"networking":{"networkPolicy":{"enabled":false}}}}}'

Verification

Verify that the NetworkPolicy resources are created in the Che namespace:
```
kubectl get networkpolicies -n eclipse-che
```
Start a workspace and verify that a NetworkPolicy resource is created for it in the user namespace:
```
kubectl get networkpolicies -n <user_namespace>
```

After enabling, the Operator creates the following resources:

Table 1. NetworkPolicy resources in the Che namespace on OpenShift
Name	Description
`allow-from-same-namespace`	Allows ingress traffic between Che Pods in the same namespace.
`allow-from-workspaces`	Allows ingress traffic from user workspace namespaces.
`allow-from-openshift-ingress`	Allows ingress traffic from the OpenShift ingress namespace.
`allow-from-openshift-host-network`	Allows ingress traffic from Pods that use the host network, for example the OpenShift router.
`allow-from-openshift-monitoring`	Allows ingress traffic from the OpenShift monitoring namespace.
`allow-from-che-operator`	Allows ingress traffic from the Operator Pod to Che components.
`allow-all-egress`	Allows all egress traffic from Che Pods.

On Kubernetes, the Operator creates only the allow-all-ingress and allow-all-egress NetworkPolicies, which allow all ingress and egress traffic. The namespace of the cluster ingress controller is not known to the Operator. Enabling this setting on Kubernetes does not restrict any traffic by itself: you must provision the NetworkPolicy resources for your cluster manually.

When network isolation for workspaces is enabled, the DevWorkspace Operator creates a <workspace_id>-networkpolicy NetworkPolicy resource in the user namespace for each workspace. See Configure network policies.

Additional resources

Kubernetes network policies