NeuVector Groups type and their interaction with CRDs and Policy Modes

• Product: SUSE NeuVector v5.x.
• Feature: NeuVector CRD for Policy As Code
• Target: Security Policies
• Capability: Understand how CRDs interact with group types in NeuVector UI

NeuVector uses groups to visualize and manage network, process, and file rules. Within each group, it is possible to create numerous functionalities, either manual or automated, for the rules that must be applied to the members of each group. There are four types of groups:

User-created: Groups created by users via UI or Neuvector REST API (Manager).

Learned: Groups are learned automatically by NeuVector. After installing NeuVector, it will check your cluster and create Learned groups based on your applications. The discovery methodology can also be applied to this to learn more about your application behavior.

CRD: Groups created and applied through CRDs manually via kubectl or through automation.

Federated: Global groups applied to federated domains (master + managed(s) cluster(s) group).

For example, if you like to automate as much as possible to keep the rules of your group equivalent and apply quickly, CRDs will meet your scenario. If you prefer to make maximum use of NeuVector's learning capabilities and want to perform actions via NeuVector's UI, customizing Learned groups will meet your scenario.

For federated groups, the rules will always show at the top of the list, thus taking precedence over other rules. Other rules, such as Admission Control, Response, Process, and File, will behave in the same way, each group type has its own ordering priority.

The distinction between CRD and user-created is the way they are entered. Either through Kubernetes(kubectl and the tool using it) or NeuVector (UI, API REST).

Custom Resource Definitions are ways you can automate the creation of rules in your environment, with a view to standardization and easier management, exclusively for CRD files applied manually by the Command line or Automation Pipeline. You can create specific groups using CRDs and insert all the necessary rules.

Each type of group has its own priority/ordering, this means that if a new network rule has the same priority value as an existing network rule, the new network rule entry will appear before the existing network rule entry in the list of rule/UI headers, which will lead to the group being classified as CRD because CRD has preference over all groups except Federated.

1. If you apply a rule created by CRD (this can come from ArgoCD, Jenkins or a kubectl terminal) and that rule at some point references the "nodes" or "external" group, the general status of that group will be changed to CRD because custom rules have been created and they are interacting with these groups. This explains the change in these groups with your changes to allow ingresses to the "nodes" group. ). 

2. If you have a Learned group, you can change the policy modes from the UI. But if, at some point, that same group has a rule applied by CRD, the type will be changed to CRD, and changing the policy by UI will no longer be possible.

3. As the "nodes" and "external" groups are addressed and customized from the groups you have, they are constantly being modified. The customized groups address network rules involving the "nodes" and "external" groups. When this happens, a CRD is applied, so these groups' types are changed to CRD. Currently, the policy mode for these groups can only be changed by CRD.

4. In practice, if you create a CRD with a service that communicates externally, this CRD will have an affinity with the "external" group, and consequently, this group will be changed to CRD type. When this is applied, it will not be possible to change the Policy Mode of this group via the NeuVector UI, as the owner will now be the CRD. The rules created automatically are maintained, but whenever there is an affinity for a CRD, that CRD will be the group's owner. If you remove the CRD, the group returns to the Learned state.

5. The CRD import behavior ignores the PolicyMode of any 'linked' group, leaving the Policy mode unchanged if the linked group already exists. If the linked group does not exist, it will be automatically created and set to the default New Services Mode.