第 7 章 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 generator
  • Network policy simulator
  • Build-time network policy generator

7.1. Network graph

7.1.1. About the network graph

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

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:

Internal entities
These represent a connection between a deployment and an IP address that belongs to the private address space as defined in RFC 1918. For more information, see "Connections involving internal entities".
External entities
These represent a connection between a deployment and an IP address that does not belong to the private address space as defined in RFC 1918. For more information, see "External entities and connections 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.
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.
Network policies
You can view existing policies for a selected component or view components that have no policies. You can also simulate network policies from the network graph view. See "Simulating network policies from the network graph" for more information.

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.

7.1.1.3. Connections involving internal entities

The network graph is useful for identifying deployments with active connections to entities that do not belong to any known deployment or CIDR block. Some of these connections never reach outside of the cluster and are made within the cluster’s private network. The network graph represents those as connections to or from internal entities.

Connections with internal entities represent a connection between a deployment and an IP address that belongs to the private address space as defined in RFC 1918. In some cases, Sensor is unable to identify one or both deployments involved in a connection. In that case, the system analyzes the IP address and decides whether the connection is internal or external.

The following scenarios can lead to a connection being categorized as one involving internal entities:

  • A change of IP address or the deletion of a deployment accepting connections (the server) while the party initiating the connection (the client) still attempts to reach it
  • A deployment communicating with the orchestrator API
  • A deployment communicating using a networking CNI plugin, for example, Calico
  • A restart of Sensor, resulting in a reset of the mapping of IP addresses to past deployments, for example, when Sensor does not recognize the IP addresses of past entities or past IP addresses of existing entities
  • A connection that involves an entity not managed by the orchestrator (in some cases, that might be seen as outside of the cluster) but is using an IP address from the private address space as defined in RFC 1918

Internal entities are indicated with an icon as shown in the following graphic. Clicking on Internal entities shows the flows for these entities.

图 7.4. Internal entities example

Network graph showing internal entities

7.1.2. Access control and permissions

To view network graphs, the user must have at least the permissions granted to the Network Graph Viewer default permission set.

The following permissions are granted to the Network Graph Viewer permission set:

  • Read Deployment
  • Read NetworkGraph
  • Read NetworkPolicy

For more information, see "System permission sets" in the "Additional resources" section.

Additional resources

7.1.3. 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, go to Network Graph and select your cluster from the drop-down list.
  2. Click the Namespaces 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.

7.1.4. Viewing network policies in the network graph

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, go to Network Graph and select your cluster from the drop-down list.
  2. Click the Namespaces list and select individual namespaces, or use the search field to locate a namespace.
  3. Click the Deployments list and select individual deployments, or use the search field to locate a deployment.
  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 is 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.

7.1.5. Configuring CIDR blocks in the network graph

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, go to Network Graph, 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, and not only for the selected cluster 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.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部