Network Graph 2.0 (TP)
|Network Graph 2.0 is in Technology Preview and will replace Network Graph.|
The Network Graph is a flow diagram, firewall diagram, and firewall rule builder in one.
In the upper left you’ll see the dropdown for clusters so I can easily navigate between any of the clusters that are connected to RHACS.
The default view, Active, shows me actual traffic for the Past Hour between the deployments in all of the namespaces.
You can change the time frame in the upper right dropdown, and the legend at bottom left
Zoom in on Backend Namespace
As we zoom in, the namespace boxes show the individual deployment names
Clicking on a deployment brings up details of the types of traffic observed including source or destination and ports.
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.
Let’s switch the view from active connections to the firewall view - Allowed.
This allows us to quickly see the disconnect between what we’ve actually seen happening, versus the wide-open view we see here
The red dots indicate an unrestricted deployment that is an open network.
The dashed lines indicate a namespace with no restrictions on egress and in conflict with best practices required under several compliance standards.
Click on Network Policy Simulator button in the top right
The Network Policy Simulator is designed to help solve this problem by using the history of observed traffic to build firewall rules. Click on Generate and Simulate
You’ll notice, though, that the firewall rules we’re generating are not proprietary rules, but OpenShift-native Network Policy objects. This feature, more than any other, illustrates the philosophy that RHACS represents: Security through platform-native features, with fixes supplied as configuration for OpenShift.
By implementing stronger security through declarative code we believe this avoids the anti-pattern of having configuration rules in a separate system - this code becomes part of your application, ensuring the consistency of “single source of truth” from your codebase.
This approach also reduces operational risk since there is no proprietary firewall in your cluster or in your pods that could fail, causing an application outage. RHACS is leveraging the firewall that’s already in your OpenShift cluster.
You’ll see this approach - “fix it in the code,” “leverage the platform,” - everywhere throughout the product - and we’ll take a look at what those policies look like, with examples of policy violations.