NeuVector Custom Resource Definitions (CRDs)

NeuVector provides a comprehensive set of Custom Resource Definitions (CRDs) that enable declarative security policy management through “Policy as Code” approach. These CRDs allow teams to define, version, and manage security policies alongside application deployments.

Overview

NeuVector CRDs enable you to:

  • Define security policies declaratively using Kubernetes-native resources
  • Version and track security policies alongside application code
  • Automate security policy deployment across multiple clusters
  • Implement GitOps workflows for security governance
  • Enforce consistent security policies in CI/CD pipelines

Supported CRDs

Core Security Policy CRDs

NvSecurityRule

Namespace-scoped security rules for application-specific policies.

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.

Key Features:

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

Example:

apiVersion: neuvector.com/v1
kind: NvSecurityRule
metadata:
  name: web-app-security
  namespace: production
spec:
  target:
    policymode: Protect
    selector:
      name: nv.web-app.production
      criteria:
        - key: service
          value: web-app.production
          op: "="
        - key: domain
          value: production
          op: "="
  ingress:
    - action: allow
      name: allow-http
      selector:
        name: ingress-controller
        criteria:
          - key: service
            value: nginx-ingress
            op: "="
      ports: tcp/80,tcp/443
      applications:
        - HTTP
        - SSL
  egress:
    - action: allow
      name: allow-database
      selector:
        name: nv.database.production
        criteria:
          - key: service
            value: database.production
            op: "="
      ports: tcp/5432
      applications:
        - PostgreSQL

NvClusterSecurityRule

Cluster-scoped security rules for global policies.

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.

Key Features:

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

Example:

apiVersion: neuvector.com/v1
kind: NvClusterSecurityRule
metadata:
  name: global-ssh-restriction
  namespace: neuvector
spec:
  target:
    selector:
      name: containers
      criteria:
        - key: container
          value: "*"
          op: "="
  ingress:
    - action: deny
      name: deny-external-ssh
      selector:
        name: external
        criteria: []
      ports: tcp/22
      applications:
        - SSH
  process:
    - action: deny
      name: ssh
      path: /bin/ssh

NvGroupDefinition

Group definition resource for modular policy management.

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

Key Features:

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

Example:

apiVersion: neuvector.com/v1
kind: NvGroupDefinition
metadata:
  name: production-web-services
  namespace: neuvector
spec:
  selector:
    name: nv.web-services.production
    comment: "Production web services group"
    criteria:
      - key: service
        value: web-services.production
        op: "="
      - key: domain
        value: production
        op: "="

Admission Control CRDs

NvAdmissionControlSecurityRule

Kubernetes admission control policies for workload validation.

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

Key Features:

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

Example:

apiVersion: neuvector.com/v1
kind: NvAdmissionControlSecurityRule
metadata:
  name: local
  namespace: neuvector
spec:
  config:
    enable: true
    mode: protect
    client_mode: service
  rules:
    - action: deny
      criteria:
        - name: namespace
          op: containsAny
          path: namespace
          value: "kube-system,kube-public"
      comment: "Block deployments to system namespaces"

Specialized Security CRDs

NvDlpSecurityRule

Data Loss Prevention (DLP) policies.

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

Key Features:

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

NvComplianceProfile

Compliance scanning and reporting configurations.

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

Key Features:

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

NvVulnerabilityProfile

Vulnerability scanning and management policies.

NvVulnerabilityProfile defines vulnerability assessment policies and risk management configurations.

Key Features:

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

NvWafSecurityRule

Web Application Firewall (WAF) policies.

NvWafSecurityRule defines web application protection rules and traffic filtering policies.

Key Features:

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

Policy Specification

Target Specification

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

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

Policy Modes:

  • Discover: Learn and log all activities without enforcement
  • Monitor: Log policy violations but allow traffic
  • Protect: Actively block policy violations

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:

  • ActiveMQ, Apache, Cassandra, Consul, CouchDB, DHCP, DNS
  • ElasticSearch, etcd, GRPC, HTTP, Kafka, Memcached, MongoDB
  • MySQL, nginx, PostgreSQL, RabbitMQ, Redis, SSH, SSL
  • And many more…

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:

Operator Description Example
= Exact match value: "web-app"
!= Not equal value: "test"
contains Contains substring value: "web"
prefix Starts with value: "app-"
regex Regular expression value: "^web-.*"
!regex Negative regex value: "^(?!test).*"

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

Best Practices

Policy Organization

  1. Use NvGroupDefinition for reusable groups:

    # Define once
apiVersion: neuvector.com/v1
kind: NvGroupDefinition
metadata:
  name: web-tier
spec:
  selector:
    name: nv.web-tier.production

  2. Leverage namespace-scoped rules for application policies:

    # Application-specific in namespace
apiVersion: neuvector.com/v1
kind: NvSecurityRule
metadata:
  name: app-security
  namespace: production

  3. Use cluster-scoped rules for global policies:

    # Global baseline security
apiVersion: neuvector.com/v1
kind: NvClusterSecurityRule
metadata:
  name: baseline-security

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:

Policy Validation

# Valid group name pattern
name: "^[a-zA-Z0-9]+[.:a-zA-Z0-9_-]*$"

# Service format for discovered groups
name: "nv.service-name.namespace"

Migration Strategy

  1. Export from staging:

    kubectl get nvsecurityrule -o yaml > staging-policies.yaml

  2. Modify for production:

    # Change policy mode
target:
  policymode: Protect  # was: Monitor

  3. Apply to production:

    kubectl apply -f production-policies.yaml

RBAC Integration

NeuVector CRDs integrate with Kubernetes RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: neuvector-policy-manager
rules:
- apiGroups: ["neuvector.com"]
  resources: ["nvsecurityrules", "nvclustersecurityrules"]
  verbs: ["get", "list", "create", "update", "delete"]

Namespace-scoped RBAC

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-policies
  namespace: development
subjects:
- kind: User
  name: dev-team-lead
roleRef:
  kind: ClusterRole
  name: neuvector-policy-manager

Troubleshooting

Common Issues

1. Policy import rejection:

Error: group criteria mismatch

Solution: Ensure group criteria match between source and destination.

2. Namespace boundary violations:

Error: cross-namespace policy creation denied

Solution: Use NvClusterSecurityRule for cross-namespace policies.

3. Invalid group names:

Error: invalid group name format

Solution: Follow naming convention: ^[a-zA-Z0-9]+[.:a-zA-Z0-9_-]*$

Validation Commands

# Validate CRD syntax
kubectl apply --dry-run=client -f policy.yaml

# Check policy status
kubectl get nvsecurityrule -n production

# View policy details
kubectl describe nvsecurityrule web-app-security -n production

# Check events for errors
kubectl get events -n neuvector | grep NeuVector

Debugging Policy Application

  1. Check controller logs:

    kubectl logs -n neuvector deployment/neuvector-controller-pod

  2. Verify group creation:

    # In NeuVector console: Policy -> Groups

  3. Review policy mode:

    # Ensure target group is in correct mode (Discover/Monitor/Protect)

Performance Considerations

  • Limit the number of concurrent CRD applications
  • Use batch operations for multiple policy updates
  • Monitor controller resource usage during policy updates
  • Implement gradual rollout for large policy changes

Integration Examples

GitOps Workflow

# .github/workflows/security-policies.yml
name: Deploy Security Policies
on:
  push:
    paths: ['policies/**']
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy policies
        run: kubectl apply -f policies/

CI/CD Pipeline Integration

#!/bin/bash
# validate-policies.sh
set -e

echo "Validating NeuVector policies..."
for policy in policies/*.yaml; do
  kubectl apply --dry-run=client -f "$policy"
done

echo "Applying policies to staging..."
kubectl apply -f policies/ --namespace=staging

echo "Running security tests..."
./run-security-tests.sh

echo "Promoting to production..."
kubectl apply -f policies/ --namespace=production

Additional Resources