Terraform Provider for VMware NSX

The nsxt_vpc_group resource manages inventory Groups and their members within a VPC scope. These groups are commonly used as sources, destinations, or in the 'Applied To' field of firewall rules. This resource is compatible with NSX Policy Manager and requires NSX 9.0.0 or later.

To use this resource, you must provide a context block containing the project_id and vpc_id of the target VPC. Membership can be defined using various criteria blocks, such as IP addresses, MAC addresses, policy paths, external IDs, or attribute-based conditions (e.g., filtering by OS name or VM name).

data "nsxt_policy_project" "demoproj" {
  display_name = "demoproj"
}

data "nsxt_vpc" "demovpc" {
  context {
    project_id = data.nsxt_policy_project.demoproj.id
  }
  display_name = "vpc1"
}

resource "nsxt_vpc_group" "group1" {
  context {
    project_id = data.nsxt_policy_project.demoproj.id
    vpc_id     = data.nsxt_vpc.demovpc.id
  }

  display_name = "tf-group1"
  description  = "Terraform provisioned Group"

  criteria {
    condition {
      key         = "Name"
      member_type = "VirtualMachine"
      operator    = "STARTSWITH"
      value       = "public"
    }
    condition {
      key         = "OSName"
      member_type = "VirtualMachine"
      operator    = "CONTAINS"
      value       = "Ubuntu"
    }
  }
}

The nsxt_policy_idps_custom_signature resource allows you to define and manage custom Intrusion Detection and Prevention System (IDPS) detection rules using Snort syntax in NSX-T. These signatures are associated with a specific custom signature version (e.g., default).

Signatures are initially created in a preview (unpublished) state. To make a signature active in IDS/IPS policies, you must set the publish argument to true.

Note: This resource is applicable to NSX Policy Manager (NSX 4.2.0 onwards).

resource "nsxt_policy_idps_custom_signature" "malware" {
  signature_version_id = "default"
  signature            = "alert tcp any any -> any any (msg:\"Custom Malware\"; flow:to_server,established; content:\"malware_string\"; nocase; metadata:signature_severity Critical; classtype:trojan-activity; sid:5000001; rev:1;)"
  description          = "Custom malware detection rule"
  enable               = true
  publish              = false
}

The nsxt_policy_host_transport_node resource allows you to manage a Host Transport Node in NSX. This resource is supported on NSX 4.1.0 and later.

To configure a Host Transport Node, you must provide a display_name, a discovered_node_id, and a standard_host_switch specification.

resource "nsxt_policy_host_transport_node" "test" {
  description        = "Terraform-deployed host transport node"
  display_name       = "tf_host_transport_node"
  discovered_node_id = data.nsxt_discovered_node.dn.id

  standard_host_switch {
    host_switch_id = "50 0b 31 a4 b8 af 35 df-40 56 b6 f9 aa d3 ee 12"
    uplink_profile = data.nsxt_policy_uplink_host_switch_profile.uplink_host_switch_profile.path

    ip_assignment {
      assigned_by_dhcp = true
    }

    transport_zone_endpoint {
      transport_zone = data.nsxt_policy_transport_zone.overlay_transport_zone.path
    }

    uplink {
      uplink_name     = "uplink-1"
      vds_uplink_name = "uplink1"
    }

    uplink {
      uplink_name     = "uplink-2"
      vds_uplink_name = "uplink2"
    }
  }

  tag {
    scope = "app"
    tag   = "web"
  }
}

The nsxt_policy_predefined_gateway_policy resource allows you to fine-tune pre-created Gateway Security Policies and their associated rules. It is used for two primary purposes:

1. Modifying Default Policies: Adjusting settings for the default Gateway Policy and its default_rule (typically used in NSX Policy Manager).
2. Modifying Predefined Policies: Adding rules to predefined policies that are not in the DEFAULT category (common in VMC environments).

Important Implementation Notes

• Importing is Recommended: If you intend to reconfigure a policy from scratch, you should import the resource first. Terraform state is not aware of attributes or rules already configured on NSX. If you do not import and your configuration does not match the existing state, you may need to apply multiple times to sync.
• VMC Rule Persistence: VMC may auto-generate rules under the default gateway policy. To prevent Terraform from removing these rules, you must include them in your configuration using their exact nsx_id.
• NSX Versioning: In NSX 3.1.0 and above, a default policy is generated per Gateway. In versions 3.0.0 and below, there is a single default policy with default rules created per Gateway.
• Path Optimization: Providing an absolute path to the path argument is faster as it avoids the roundtrip required for data source retrieval.

# Example for NSX Policy Manager using a data source
data "nsxt_policy_gateway_policy" "default" {
  category = "Default"
}

resource "nsxt_policy_predefined_gateway_policy" "test" {
  path = data.nsxt_policy_gateway_policy.default.path

  tag {
    scope = "color"
    tag   = "orange"
  }

  default_rule {
    scope     = nsxt_policy_tier0_gateway.main.path
    logged    = true
    log_label = "orange default"
    action    = "ALLOW"
  }
}

The nsxt_policy_security_policy_rule resource allows you to manage individual Security Policy Rules in NSX Global Manager, NSX Policy Manager, or VMC.

Important Management Pattern

To avoid unexpected behavior and resource conflicts, do not use nsxt_policy_security_policy_rule and nsxt_policy_security_policy to manage the same rules simultaneously.

Instead, choose one of these two patterns:

1. Separate Management: Use nsxt_policy_security_policy_rule in conjunction with nsxt_policy_parent_security_policy to manage a security policy and its rules as distinct entities.
2. Unified Management: Use nsxt_policy_security_policy to manage both the security policy and all its contained rules within a single resource.

resource "nsxt_policy_security_policy_rule" "rule1" {
  display_name       = "rule1"
  description        = "Terraform provisioned Security Policy Rule"
  policy_path        = nsxt_policy_parent_security_policy.policy1.path
  sequence_number    = 1
  destination_groups = [nsxt_policy_group.cats.path, nsxt_policy_group.dogs.path]
  action             = "DROP"
  services           = [nsxt_policy_service.icmp.path]
  logged             = true
}

You can apply various filters to the nsxt_policy_baremetal_servers data source to narrow down the list of discovered servers:

• Tag-based filtering: Use tag_scope and tag for efficient server-side filtering.
• OS filtering: Use os_name or os_version for case-insensitive substring matches.
• Regex filtering: Use display_name to match server names against a regex pattern.
• Source filtering: Use source_id to filter by a specific bare metal controller ID.

# Filter by production environment using server-side tag filtering
data "nsxt_policy_baremetal_servers" "prod" {
  tag_scope = "environment"
  tag       = "production"
}

# Filter by OS name
data "nsxt_policy_baremetal_servers" "redhat" {
  os_name = "redhat"
}

# Filter by display name using regex
data "nsxt_policy_baremetal_servers" "web_servers" {
  display_name = "web-.*"
}

# Multiple filters combined
data "nsxt_policy_baremetal_servers" "prod_web" {
  display_name = "web-.*"
  tag_scope    = "environment"
  tag          = "production"
  os_name      = "ubuntu"
}

Instead of hard-coding group paths, you can use the output from association data sources to dynamically drive security policies. This allows you to create rules based on the existing group memberships of a specific server or interface.

For example, you can use data.nsxt_policy_baremetal_server_group_associations.bms_groups.groups[*].path to populate the source_groups field in a security policy rule, effectively allowing all groups that the target server currently belongs to to access a specific destination.

# Discover all groups the server is currently a member of
data "nsxt_policy_baremetal_server_group_associations" "bms_groups" {
  external_id = "71be0142-2ed1-1d53-9c60-5564cf4b7e2e"
}

# Allow the discovered groups to reach monitoring servers
resource "nsxt_policy_security_policy" "bms_monitoring_policy" {
  display_name = "BMS-Monitoring-Access"
  category     = "Application"

  rule {
    display_name       = "allow_bms_to_monitoring"
    source_groups      = data.nsxt_policy_baremetal_server_group_associations.bms_groups.groups[*].path
    destination_groups = [nsxt_policy_group.monitoring_servers.path]
    action             = "ALLOW"
    services           = [nsxt_policy_service.monitoring.path]
    sequence_number    = 100
  }
}