Locking NSX-T Firewall Policies

After receiving a couple questions about the NSX-T firewall policy locking feature, I decided to write a short blog post about it.

The purpose of locking a firewall policy

The easy part first. As explained in the official NSX-T documentation we lock a firewall policy to prevent multiple users from editing the same section.

Locks could be short term like when a team is working in the NSX Manager firewall UI at the same time and want to avoid configuration collisions. Locks could also be long(er) term. For example when somebody is tasked with building a more complex firewall ruleset or when policies are subject to change management.

Let’s start locking then!

Here’s where it can get a bit confusing. While the option to lock a policy is always available, it won’t have any effect until you implement and use Role Based Access Control (RBAC) for NSX-T management. Why?

The default “admin” account, which is the only account you can work with in the NSX Manager UI without RBAC, has the “Enterprise Admin” role assigned to it. This superuser role has permission to make changes to firewall policies even when they are locked.

adding new rule in locked section as ea

So, if your team is using this default account (very bad practice) or individual accounts with the “Enterprise Admin” role assigned, you can lock firewall policies all you want, but these locks won’t have any actual effect.

Let’s fix this then!

Yes. As said this requires that we implement and use RBAC for NSX-T management first. There’s documentation available that will help you set this up so I won’t go through that in this article. On a high level the process looks like this:

  1. Deploy vIDM
  2. Connect vIDM to Active Directory
  3. Configure remote app access for the NSX Manager
  4. Configure NSX Manager to use vIDM for AAA

When that’s done we can start assigning NSX-T roles to Active Directory users:

role assignment

Example

In this example I’m assigning the “Security Engineer” role to two AD users:

The two security engineers have been configured:

security engineers

Let’s pretend “jsmith@demo.local” logs in to the NSX Manager UI and starts working on a new DFW policy:

john's dfw policy

When called into a meeting jsmith locks the policy he’s working on to prevent anybody from making changes:

Next, the other security engineer “pgroot@demo.local” logs in to the NSX Manager UI. She has a look at the new policy and decides to make a minor change to it. When she tries to publish the change the following message appears:

The change can’t be realized with her account. This is the expected and desired behaviour. The policy lock is enforced with RBAC implemented.

Summary

While most organizations have the RBAC components for NSX-T management in place (vIDM, AD, etc), actually leveraging NSX-T management roles so that things like locking firewall policies work is perhaps another thing. Hopefully this short article gave you some better understanding of how to get started.

2 Comments

  1. garyhills738
    Permalink

    Rutger,

    Another great article, good to know, thank you!

    Do you know if you’re able to use a vIDM account for NSX Manager CLI access, or it just UI and API access?

    Best Regards,
    Gary

    Like

    Reply
    • rutgerblom
      Permalink

      Thanks Gary,

      For CLI access you can only use the local appliance accounts (root or admin).

      Best regards.
      Rutger

      Like

      Reply

Leave a Reply to rutgerblom Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.