DevSecOps in Practice

Security Policy as Code (SPaC): Shifting Security Left

Shifting security left integrates security early in development. It is central to DevOps, DevSecOps, and Cloud Native practices. However, implementation can be complex. Poor execution may cause friction between security and development teams, slowing progress. NeuVector's Security Policy as Code (SPaC) feature helps by defining security policies in code. These policies can be shared with developers to guarantee security is embedded in development, CI/CD pipelines, and testing.

Previously, we explored how NeuVector enforces security with Discover, Monitor, and Protect modes. SPaC allows defining these policies declaratively in YAML files. For example, after deploying the RestQR application (the 2 microservices and the PostgreSQL database), we tested the application and observed its behavior. NeuVector learned the network, process, and file activities and created rules based on these observations. We can manually add new rules, review the learned rules, or deploy new rules via the alert messages and then export these rules to a YAML file representing the security policy in a CRD object (NvSecurityRule).

To export policies via the UI:

1. Navigate to the Groups tab.
2. Select the group containing the rules.
3. Click Export Group Policy.
4. Choose the mode (Discover, Monitor, or Protect).
5. Click Submit.

This generates an NvSecurityRule CRD manifest for use in enforcing consistent security policies. Below is a simplified example of a security policy:

apiVersion: v1
kind: List
items:
    # API version for NeuVector CRDs
  - apiVersion: neuvector.com/v1  
    # Kind of object representing a security rule in NeuVector
    kind: NvSecurityRule
    metadata:      
      # Name of the rule; typically matches the group name
      name: nv.menu.default             
    spec:
      # Data Loss Prevention (DLP) settings
      dlp:
        settings: []
        status: true
      # Outbound traffic rules (Egress) configuration
      egress:
        # First egress rule allows PostgreSQL communication
        - action: allow
          applications:
            # The application associated with this rule
            - PostgreSQL         
          # Name of the egress rule
          name: nv.menu-postgresql.default-egress-0  
          # Specifies that the rule applies to all ports
          ports: any             
          # Rule priority (lower number means higher priority)
          priority: 0            
          selector:
            # Criteria to match traffic for this rule
            criteria:            
              - key: service
                op: =
                value: menu-postgresql.default
              - key