Custom Resources by neuvector.com

Core Security Policy CRDs

For examples of policy application, see Examples.

NvSecurityRule

NvSecurityRule defines security policies that apply to workloads within a specific namespace. These rules are scoped to the namespace where they are deployed and can only affect targets within that namespace:

• Namespace-scoped enforcement.
• Network ingress/egress rules.
• Process and file access controls.
• DLP and WAF policy integration.

Reference

NvClusterSecurityRule

NvClusterSecurityRule defines security policies that apply across the entire cluster, regardless of namespace boundaries. These rules are ideal for enforcing global security standards and baseline protections:

• Cluster-wide enforcement.
• Global security baselines.
• Cross-namespace policy management.
• Federated policy support.

Reference

NvGroupDefinition

NvGroupDefinition allows you to define reusable group criteria that can be referenced by security rules. This promotes modularity and consistency across policies:

• Reusable group definitions.
• Centralized group management.
• Name referral support.
• Simplified policy maintenance.

Reference

Admission Control CRDs

NvAdmissionControlSecurityRule

NvAdmissionControlSecurityRule defines admission control policies that validate and potentially block workload deployments based on security criteria:

• Admission control integration.
• Workload validation rules.
• Deployment-time security enforcement.
• Compliance checking.

Reference

Specialized Security CRDs

NvDlpSecurityRule

NvDlpSecurityRule defines data protection policies to prevent sensitive data leakage and enforce data handling compliance:

• Sensitive data detection.
• Data loss prevention.
• Compliance enforcement.
• Custom pattern matching.

NvComplianceProfile

NvComplianceProfile defines compliance standards and scanning configurations for regulatory and security framework adherence:

• Compliance standard definitions.
• Automated scanning.
• Reporting configurations.
• Custom compliance checks.

NvVulnerabilityProfile

NvVulnerabilityProfile defines vulnerability assessment policies and risk management configurations:

• Vulnerability scanning policies.
• Risk assessment rules.
• Remediation workflows.
• Custom vulnerability criteria.

NvWafSecurityRule

NvWafSecurityRule defines web application protection rules and traffic filtering policies:

• Web application protection.
• Traffic filtering rules.
• Attack pattern detection.
• Custom WAF rules.

NvResponseRuleSecurityRule

NvResponseRuleSecurityRule declares what NeuVector does when an event it is watching occurs. The resource is cluster-scoped and carries a single rule.

Unlike the resources above, it selects no workloads: the rule matches events, not groups. Specify which event to react to in rule.event, narrow it down with rule.conditions, and list what to do in rule.actions.

apiVersion: neuvector.com/v1
kind: NvResponseRuleSecurityRule
metadata:
  name: quarantine-critical
spec:
  rule:
    policy_name: default
    event: security-event
    conditions:
      - type: level
        value: Critical
    actions:
      - quarantine
      - webhook
    webhooks:
      - <WEBHOOK_NAME>
    comment: Quarantine the workload and notify on a critical security event

The parameters of rule:

• policy_name — the policy the rule belongs to. The only accepted value is default.
• event — the event to react to: event, security-event, cve-report, compliance or admission-control.
• conditions — the conditions that narrow the event down. Each carries a type and a value. An empty list matches every event of the chosen type.
• actions — what to do, at least one of quarantine, suppress-log or webhook.
• webhooks — the webhooks to call. Required by the webhook action.
• disable — turns the rule off without deleting it.
• comment — a free-form description.

NvSecurityRule and NvClusterSecurityRule accept the same rules in their response section, where they apply to the workloads the policy targets instead of to the whole cluster. The section takes a list of rules of the shape above, minus the admission-control event, which has no workload to attach to:

spec:
  target:
    policymode: Monitor
    selector:
      name: group-name
  response:
    - policy_name: default
      event: cve-report
      conditions:
        - type: cve-high-count
          value: "10"
      actions:
        - suppress-log

Setting up security policies

To apply security policies, you must specify the target parameters (target), the mode of operation, and the corresponding rules. The key elements of the specification and examples of their use are described below.

Target Specification

All security rules require a target specification that defines which workloads the policy applies to:

target:
  policymode: Protect  # Possible values: Discover, Monitor, Protect
  selector:
    name: group-name
    criteria:
      - key: service
        value: service-name
        op: "="
      - key: domain
        value: namespace
        op: "="

here:

• criteria is a set of conditions (criteria) by which the policy is applied to certain objects: pods, containers, services, etc.
• policy modes:
  • Discover — learn and log all activities without enforcement.
  • Monitor — log policy violations but allow traffic.
  • Protect — actively block policy violations.

For more information on policy modes, see the section “Readme”

Network Rules

Network rules control ingress and egress traffic:

ingress:
  - action: allow|deny
    name: rule-name
    selector:
      name: source-group
      criteria:
        - key: selector-key
          value: selector-value
          op: operator
    ports: "tcp/80,tcp/443"
    applications: ["HTTP", "SSL"]
    priority: 0

Supported applications: HTTP, SSL, PostgreSQL, Redis, SSH, Kafka, MongoDB, MySQL and others.

Process Rules

Process rules control which processes can execute:

process:
  - action: allow|deny
    name: process-name
    path: /path/to/process
    allow_update: true|false

File Access Rules

File access rules control filesystem operations:

file:
  - behavior: monitor_change|block_access
    filter: /path/to/file/or/directory
    recursive: true|false
    app: ["allowed-applications"]

Process Profiles

Process profiles define behavioral baselines:

process_profile:
  baseline: default|shield|basic|zero-drift
  mode: Discover|Monitor|Protect

Selector Operators

CRD selectors support various operators for flexible matching:

Name Referral

Use the name_referral attribute to reference group definitions:

selector:
  name: predefined-group
  name_referral: true
  # Criteria will be ignored and looked up from NvGroupDefinition.

Naming Conventions

• Use descriptive rule names: web-to-database-access.
• Follow consistent group naming: nv.service.namespace.
• Avoid reserved prefixes: fed., nv.ip., host:, workload:.
• Names must match the pattern: ^[a-zA-Z0-9]+[.:a-zA-Z0-9_-]*$.