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.

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:

Example

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

The two security engineers have been configured:

Let’s pretend “jsmith@demo.local” logs in to the NSX Manager UI and starts working on a new 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.