SUSE Support

Here When You Need Us

NeuVector Groups type and their interaction with CRDs and Policy Modes

This document (000021394) is provided subject to the disclaimer at the end of this document.


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


NeuVector has a product definition to allow better coverage of CRDs, this definition says that when a group is created per CRD or that group is related to other groups in that CRD, only the CRD file will have permission/right to change policy modes. The imported target policy mode is not allowed to be modified from the NeuVector console (Policy -> Groups). For example, once the mode is set to Monitor, it can only be changed through CRD modification, not through the console. When CRD is applied, it takes priority over other group types.

Additional Information

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.


This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000021394
  • Creation Date: 08-Mar-2024
  • Modified Date:11-Mar-2024

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.