Lockdown DNS Without Slowing Down Processes

Even if you could lock down change permissions to a single DNS record, should you? In an enterprise network, the answer is most likely no. With our DDI solution, Micetro, though, we have an enterprise grade answer to this very problem with a solution called Workflow.

What Can You Lockdown With Micetro?

We’ve recently updated the Role Based Access Control model used in our new version of 10.1. For a full readout on that check out this blog. What I’d like to mention here is the real flexibility you get with RBAC on Micetro. We now have three categories of roles: General, Legacy, and Specific.

General – These are roles that are built-in to Micetro and may also be created by you. Anyone assigned these roles will have access (read-only or change) to system-wide objects. So, it might be admin privileges over everything, another role might give change permissions to DNS or DHCP system-wide. Another role will give read-only permission to IPAM for example.

Legacy – These are actually roles that have been created when a customer had been using prior versions of Micetro. In order to make everything continue to work in 10.1, we automated the creation of Legacy roles in 10.1 so that older configuration would continue to work.

Specific – These get much more flexible. These roles are created to give permissions to a single DHCP scope, an IP range, a DNS or DHCP server, or even user access configuration. However, these roles do not get granular enough to assign a role to a specific IP or DNS record.

Why Not Lockdown Permissions for a Single DNS Record?

I completely understand why my colleagues and I get asked the question about locking down permissions for a single record. I know there are use cases, where especially outside the DDI or network team, you’d want to give very granular permissions maybe to a server admin or a DevOps person. However, once you start pulling that thread it never stops.

Role Based Access Control is highly effective, but when you start creating that many granular roles, shortcuts will be taken. Of course, I’m not talking about you, dear reader, specifically. If you’re running an enterprise network, likely with multiple sites, maybe even in a multicloud environment, there are probably quite a few people in your IT organization. All of these people use DNS in one way or another and would love to cut the time it takes to request a DNS record, I’m sure.

We actually have one customer who has over 40,000 users from multiple IT teams on the Micetro platform. This is where RBAC, when used properly, shines. It’s just not sustainable to create roles for individual users or individual records. But this doesn’t solve your original issue, because you still have people waiting days or weeks to get a DNS record they requested or worse, they’re just going to use an IP instead. This is especially not sustainable because many times users outside the DDI team don’t understand the bigger picture and plan within a multicloud or multisite DDI architecture.

A Better Way: DNS Workflow

RBAC is one side of the coin, and the other side is a capability called Workflow. This is how we can solve that problem without creating dozens or hundreds of new roles. With Workflow users may be given the ability to easily request a DNS change or new record in Workflow. So, this means that a user, perhaps a server admin, could be given request permissions either system-wide using a General role, or to specific objects using Specific roles. Then it goes in a queue to be approved by a network engineer with approval permissions and a more contextual view of the whole system.

Upon approval or rejection of this request, the engineer may put comments in on why it was approved or rejected, and then will decide whether to implement the change immediately or put it in a Schedule queue with other approved requests to be implemented automatically during a change management window. The IP and DNS record will be Held (not available for others’ use) even while it’s still just in the Schedule queue. A history of all of this will also be retained in case of any issues or auditing logs that may be necessary down the road.

Making This Self-Service

So, of course, Workflow is available via the GUI, but other folks may not have the time to get the training to do all of this. Creating a self-service portal that plugs into the APIs of Micetro is likely the best way to go about making it easy for everyone and Men&Mice can help you with this! Creating a self-service portal will reduce the ticket times as well as the frustration of having to create and watch tickets. The process can be standardized to give all the pertinent information, and with just a couple clicks to approve, the process can go from taking weeks to taking hours or minutes. The rest of your larger team will appreciate the reduction in time-to-market for their apps and services as well as the information of when the request will go through.

For a live demo of how this works go to https://menandmice.com/live-demo.