Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/02.deploying/01.production/03.details/03.details.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,9 @@ slug: /deploying/production/details
* CUSTOM_CHECK_CONTROL
> (Optional) Used to enable/disable ability to create custom compliance scripts in containers/hosts. Values are "disable" (default, not allowed), "strict" (admin role only), or "loose" (admin, compliance, and runtime-policy roles).

* NV_ENABLE_CUSTOM_SVC_NAME
> (Optional) Set the value to "1" (or "true") to allow a workload to specify its NeuVector service/group via the `io.neuvector.service.name` label. Because the label is evaluated by both the controller and the enforcer, this variable must be set on **both** components. See [Overriding a Workload's Service](/policy/groups#overriding-a-workloads-service) for details.

* AUTO_PROFILE_COLLECT
> (Optional) Set value to 1 to enable collection of memory profile data to help investigate memory pressure issues.

Expand Down
23 changes: 23 additions & 0 deletions docs/05.policy/04.groups/04.groups.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,29 @@ After saving a new group, NeuVector will display the members in that group. Rule

Custom groups can support virtual host based address groups. This enables a use case where two different FQDN addresses are resolved to the same IP address, but different rules for each FQDN should be enforced. A new custom group with ‘address=vh:xxx.yyy’ can be created using the ‘vh:’ indicator to enable this protection. A network rule can then use the custom group as the ‘From’ source based on the virtual hostname (instead of resolved IP address) to enforce different rules for virtual hosts.

#### Overriding a Workload's Service

By default, NeuVector derives the service (and the corresponding learned group, prefixed with `nv.`) for each workload from orchestration metadata such as the deployment/pod name. A workload can override this derivation by setting the label `io.neuvector.service.name` on the container or pod. For example, a pod labeled `io.neuvector.service.name=myapp` in namespace `prod` is placed into the group `nv.myapp.prod` regardless of its pod name.

On Kubernetes the label value is lowercased and normalized to DNS-1123 form before use, so `io.neuvector.service.name=MyApp` results in the group `nv.myapp.prod`.

:::warning
Honoring this label is **disabled by default**. NeuVector ignores `io.neuvector.service.name` unless the feature is explicitly enabled.
:::

To enable it, set the environment variable `NV_ENABLE_CUSTOM_SVC_NAME` to `"1"` (or `"true"`) on **both** the Controller and the Enforcer. Both components evaluate the label, so setting it on only one leads to inconsistent group assignment. With the Helm chart, add the variable to the `controller.env` and `enforcer.env` passthrough lists in your values file:

```yaml
controller:
env:
- name: NV_ENABLE_CUSTOM_SVC_NAME
value: "true"
enforcer:
env:
- name: NV_ENABLE_CUSTOM_SVC_NAME
value: "true"
```

### Custom Group Examples

#### General Criteria
Expand Down
Loading