Well, the most secure system in the world is the one that none of us can access
Unfortunately, maybe for us we actually do need to allow our administrators access to manager in this case
Why do I say that's a little bit unfortunate?
Well manager is extremely powerful if we think about the how exactly it operates
It's pushing all of our configuration out to all of our edges out here that are forming all of our tunnels
So basically our entire SD-WAN environment. It's also passing configuration out to our
vSmarts or basically our I guess our controllers and our validators and
So all of our edges are out here and we understand that if the wrong person even if they don't have ill intentions
If they log into manager and execute some configurations that they shouldn't have done that could potentially cause
major outages in
the SD-WAN environment and
It would not take much effort in order to do that
Because if I wanted to not wanted to but if I were to accidentally make a bad
Configuration on one router in a traditional environment that might affect a site or two
But it's not going to affect the entire network and yet with SD-WAN manager
We understand that I could actually create a ton of problems if I were to perform the wrong
tasks inside of the UI
This is going to lead us to a conversation around authentication
Authentication is how we're going to make sure that only the right users have access
To manager and that's very important
I don't necessarily want my interns or people in the business department accessing manager. Okay, that makes sense
But that's just part of it because we might have a large team and this team could be very diverse
I could have a network administrator who needs to be pushing all of this configuration
Meanwhile, I could also have somebody on the NOC who really just needs to kind of see what's going on
And so we don't just want to control access. We also want to control permissions
We're talking about
permissions as far as what tasks
We can actually accomplish when we log into the UI
so Cisco has long had a great solution for managing not only access but also permissions and that would be
Privilege levels. No, I'm just kidding. Don't worry. It's not privilege levels
It's role-based access control, yeah privilege levels might have created a little bit of PTSD for those of us who
Had to configure permissions back before role-based access control
But that was old iOS now we live in the new iOS XE world
Our back has been around again for probably at least 10 years at this point probably 15 years
I'm probably older than I even think
But the idea here is this we're going to create a very modular architecture
For how we're going to manage our permissions. We want to make this as easy as possible
We don't want to mess up. We don't want our NOC engineers being able to push configuration at all
Let alone specific configurations like whether or not to reboot an edge or something like that
Instead we want the NOC to be able to have read-only access. Let's say
Then me as the admin. I want to be able to have full write access
But then we've got all these other users in the middle that are probably a little bit mixed
We might have some read-only. We might have some read-write and
Furthermore, we might even want to deny that somebody can even access a certain part of the user interface
So what's going to happen here at the heart of our role-based access control would be the role
So the role is going to define all of our permissions
This is how I'm going to control who has access to what I define my permissions and then I can create users
Who then have access to specific roles?
So maybe I've got a role up here that has one set of permissions
I've got this role. I've got that role and
Again these roles might be admin they might be NOC or whatever the situation is
And so as I create more users in the system
They all have a specific role that gives them the set of permissions that we want them to have again
It's modular. It allows us to scale this out to however many users and roles that we desire
Now here's some good news even better than the fact that this is modular and customizable
On top of that Cisco actually gives us some predefined roles and in a lot of organizations
In fact, there are five of these predefined roles if you studied SD WAN a long time ago
There were only three but Cisco has added a couple and so we'll just kind of go through these real quick and see that they
Do fit a lot of the needs of many organizations. So net admin
This is going to be the default role that we see given to the Cisco login
So net admin as we might imagine is going to be read and write on everything
Meanwhile we also have an operator role and
This is going to be read only but with access to everything
Now this is a key concept here and a lot of systems if we can't actually deny access to certain sections of a UI
So if I don't want you configuring a certain section based on the permissions in your role
You're still going to see that you're just not going to be able to make changes
Well with SD WAN I can actually deny access to certain parts of the UI and we will see that coming up
So net admin and operator
They truly have access to everything from a read write for net admin and a read only side of things for operator
We do also have basic now
This is where things start to get a little bit away from having access to everything. It is read only
but it's specific to
interfaces and
system configurations
so they can't even go look at things like policies and
Templates because it doesn't fit into this
Defined role that we've created
So it's truly a basic level of access and there are going to be some users that maybe are lower level
Engineers that we want them to be able to log in and take a look around and see what's going on
But we don't want them to see everything that's happening
Furthermore, we have a couple more here that these are the two that Cisco has added. We have network
operations and
operations
So once again, this is not going to allow them to see everything this is going to be a
Really a big mix and we'll take a quick look at this and in the UI
but there's going to be read write for some permissions read only for others and
Some things will just flat-out deny access to but it's kind of interesting when we really look at these predefined roles
This works for a lot of organizations and the good news is if we're like, hey, you know, this one's pretty close the operator
I want read only for most everything but there's a couple of things that I
I
Want to prevent them from accessing?
Well, I can perform a copy of this and I can create a custom role
From that or I can just create a custom role from scratch either way
I have the ability to give or create my roles with the permissions that I want for my organization
Now when we're defining a role, we're going to be able to divine our permissions and these permissions
Again are going to come down to three different options in the UI
We're going to see that we can mark it to be a read option
Mark it to be a right option
Or if we don't want them to even be able to see a particular option in the UI we can choose deny
Furthermore, we can also map permissions or map roles to VPNs or VPN
VPN segments or VPN groups, but either way if we map it to a VPN we will be able to
Make it so that a user is only able to control elements of that particular user VPN
So once we get these roles and these permissions defined we're going to apply it to a user and
The question is how do we find define these users? We have two main options
We do have a local user database that is stored on manager
So I'm gonna have to create every user myself and then map them to
Their roles now that's great and all except managing this for dozens of individuals can really be
Problematic and so if we only have three or four users then so be it
But what if I wanted to be more dynamic based on the role a user has in the organization when we have?
Hirings and firings well at that point as we can imagine we would want to have this tied to a server
and
Specifically Cisco does support tech X and radius as options for managing the user database
now there is one last element to all of this that we haven't discussed and that is the concept of the scope a
Scope is interesting. It's sort of an add-on to Cisco's traditional RBAC feature set because we don't see scopes
Outside of SD WAN or at least at this moment in time
to specific devices or specific
concepts
Granular there we go all right, so we're talking about specifically is
access or lack thereof to sites
to devices so maybe site 11 or edge 12 something like that and then also
Templates fits into this category
So sites devices and templates can be defined in a scope so at this point
We can create let's say a scope that says we're only allowed to access sites
12 and
14 so this would be a scope that we create and then users can point to the scope as well
So these permissions are filtered then through this scope so if I say you have read write options or read write
Access to creating let's say
Configuration on a pretend on edges well at that point
I'm only going to be able to you do that on edges at sites 12 and 14
Because the scope further filters things down and makes my control a little more granular
now note that there is a default scope and
The default scope is all so we don't have to worry too much about this if we don't need it
We can just apply the scope for all to our users
And then they can access all of the sites and devices and templates within this within the framework
I almost said the wrong word there within the framework of our roles, so this is how our back comes together
This is all of the technical terms and and predefined roles and everything
Let's go ahead and jump into the UI and see this in action