A Kubernetes network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. These network policies are configured as YAML files. By looking at these files alone, it is often hard to identify whether the applied network policies achieve the desired network topology.

Red Hat Advanced Cluster Security for Kubernetes gathers all defined network policies from your orchestrator and provides functionality to make these policies easier to use.

To support network policy enforcement, Red Hat Advanced Cluster Security for Kubernetes provides:

  • Network graph

  • Network policy simulator

  • Network policy generator

Network graph view

The network graph provides visibility and control over:

  • The allowed network connections, as defined by the Kubernetes network policies.

  • The active communications paths among namespaces and deployments.

In the Network Graph view, you can configure the type of connections you want to see. In the Flows section (upper left), select:

  • Active to view only active connections.

  • Allowed to view only allowed network connections.

  • All to view both active and allowed network connections.

In the network graph, each circle represents a deployment, each surrounding box represents a Kubernetes namespace, and each thick line represents connection between namespaces. You can hover over these items to view more details.

To understand the meaning of other symbols in the network graph, move you mouse over other symbols in the legend (lower left) to view the tooltip indicating the meaning of those symbols.

When you hover over:

  • a connection, you see information about the network flow, which includes active connections, port numbers and protocols in use.

  • a deployment, you see information about ingress and egress connections, protocols, port numbers in use, and the direction of the network traffic between deployments.

You need Red Hat Advanced Cluster Security for Kubernetes version 3.0.47 or newer to see information about ingress and egress connections, protocols, port numbers, and the direction of the network traffic.

Allowed network connections

Red Hat Advanced Cluster Security for Kubernetes processes all network policies in each secured cluster to show you which deployments can contact each other, and which can reach external networks.

The network graph shows possible network connections as dashed lines.

Actual network flows

Red Hat Advanced Cluster Security for Kubernetes monitors running deployments and tracks traffic between them. The network graph shows observed network flows as solid lines.

Network baseline

Red Hat Advanced Cluster Security for Kubernetes discovers existing network flows and creates a baseline.

To view the network baseline for a deployment, select that deployment in the Network Graph view. The Network Flows details panel show both anomalous and baseline flows. From this panel, you can:

  • Mark network flows from the baseline as anomalous by selecting Mark as Anomalous.

  • Add network flows to baseline from the anomalous flows by selecting Add to Baseline.

To use the Network baseline feature, you must use Red Hat Advanced Cluster Security for Kubernetes version 3.0.54 or newer.

External entities and connections

The Network Graph view shows information about network connections between managed clusters and external sources. Red Hat Advanced Cluster Security for Kubernetes also automatically discovers and highlights public CIDR (Classless Inter-Domain Routing) addresses blocks, such as Google Cloud, AWS, Azure, Oracle Cloud, and Cloudflare. Using this information, you can identify deployments with active external connections and if they are making or receiving unauthorized connections from outside of your network.

You need Red Hat Advanced Cluster Security for Kubernetes version 3.0.52 or newer to see information about active external connections.

By default, the external connections point to a common External Entities box, and different CIDR addresses blocks in the Network Graph view. However, you can choose not to show auto-discovered CIDR blocks.

Red Hat Advanced Cluster Security for Kubernetes includes IP ranges for the following cloud providers:

  • Google Cloud

  • AWS

  • Azure

  • Oracle Cloud

  • Cloudflare

Red Hat Advanced Cluster Security for Kubernetes fetches and updates the cloud providers' IP ranges every 7 days. If you are using offline mode, you can update these ranges by installing new support packages.

Viewing network policies

Network policies specify how groups of pods are allowed to communicate with each other and with other network endpoints. Kubernetes NetworkPolicy resources use labels to select pods and define rules that specify what traffic is allowed to or from the selected pods. Red Hat Advanced Cluster Security for Kubernetes discovers and displays network policy information for all your Kubernetes clusters, namespaces, deployments, and pods, in the Network Graph view.

To view network policies and other related details for deployments in a namespace, you can select the namespace in Network Graph view.

The namespace details panel lists all deployments in the selected namespace. You can then hover over a deployment in the details panel and select the Navigate to deployment (arrow) icon that appears on the right to view deployment details.

Alternatively, you can directly select a deployment in the Network Graph view to view its details. The deployment details panel includes the Network Flows, Details, and Network Policies tabs.

You can select each tab to view related information.

  • The Network Flows tab shows information about ingress and egress connections, protocols, and port numbers in use for that deployment.

  • The Details tab shows information about how the service is deployed, including orchestrator labels and annotations.

  • The Network Policies tab shows information about every network policy that applies to the deployment.

You need Red Hat Advanced Cluster Security for Kubernetes version 3.0.47 or newer to see information about ingress and egress connections, protocols, port numbers, and the direction of the network traffic.

Configuring CIDR blocks

You can specify custom CIDR blocks or configure displaying auto-discovered CIDR block in the Network Graph view.

Procedure
  1. In the Network Graph view, select Configure CIDR Blocks.

  2. Turn the Display auto-discovered CIDR blocks in Network Graph toggle off to hide auto-discovered CIDR blocks.

    When you hide the auto-discovered CIDR blocks, the auto-discovered CIDR blocks are hidden for all clusters, not only for the selected cluster on the top bar in the Network Graph view.

  3. Add custom CIDR addresses by adding CIDR Block Name and CIDR Address. To add more than one, select the Add icon.

  4. Click Update Configuration to save the changes.

Simulating network policies

Your current network policies might allow unneeded network communications. To simulate the effects of a new set of network policies, use the network policy simulator.

Procedure
  1. On the RHACS portal, select Network Graph from the left-hand navigation menu.

  2. On the Network Graph view header, select Network Policy Simulator.

  3. Select Upload and simulate network policy YAML and upload your proposed YAML file. The network graph view displays what your proposed network policies would achieve.

  4. To share your proposed policies with your team, select Share YAML. To apply your policy directly, select Apply Network Policies.

Directly applying network policies might cause problems for running applications. Always download and test the network policies in a development environment or test clusters before applying them to production workloads.

Generating network policies

A Kubernetes network policy controls which pods receive incoming network traffic, and which pods can send outgoing traffic. By using network policies to enable and disable traffic to or from pods, you can limit your network attack surface.

These network policies are YAML configuration files. It is often difficult to gain insights into the network flow and manually create these files. Red Hat Advanced Cluster Security for Kubernetes allows you to autogenerate these network policies based on the actual observed network communication flows in your environment.

You can generate network policies from the network graph view.

The generated policies apply to the deployments shown in the network graph and they allow all network traffic observed during the selected time.

Procedure
  1. In the RHACS portal, select Network Graph from the left-hand navigation menu.

  2. Select a cluster name from the menu on the top bar, if the right one is not already selected.

  3. If you want to generate policies for only some deployments, use the filter box to filter the deployments you want. If you do not add a filter, Red Hat Advanced Cluster Security for Kubernetes generates policies for all deployments in the cluster.

  4. Select an appropriate time from the menu on the top bar. If the selected time is too short it leaves out periodic or infrequent network communications.

  5. Select Network Policy Simulator.

  6. In the panel that opens, select Exclude ports & protocols if you do not want ports and protocols to be scoped in Red Hat Advanced Cluster Security for Kubernetes generated policies.

  7. Select Generate and simulate network policies. The generated network policy configuration YAML opens in the same panel, and the network graph shows the effects of the policies.

Saving generated policies

You can download and save the generated network policies from Red Hat Advanced Cluster Security for Kubernetes. Use this option to commit the policies into a version control system like Git.

Procedure
  • Select the Download YAML icon on the Network Policy Simulator panel.

Testing generated policies

After you download the network policies that Red Hat Advanced Cluster Security for Kubernetes generates, you can test them by applying them to your cluster.

Procedure
  1. To create policies using the saved YAML file, use the following command:

    $ oc create -f "<generated_file>.yaml" (1)
    1 Use kubectl instead of oc if you are using Kubernetes.
  2. If the generated policies cause problems, you can remove them by running the following command:

    $ oc delete -f "StackRox Generated.yaml" (1)
    1 Use kubectl instead of oc if you are using Kubernetes.

Applying generated policies

You can apply the generated network policies from the RHACS portal.

Procedure
  • To directly apply the generated policies in the cluster from within Red Hat Advanced Cluster Security for Kubernetes, select Apply Network Policies.

Directly applying network policies might cause problems for running applications. Always download and test the network policies in a development environment or test clusters before applying them to production workloads.

Deleting generated policies

If you have applied generated policies directly and want to remove them, select the Revert most recently applied YAML icon on the Network Policy Simulator panel.

Procedure
  1. In the RHACS portal, select Network Graph from the left-hand navigation menu.

  2. Select a cluster name from the menu on the top bar, if the right one is not already selected.

  3. Select Network Policy Simulator.

  4. Select View active YAMLS.

  5. Select the Revert most recently applied YAML icon.

Deleting all autogenerated policies

You can delete all generated policies from your cluster that you have created by using Red Hat Advanced Cluster Security for Kubernetes.

Procedure
  • Run the following command:

    • On OpenShift Container Platform:

      $ oc get ns -o jsonpath='{.items[*].metadata.name}' | xargs -n 1 oc delete networkpolicies -l 'network-policy-generator.stackrox.io/generated=true' -n
    • On Kubernetes:

      $ kubectl get ns -o jsonpath='{.items[*].metadata.name}' | xargs -n 1 kubectl delete networkpolicies -l 'network-policy-generator.stackrox.io/generated=true' -n

Policy generation strategy

When you autogenerate network policies:

  • Red Hat Advanced Cluster Security for Kubernetes generates a single network policy for each deployment in the namespace. The pod selector for the policy is the pod selector of the deployment.

    • If a deployment already has a network policy, Red Hat Advanced Cluster Security for Kubernetes does not generate new policies or delete existing policies.

  • Generated policies only restrict traffic to existing deployments.

    • Deployments you create later will not have any restrictions unless you create or generate new network policies for them.

    • If a new deployment needs to contact a deployment with a network policy, you might need to edit the network policy to allow access.

  • Each policy has the same name as the deployment name, prefixed with stackrox-generated-. For example, the policy name for the deployment depABC in the generated network policy is stackrox-generated-depABC. All generated policies also have an identifying label.

  • Red Hat Advanced Cluster Security for Kubernetes generates a single rule allowing traffic from any IP address if:

    • The deployment has an incoming connection from outside the cluster within the selected time, or

    • The deployment is exposed through a node port or load balancer service.

  • Red Hat Advanced Cluster Security for Kubernetes generates one ingress rule for every deployment from which there is an incoming connection.

    • For deployments in the same namespace, this rule uses the pod selector labels from the other deployment.

    • For deployments in different namespaces, this rule uses a namespace selector. To make this possible, Red Hat Advanced Cluster Security for Kubernetes automatically adds a label, namespace.metadata.stackrox.io/name, to each namespace.

In rare cases, if a standalone pod does not have any labels, the generated policy allows traffic from or to the pod’s entire namespace.

Using network baselining

In Red Hat Advanced Cluster Security for Kubernetes, you can minimize your risks by using network baselining. It is a proactive approach to keep your infrastructure secure. Red Hat Advanced Cluster Security for Kubernetes first discovers existing network flows and creates a baseline, and then it treats network flows outside of this baseline as anomalous.

  • To use the Network baseline feature, you must use the Red Hat Advanced Cluster Security for Kubernetes version 3.0.54 or newer.

  • To enable alerts on baseline violations, you must use Red Hat Advanced Cluster Security for Kubernetes version 3.0.56 or newer.

When you install Red Hat Advanced Cluster Security for Kubernetes, there is no default network baseline. As Red Hat Advanced Cluster Security for Kubernetes discovers network flows, it creates a baseline and then it adds all discovered network flows to it.

  • When Red Hat Advanced Cluster Security for Kubernetes discovers new network activity, it adds that network flow to the network baseline.

  • Network flows do not show up as anomalous flows and do not trigger any violations.

After the discovery phase:

  • Red Hat Advanced Cluster Security for Kubernetes stops adding network flows to the network baselines.

  • New network flows (which are not in the network baseline) show up as anomalous flows but they do not trigger any violations.

Viewing network baselines

You can view network baselines from the network graph view.

Procedure
  1. On the Network Graph view, select a deployment.

  2. The Network Flows details panel show both anomalous and baseline flows. From this panel, you can:

    • mark network flows from the baseline as anomalous by selecting Mark as Anomalous, or

    • add network flows to baseline from the anomalous flows by selecting Add to Baseline.

Enabling alerts on baseline violations

You can configure Red Hat Advanced Cluster Security for Kubernetes to detect anomalous network flows and trigger violations.

You need Red Hat Advanced Cluster Security for Kubernetes version 3.0.56 or newer to enable alerts on baseline violations.

Procedure
  1. On the Network Graph view, select a deployment.

  2. In the network flow details panel, select Baseline Settings.

  3. Turn on the Alert on baseline violations toggle.

    • Once you turn on the Alert on baseline violations toggle anomalous network flows trigger violations.

    • You can turn off the Alert on baseline violations toggle to stop receiving violations for anomalous network flows.