1. Documentation
    2. history
×

Managing network policies

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 (RHACS) gathers all defined network policies from your orchestrator and provides tools to make these policies easier to use.

To support network policy enforcement, RHACS provides the following tools:

  • Network graph

  • Network policy simulator

  • Network policy generator

  • Build-time network policy generator

This documentation describes the network graph (1.0), which is deprecated in RHACS 4.0, and is scheduled for removal in a future release. It also describes the network graph (2.0 preview), provided in RHACS 3.74 and 4.0 as a Technology Preview.

Network graph (2.0 preview)

Network graph (2.0 preview) is provided in RHACS 3.74 and 4.0 and is a Technology Preview feature.

About the network graph (2.0 preview)

The network graph provides high-level and detailed information about deployments, network flows, and network policies in your environment.

Network graph 2.0 is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

RHACS processes all network policies in each secured cluster to show you which deployments can contact each other and which can reach external networks. It also monitors running deployments and tracks traffic between them. You can view the following items in the network graph:

Network components

From the top menu, you can select namespaces (indicated by the NS label) and deployments (indicated by the D label) to display on the graph for a chosen cluster (indicated by the CL label). You can further filter deployments by using the drop-down list and selecting criteria on which to filter, such as common vulnerabilities and exposures (CVEs), labels, and images.

External entities

These represent entities that are connected outside of your cluster. More information is provided in "External entities and connections in the network graph (2.0 preview)".

Network policies

You can view existing policies for a selected component or view components that have no policies.

Network flows

You can select one of the following flows for the graph:

Active traffic

Selecting this default option shows observed traffic, focused on the namespace or specific deployment that you selected. You can select the time period for which to display information.

Inactive flows

Selecting this option shows potential flows allowed by your network policies, helping you identify missing network policies needed to achieve tighter isolation. You can select the time period for which to display information.

You can also simulate network policies from the network graph view. See "Simulating network policies from the network graph" for version 1.0 or 2.0 preview for more information.

  • Clicking on items in the graph lets you view additional information about components or perform actions such as adding a network flow to your baseline.

  • Opening the legend provides information about the symbols in use and their meaning. The legend shows explanatory text for symbols representing namespaces, deployments, and connections on the network graph.

  • Selecting additional display options from the drop-down list controls whether the graph displays icons such as the network policy status badge, active external traffic badge, and port and protocol labels for edge connections.

  • RHACS detects changes in network traffic, such as nodes joining or leaving. If changes are detected, the network graph displays a notification showing the number of updates available. To avoid interrupting your focus, the graph is not updated automatically. Click the notification to update the graph.

External entities and connections in the network graph (2.0 preview)

The network graph view shows network connections between managed clusters and external sources. In addition, RHACS automatically discovers and highlights public Classless Inter-Domain Routing (CIDR) address blocks, such as Google Cloud, AWS, Microsoft Azure, Oracle Cloud, and Cloudflare. Using this information, you can identify deployments with active external connections and decide if they are making or receiving unauthorized connections from outside your network.

By default, the external connections point to a common External Entities icon and different CIDR address blocks in the network graph. However, you can choose not to show auto-discovered CIDR blocks by clicking Manage CIDR blocks and deselecting Auto-discovered CIDR blocks.

RHACS includes IP ranges for the following cloud providers:

  • Google Cloud

  • AWS

  • Microsoft Azure

  • Oracle Cloud

  • Cloudflare

RHACS fetches and updates the cloud providers' IP ranges every 7 days, and updates CIDR blocks daily. If you are using offline mode, you can update these ranges by installing new support packages.

The following image provides an example of the network graph. In this example, based on the options that the user has chosen, the graph depicts deployments in the selected namespace. Traffic flows are not displayed until you click on an item such as a deployment. The graph uses a red badge to indicate deployments that are missing policies and therefore allowing all network traffic.

Overview of the Network graph showing deployments
Figure 1. Network graph example

When you click an item in the graph, the rearranged side panel with collapsible sections presents information about that item. You can click on the following items:

  • Deployments

  • Namespaces

  • External entities

  • CIDR blocks

  • External groups

The side panel displays relevant information based on the item in the graph that you have selected. The D or NS label next to the item name in the header (in this example, "postgres,") indicates if it is a deployment or a namespace. The following example illustrates deployment mode.

Side panel for a deployment
Figure 2. Side panel for a deployment example

In Namespace mode, the side panel includes a search bar and a list of deployments. You can click on a deployment to view its information. In Namespace mode, the side panel also includes a Network policies tab. From this tab, you can view, copy to the clipboard, or export any network policy defined in that namespace, as shown in the following example.

Side panel for a namespace showing network policy information
Figure 3. Side panel for a namespace example

Viewing deployment information

The network graph provides a visual map of deployments, namespaces, and connections that RHACS has discovered. By clicking on a deployment in the graph, you can view information about the deployment, including the following details:

  • Network security, such as the number of flows, existing or missing network policy rules, and listening ports

  • Labels and annotations

  • Port configurations

  • Container information

  • Anomalous and baseline flows for ingress and egress connections, including protocols and port numbers

  • Network policies

Procedure

To view details for deployments in a namespace:

  1. In the RHACS portal, navigate to Network Graph (2.0 preview) and select your cluster from the drop-down list.

  2. Click the Namespace list and use the search field to locate a namespace or select individual namespaces.

  3. Click the Deployments list and use the search field to locate a deployment or select individual deployments to display in the network graph.

  4. In the network graph, click on a deployment to view the information panel.

  5. Click the Details, Flows, Baseline, or Network policies tab to view the corresponding information.

Viewing network policies in the network graph (2.0 preview)

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. RHACS discovers and displays network policy information for all your Kubernetes clusters, namespaces, deployments, and pods, in the network graph.

Procedure

  1. In the RHACS portal, navigate to Network Graph (2.0 preview) and select your cluster from the drop-down list.

  2. Click the Namespace list and use the search field to locate a namespace or select individual namespaces.

  3. Click the Deployments list and use the search field to locate a deployment or select individual deployments to display in the network graph.

  4. In the network graph, click on a deployment to view the information panel.

  5. In the Details tab, in the Network security section, you can view summary messages about network policy rules that give the following information:

    • If policies exist in the network that regulate ingress or egress traffic

    • If your network is missing policies and therefore allowing all ingress or egress traffic

  6. To view the YAML file for the network policies, you can click on the policy rule, or click the Network policies tab.

Configuring CIDR blocks in the network graph (2.0 preview)

You can specify custom CIDR blocks or configure the display of auto-discovered CIDR blocks in the network graph.

Procedure

  1. In the RHACS portal, navigate to Network Graph (2.0 preview), and then select Manage CIDR Blocks. You can perform the following actions:

    • Toggle Auto-discovered CIDR blocks to hide auto-discovered CIDR blocks in the network graph.

      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.

    • Add a custom CIDR block to the graph by performing the following steps:

      1. Enter the CIDR name and CIDR address in the fields. To add additional CIDR blocks, click Add CIDR block and enter information for each block.

      2. Click Update Configuration to save the changes.

Simulating network policies from the network graph (2.0 preview)

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. For information about using the network policy simulator to generate policies, see "Generating network policies in the network graph (2.0 preview)."

Procedure

  1. In the RHACS portal, navigate to Network Graph (2.0 preview).

  2. Select a cluster, and then select one or more namespaces.

  3. On the network graph header, select Simulate network policy.

  4. Optional: Generate a YAML file with network policies to use in the simulation by clicking Generate and simulate network policies. For more information, see "Generating network policies in the network graph (2.0 preview)".

  5. Upload a YAML file of a network policy that you want to use in the simulation. The network graph view displays what your proposed network policies would achieve. Perform the following steps:

    1. Click Upload YAML and then select the file.

    2. Click Open. The system displays a message to indicate the processing status of the uploaded policy.

  6. You can view active YAML files that correspond to the current network policies by clicking the View active YAMLS tab, and then selecting policies from the drop-down list. You can also perform the following actions:

    • Click the appropriate button to copy or download the displayed YAML file.

    • Use the Actions menu to rebuild rules from active traffic or revert rules to a previously applied YAML. For more information, see "Generating network policies from the network graph (2.0 preview)".

      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.

About generating policies from the network graph (2.0 preview)

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. You can use RHACS to generate these files. When you automatically generate network policies, RHACS follows these guidelines:

  • RHACS 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, RHACS does not generate new policies or delete existing policies.

      Generated policies only restrict traffic to existing deployments.

    • Deployments that 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.

  • RHACS generates a single rule allowing traffic from any IP address if one of the following conditions are met:

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

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

  • RHACS 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, RHACS 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.

Generating network policies in the network graph (2.0 preview)

RHACS lets you automatically generate network policies based on the actual observed network communication flows in your environment.

You can generate network policies from the network graph.

The generated policies apply to all deployments that exist in the currently selected cluster. They also allow all network traffic observed during the baseline discovery period.

Procedure

  1. In the RHACS portal, navigate to Network Graph (2.0 preview).

  2. Select a cluster, and then select one or more namespaces.

  3. In the network graph header, select Simulate network policy. RHACS generates policies for all deployments that exist in the selected cluster.

  4. Optional: In the information panel that opens, select Exclude ports & protocols if you do not want ports and protocols to be scoped in RHACS generated policies.

  5. Select Generate and simulate network policies. The generated network policy configuration YAML file opens in the same panel, and the network graph shows the effects of the 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.

Saving generated policies in the network graph (2.0 preview)

You can download and save the generated network policies from RHACS. Use this option to commit the policies into a version control system such as Git.

Procedure

  • After generating a network policy, click the Download YAML icon in the Network Policy Simulator panel.

Testing generated policies in the network graph (2.0 preview)

After you download the network policies that RHACS generates, you can test them by applying them to your cluster.

Procedure

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

    $ oc create -f "<generated_file>.yml" (1)
    1 If you use Kubernetes, enter kubectl instead of oc.

  2. If the generated policies cause problems, you can remove them by running the following command:

    $ oc delete -f "<generated_file>.yml" (1)
    1 If you use Kubernetes, enter kubectl instead of oc.

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.

Applying generated policies in the network graph (2.0 preview)

You cannot apply generated network policies from the network graph in the network graph (2.0 preview). Apply Kubernetes network policies as part of your automated procedures.

Reverting to a previously applied policy in the network graph (2.0 preview)

You can remove a policy and revert to a previously applied policy.

Procedure

  1. In the RHACS portal, navigate to Network Graph (2.0 preview).

  2. Select a cluster name from the menu on the top bar.

  3. Select one or more namespaces and deployments.

  4. Select Simulate network policy.

  5. Select View active YAMLS.

  6. From the Actions menu, select Revert rules to previously applied YAML.

    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 all policies autogenerated in the network graph (2.0 preview)

You can delete all automatically generated policies from your cluster that you have created by using RHACS.

Procedure

  • Run the following command:

    $ oc get ns -o jsonpath='{.items[*].metadata.name}' | \
xargs -n 1 oc delete networkpolicies -l \
'network-policy-generator.stackrox.io/generated=true' -n (1)
    1 If you use Kubernetes, enter kubectl instead of oc.

Network graph (1.0)

The Network graph (1.0) is deprecated in RHACS 4.0, and is scheduled for removal in a future release.

About the network graph (1.0)

The network graph provides visibility and control over the following items:

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

  • The active communications paths among namespaces and deployments.

In the menu bar, choose the cluster for which you want to view information and at least one namespace.

In the network graph, you can configure the type of connections you want to see. In the Flows section, select:

  • Active to view only active connections.

  • Allowed to view only allowed network connections.

  • All to view active and allowed network connections.

In the network graph, click Legend to view information about the symbols in use and their meaning. The legend shows explanatory text for symbols representing namespaces, deployments, and connections on the network graph.

Clicking on an item in the network graph, such as a deployment or a namespace, opens a window that displays additional information. You can expand and collapse the window by selecting the arrow in the blue bar.

When you hover over a connection, you see information about the network flow, which includes active connections, port numbers, and protocols in use. When you hover over a deployment, you see information about ingress and egress connections, protocols, port numbers in use, and the direction of the network traffic between deployments.

Allowed network connections

RHACS 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

RHACS monitors running deployments and tracks traffic between them. The network graph shows observed network flows as solid lines.

Network baseline

RHACS discovers existing network flows and creates a baseline.

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

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

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

When RHACS detects changes in network traffic, such as nodes joining or leaving, the network graph displays a notification showing the number of updates available. To avoid interrupting your focus, the graph is not updated automatically. Click the notification to update the graph.

External entities and connections

The network graph shows network connections between managed clusters and external sources. In addition, RHACS automatically discovers and highlights public Classless Inter-Domain Routing (CIDR) address blocks, such as Google Cloud, AWS, Microsoft Azure, Oracle Cloud, and Cloudflare. Using this information, you can identify deployments with active external connections and decide if they are making or receiving unauthorized connections from outside your network.

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

RHACS includes IP ranges for the following cloud providers:

  • Google Cloud

  • Amazon Web Services (AWS)

  • Microsoft Azure

  • Oracle Cloud

  • Cloudflare

RHACS fetches and updates the cloud providers' IP ranges every 7 days and CIDR blocks are updated daily. 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.

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

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 icon that appears on the right to view deployment details.

You can also directly select a deployment in the network graph 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 in the network graph (1.0)

You can specify custom CIDR blocks or configure displaying auto-discovered CIDR block in the network graph.

Procedure

  1. In the RHACS portal, navigate to Network Graph (1.0), and then select Configure CIDR Blocks.

  2. Toggle the Display auto-discovered CIDR blocks in Network Graph option 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.

  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 from the network graph (1.0)

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. In the RHACS portal, navigate to Network Graph (1.0).

  2. Select one or more namespaces.

  3. On the network graph header, select Network Policy Simulator.

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

  5. To share your proposed policies with your team, select Share YAML.

  6. 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.

About generating 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. You can use Red Hat Advanced Cluster Security for Kubernetes (RHACS) to generate these files. When you autogenerate network policies, RHACS follows these guidelines:

  • RHACS 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, RHACS does not generate new policies or delete existing policies.

  • Generated policies only restrict traffic to existing deployments.

    • Deployments that 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.

  • RHACS generates a single rule allowing traffic from any IP address if one of the following conditions are met:

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

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

  • RHACS 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, RHACS 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.

Generating network policies from the network graph (1.0)

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 lets you automatically generate 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, navigate to Network Graph.

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

  3. Select one or more namespaces.

  4. If you want to generate policies for only some deployments, use the Add one or more deployment filters field to add criteria by which to filter deployments. If you do not add a filter, Red Hat Advanced Cluster Security for Kubernetes generates policies for all deployments in the cluster.

  5. 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.

  6. Select Network Policy Simulator.

  7. 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.

  8. 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 RHACS. Use this option to commit the policies into a version control system such as Git.

Procedure

  • After generating a network policy, click the Download YAML icon in the Network Policy Simulator panel.

Testing generated policies

After you download the network policies that RHACS 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>.yml" (1)
    1 If you use Kubernetes, enter kubectl instead of oc.

  2. If the generated policies cause problems, you can remove them by running the following command:

    $ oc delete -f "<generated_file>.yml" (1)
    1 If you use Kubernetes, enter kubectl instead of oc.

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.

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 RHACS, 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, navigate to Network Graph (1.0).

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

  3. Select one or more namespaces.

  4. Select Network Policy Simulator.

  5. Select View active YAMLS.

  6. Select the Revert most recently applied YAML icon.

Deleting all policies autogenerated in the network graph (1.0)

You can delete all generated policies from your cluster that you have created by using RHACS.

Procedure

  • Run the following command:

    $ oc get ns -o jsonpath='{.items[*].metadata.name}' | \
xargs -n 1 oc delete networkpolicies -l \
'network-policy-generator.stackrox.io/generated=true' -n (1)
    1 If you use Kubernetes, enter kubectl instead of oc.
Additional resources

Using build-time network policy generator

Build-time network policy generation is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

The build-time network policy generator can automatically generate Kubernetes network policies based on application YAML manifests. You can use it to develop network policies as part of the continuous integration/continuous deployment (CI/CD) pipeline before deploying applications on your cluster.

Red Hat developed this feature in partnership with the developers of the NP-Guard project. First, the build-time network policy generator analyzes Kubernetes manifests in a local folder, including service manifests, config maps, and workload manifests such as Pod, Deployment, ReplicaSet, Job, DaemonSet, and StatefulSet. Then, it discovers the required connectivity and creates the Kubernetes network policies to achieve pod isolation. These policies allow no more and no less than the needed ingress and egress traffic.

Generating build-time network policies

The build-time network policy generator is included in the roxctl CLI. For the build-time network policy generation feature, roxctl CLI does not need to communicate with RHACS Central so you can use it in any development environment.

Prerequisites

  1. The build-time network policy generator recursively scans the directory you specify when you run the command. Therefore, before you run the command, you must already have service manifests, config maps, and workload manifests such as Pod, Deployment, ReplicaSet, Job, DaemonSet, and StatefulSet as YAML files in the specified directory.

  2. Verify that you can apply these YAML files as-is using the kubectl apply -f command. The build-time network policy generator does not work with files that use Helm style templating.

  3. Verify that the service network addresses are not hard-coded. Every workload that needs to connect to a service must specify the service network address as a variable. You can specify this variable by using the workload’s resource environment variable or in a config map.

  4. Service network addresses must match the following official regular expression pattern:

    (http(s)?://)?<svc>(.<ns>(.svc.cluster.local)?)?(:<portNum>)? (1)
    1 In this pattern,

    • <svc> is the service name.

    • <ns> is the namespace where you defined the service.

    • <portNum> is the exposed service port number.

    Following are some examples that match the pattern:

    • wordpress-mysql:3306

    • redis-follower.redis.svc.cluster.local:6379

    • redis-leader.redis

    • http://rating-service.

Procedure

  1. Verify that the build-time network policy generation feature is available by running the help command:

    $ roxctl generate netpol -h

  2. Generate the policies by using the generate netpol command:

    $ roxctl generate netpol <folder-path> (1)
    1 Specify the path of the folder that has the Kubernetes manifests.

The roxctl generate netpol command supports the following options:

Option

Description

-h, --help

View the help text for the netpol command.

-d, --output-dir <dir>

Save the generated policies into a target folder. One file per policy.

-f, --output-file <filename>

Save and merge the generated policies into a single YAML file.

--fail

Fail on the first encountered error. The default value is false.

--remove

Remove the output path if it already exist.

--strict

Treat warnings as errors. The default value is false.

After generating the policies, you must inspect them for completeness and accuracy, in case any relevant network address was not specified as expected in the YAML files. Most importantly, verify that required connections are not blocked by the isolating policies. To help with this inspection, you can use RHACS to simulate the generated network policies .

Red Hat recommends applying network policies to the cluster as part of the workload deployment using automation. You can follow a GitOps approach by submitting the generated policies using Pull Requests, providing the team an opportunity to review the policies before deploying them as part of the pipeline.

About network baselining in the network graph (2.0 preview)

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

When you install RHACS, there is no default network baseline. As RHACS discovers network flows, it creates a baseline and then it adds all discovered network flows to it, following these guidelines:

  • When RHACS 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, the following actions occur:

  • RHACS stops adding network flows to the network baselines.

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

Using network baselining

In RHACS, you can minimize your risks by using network baselining. It is a proactive approach to keep your infrastructure secure. RHACS 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 RHACS, 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, following these guidelines:

  • When RHACS 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, the following actions occur:

  • RHACS stops adding network flows to the network baselines.

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

Viewing network baselines from the network graph (2.0 preview)

You can view network baselines from the network graph view.

Procedure

  1. Click the Namespace list and use the search field to locate a namespace or select individual namespaces.

  2. Click the Deployments list and use the search field to locate a deployment or select individual deployments to display in the network graph.

  3. In the network graph, click on a deployment to view the information panel.

  4. Select the Baseline tab. Use the filter by entity name field to further restrict the flows that are displayed.

  5. Optional: You can mark baseline flows as anomalous by performing one of the following actions:

    • Select an individual entity, and then click kebab and select Mark as anomalous.

    • Select multiple entities, and then click Bulk actions and select Mark as anomalous.

  6. Optional: Check the box to exclude ports and protocols.

  7. Optional: To save the baseline as a network policy YAML file, click Download baseline as network policy.

Viewing network baselines from the network graph (1.0)

You can view network baselines from the network graph view.

Procedure

  1. In the network graph, select one or more namespaces.

  2. Select a deployment.

    The Network Flow details panel shows both anomalous and baseline flows.

  3. Perform one of the following actions:

    • 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.

Downloading network baselines from the network graph (2.0 preview)

You can download network baselines as YAML files from the network graph view.

Procedure

  1. In the RHACS web portal, navigate to Network Graph (2.0 preview).

  2. Click the Namespace list and use the search field to locate a namespace or select individual namespaces.

  3. Click the Deployments list and use the search field to locate a deployment or select individual deployments to display in the network graph.

  4. In the network graph, click on a deployment to view the information panel.

  5. The Baseline tab lists the baseline flows. Use the filter by entity name field to further restrict the list of flows.

  6. Optional: Check the box to exclude ports and protocols.

  7. Click Download baseline as network policy.

Enabling alerts on baseline violations in the network graph (2.0 preview)

You can configure RHACS to detect anomalous network flows and trigger violations for traffic that is not in the baseline. This can help you determine if the network contains unwanted traffic before you block traffic with a network policy.

Procedure

  1. Click the Namespace list and use the search field to locate a namespace or select individual namespaces.

  2. Click the Deployments list and use the search field to locate a deployment or select individual deployments to display in the network graph.

  3. In the network graph, click on a deployment to view the information panel.

  4. In the Baseline tab, you can view baseline flows. Use the filter by entity name field to further restrict the flows that are displayed.

  5. Toggle the Alert on baseline violations option.

    • After you toggle the Alert on baseline violations option, anomalous network flows trigger violations.

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

Enabling alerts on baseline violations in the network graph (1.0)

You can configure RHACS to detect anomalous network flows and trigger violations.

You need RHACS version 3.0.56 or newer to enable alerts on baseline violations.
Procedure

  1. In the network graph, select a deployment.

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

  3. Toggle the Alert on baseline violations option.

    • After you toggle the Alert on baseline violations option, anomalous network flows trigger violations.

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

Configuring network baselining time frame

You can use the ROX_NETWORK_BASELINE_OBSERVATION_PERIOD and the ROX_BASELINE_GENERATION_DURATION environment variables to configure the observation period and the network baseline generation duration.

Procedure

  • Set the ROX_NETWORK_BASELINE_OBSERVATION_PERIOD and the ROX_BASELINE_GENERATION_DURATION environment variables:

    $ oc -n stackrox set env deploy/central \ (1)
  ROX_NETWORK_BASELINE_OBSERVATION_PERIOD=<value> (2)
    1 If you use Kubernetes, enter kubectl instead of oc.
    2 Value must be time units, for example: 300ms, -1.5h, or 2h45m. Valid time units are ns, us or µs, ms, s, m, h. 
    $ oc -n stackrox set env deploy/central \ (1)
  ROX_BASELINE_GENERATION_DURATION=<value> (2)
    1 If you use Kubernetes, enter kubectl instead of oc.
    2 Value must be time units, for example: 300ms, -1.5h, or 2h45m. Valid time units are ns, us or µs, ms, s, m, h.