Automate NSX Security Policies with Ansible

NSX-T security policy automation turns firewall configuration into a repeatable, reviewable part of infrastructure delivery. Instead of creating distributed firewall rules manually in NSX Manager, an Ansible playbook can define groups, policies, rules, logging, and enforcement behaviour as code.

This approach suits VMware administrators managing private clouds, Kubernetes clusters, and hybrid environments across Australia. It also gives teams a practical way to reduce configuration drift, standardise change control, and recover quickly when a policy must be rebuilt.

Approach	Manual NSX Manager Changes	Ansible-Based Automation
Consistency	Depends on operator habits	Defined in version-controlled files
Change review	Limited audit context	Pull requests and peer review
Reuse	Policies are copied manually	Variables and templates support reuse
Recovery	Requires reconstruction	Playbooks can recreate configuration
Scaling	Slows as environments grow	Suitable for multiple clusters and sites

Designing Repeatable Policy Definitions

Begin with the security intent rather than the NSX interface. Define which applications need to communicate, which ports are required, and where traffic must be denied. A three-tier application might have web servers accepting HTTPS from a load balancer, application servers accepting traffic from the web tier, and databases accepting only the required application connections.

Represent those decisions in YAML variables. Keep environment-specific values, such as segment names, IP sets, and tags, separate from the policy logic. This allows the same playbook to support a Melbourne production site, a Sydney disaster recovery environment, and a smaller Brisbane lab without duplicating every task.

A Git workflow makes the process auditable. Teams can use a Git repository guide to establish branches, commit conventions, and review practices before security changes reach production. A pull request then records why a rule changed, who approved it, and when it was applied.

Preparing Ansible And NSX Manager

Install Ansible on a controlled administration host or automation runner with network access to NSX Manager. Store credentials in Ansible Vault or an external secrets platform, never directly in a playbook. Use service accounts with the smallest practical permissions, and separate development, staging, and production credentials.

The VMware Ansible collection can provide NSX-specific modules, while Ansible’s uri module offers a flexible fallback for policy endpoints supported by the NSX-T API. Check the collection version against the NSX release in use, because module names, parameters, and API behaviour can vary between releases.

A basic inventory might identify each NSX Manager by environment:

all:
  children:
    nsx_production:
      hosts:
        nsx-manager-prod:
          ansible_host: 10.20.10.15
          nsx_validate_certs: true

For Australian organisations, certificate handling deserves particular attention. Internal certificate authorities are common in enterprise VMware estates, while regulated workloads may require clear evidence of where management credentials and automation logs are stored. Align the design with organisational data residency and Essential Eight practices.

Writing Safe Policy Automation

A policy task should be declarative and predictable. The following example uses the NSX Policy API through uri; the exact endpoint and payload should be verified against the deployed NSX version:

- name: Create application security policy
  hosts: nsx_production
  gather_facts: false
  vars:
    nsx_api: "https://{{ ansible_host }}"
    policy_id: "app-tier-policy"
  tasks:
    - name: Apply security policy
      ansible.builtin.uri:
        url: "{{ nsx_api }}/policy/api/v1/infra/domains/default/security-policies/{{ policy_id }}"
        method: PUT
        user: "{{ nsx_username }}"
        password: "{{ nsx_password }}"
        force_basic_auth: true
        validate_certs: "{{ nsx_validate_certs }}"
        body_format: json
        body:
          display_name: "Application Tier Policy"
          stateful: true
          category: "APPLICATION"
          rules:
            - display_name: "Allow HTTPS to application"
              source_groups: ["web-servers"]
              destination_groups: ["app-servers"]
              services: ["HTTPS"]
              action: "ALLOW"
              logged: true
              sequence_number: 10
        status_code: [200, 201]

Use stable object IDs and deterministic sequence numbers. Add tags or descriptions that identify the playbook, environment, and owning team. Logging should be enabled selectively: it is valuable during rollout and incident analysis, but excessive distributed firewall logging can increase storage and operational noise.

Kubernetes environments need a separate design conversation around namespaces, services, and workload identity. Before automating those controls, review this Kubernetes setup guide and decide whether NSX tags, security groups, or a complementary container networking policy should represent application boundaries.

Validating Changes And Drift

Run playbooks with --check where supported, then validate the resulting intent and realised state through the NSX Manager API. A successful HTTP response does not always prove that a rule is effective. Confirm that groups resolve the expected members, the policy is attached to the correct enforcement point, and traffic matches the intended rule.

Testing should include permitted and denied flows. For example, verify HTTPS from the load balancer to the application tier, confirm that database access is restricted to approved sources, and check that unwanted east-west traffic is rejected. In a lab, packet captures and test VMs can provide fast feedback before production rollout.

Schedule periodic read-only audits to detect drift caused by emergency GUI changes or other automation. Exporting the policy state and comparing it with the desired YAML can highlight differences. During an incident in an Australian environment, this evidence can also help teams coordinate across AEST and AWST support windows without relying on memory or screenshots.

Operating Automation In Australian Environments

Australian IT teams often manage a mixture of local data centres, public cloud services, and remote offices. A policy model that works in a Canberra government environment may need different naming, approval, and logging controls from a commercial VMware platform in Perth. Keep regional differences in inventory and variables rather than branching the entire playbook.

Plan for maintenance windows around business operations and financial-year change freezes. Teams in Sydney, Melbourne, and Adelaide may share a platform but have different application owners and support rosters. Clear ownership metadata in every rule makes escalation faster when a policy blocks a critical service.

• Use separate inventories for development, staging, and production.
• Store secrets in Vault or an approved enterprise secrets manager.
• Require peer review for allow rules and policy-category changes.
• Test both positive and negative traffic paths after deployment.
• Record NSX, Ansible, collection, and playbook versions for auditability.

Treat the automation repository as a production system. Protect its branches, run linting and syntax checks in CI, and restrict who can execute against production NSX Managers. A small home lab can validate module behaviour and API payloads before the same workflow is introduced into a large enterprise estate.

Build a small policy-as-code pilot around one application, commit it to version control, and validate it against a non-production NSX environment. Once the workflow is reliable, extend it to shared services, Kubernetes workloads, and disaster recovery sites with the same controlled process.