[MUSIC]
>> You can use an NSG to control
traffic to one or more Virtual Machines,
network adapters or sub-nets
in your virtual network within Azure Stack.
An NSG contains access control rules that
allow or deny traffic based on traffic direction,
protocol, source address and port,
and destination address and port.
A single network identity group can be
associated to multiple network interfaces and sub-nets,
but each network interface or sub-net can be
associated to only one Network Security Group.
In Azure Stack, let's start with the user or tenant portal.
There are many ways that you can create
an NSG or Network Security Group and we'll
start with the simplest way first of just creating the NSG object.
If you notice on the left-hand side of the screen,
it does not appear initially.
But if I click on "More Services" and scroll down to
"Networking" we will see
here that there is an option for Network Security Groups.
In here, notice that the star is not highlighted,
if I simply click this,
you notice it adds it to the menu on the left-hand side.
So once I've done that,
I can then reorder my menu and move these icons wherever I like.
So now that we have
a simple Network Security Group object
let's start by creating one, and then we will
associate it to a NIC or
a sub-net, and then look
at various properties of the Network Security Group.
So we'll start by clicking the "Network Security Group".
You see I have a couple initially.
But we're going to create one from scratch.
So I click the "Add" button.
First of all, let's give it a name.
So we could have a whole discussion on naming conventions.
That's something very important
particularly for automation and scripting.
But for this purpose we'll keep it very simple and we'll just
call it NSG2 since I already have an NSG1.
So you can put it in a new resource group or use an existing one,
I like to group things according to their object type.
So in this case, you see I have two resource groups one for
networks and one for virtual machines to keep them organized.
So I'll select "Networks" since I want to
associate this with my network objects.
Location for now in Azure Stack,
we only have one which can be renamed but this is
the local or single instance if you have
deployed Azure Stack Integrated System
currently for the middle of calendar year 2018,
we just have one region,
as we move forward in the future,
you will have options to make more regions.
So I'll go ahead and click "Create."
It's validating it to make sure that I didn't have any errors.
I didn't have any duplicate things.
It says deployment in progress here,
so I'll go ahead and click "Refresh" and there it is.
So now I can click on the NSG.
We can take a look at the basic properties.
As we mentioned, there's some default rules for
"Inbound Security Rules" or "Outbound Security Rules."
So we have "Allow VNet
In Bound" from any port any protocol by default.
We have "Azure Load
Balancing Access Rules" and we have "Deny All Inbound."
We also have some outbound security rules
that we can look at too as well.
In the NSG, we have "Activity Logs"
and as we create these
and we can see what operations have happened.
So in this case,
there is a "Write Network Security Group" operation
that was succeeded because I just completed that.
We also have "Access Control" or
"Identity and Access Management" by default.
So when we create NSG's just like any resource in Azure,
we can assign people rights
to create these or write them or delete them.
You notice by default all objects,
by default will get the subscription owner which is inherited.
But if we wanted to have say for example
only the network admins to have access rights to this,
we could create an Azure Stack.
We could create a custom role-based access control group
that may only have contributor rights.
But by default, we only get three owner, contributor,
and reader which these are across the entire subscription but we
could scope it to the network resources.
But as we drill down into here just to show you real quickly.
We go into the "Network Resource Provider"
you can go further down in here and
see these are all the rights that come with that.
As you see right here,
there are some default rules
associated with the RBAC or
Role-Based Access Controls for Network Security Group.
So what we could do is make a
custom RBAC rule just to cover these things.
Then as you see at the top,
we could give the ability to read, write,
delete or do other special actions on that.
But in this case, we're not going to change that
because it's efficient the way it is.
All right, so let's go back to my Network Security Groups,
back into NSG two.
So we looked at Access Control.
We also have the ability to tag these,
but we can make one for example,
a common tag I like to have is for "Environment."
So I can give it,
so it's a name value pair.
So I could give this a value of "Production" and save that.
Likewise, I could take
all my other resources that I
create either in the portal or programmatically
and give them also
a production environment tag and we could use that
to sort and filter or use it to slice and dice for billing.
Within the NSG, we can look at settings for "Inbound"
and "Outbound Security Rules" so when we click on this,
there's a default rules option up here.
So if I click it hides them.
But by default, it did show those rules as we looked at.
Likewise, there's outbound.
So if I wanted to add something on
here you notice the priorities are very high.
So think of that as a cost in an access control list.
If you make something else and you want
it to override that default,
you just make it a lower priority which is a lower cost and
lower cost has higher precedence
and it would override those rules.
So let's take a look at how that works.
So different ways you can set this.
So this is an inbound security rule.
By default, it says "Any" source.
But I can also do by IP address specifically.
So if I had a particular virtual machine I
wanted to talk to
this network security group only or from a load balancer,
or I can use a service tag.
So service tags are predefined options.
So I can say let's use a source tag for Internet, VirtualNetwork,
or AzureLoadBalancer, and it does
all the work for me and I don't have to figure it out that way.
Likewise, we can change source port range and you
can do these with comma-separated values for different things.
So for example, if I had
SQL Server and I want to have 1433 and 1434,
I just put a comma between them or I could put
a range with a hyphen in there as well.
Then I can look at the destination.
So if this was a three-tiered application and this was
the front end and I want the destination to go to the back end,
I could have it point to an IP address in the middle tier,
or the back end tier,
or another virtual network within that hierarchy.
Again, you can get real specific with protocols for Any,
for TCP, or UDP.
Then you have two actions: Allow or Deny based on that,
then give it a name and a description.
So that's an example and it works
the same way for outbound security rules.
You'll also see here network interfaces.
So in this case, it's kind of interesting.
We made an NSG that's not attached to anything.
So there are really fundamentally two ways,
really three ways that you can add NSG.
So if I didn't create it from scratch,
and I'll go back and show this in a minute.
I can add an existing NSG or
actually create an NSG during VM creation time.
But when I do that,
it really is not attached to the VM but it's attached to
either the "Network interface" or the "Subnet".
So in the old days,
a couple of years ago, in Azure,
when we had ASM model or Azure Service Manager,
you could associate it to a virtual machine but in ARM model,
which is what right now the Azure Resource Manager model.
You associate NSGs with the network interface or the subnet.
So in this case,
I'm going to take a network interface and
associate this network interface.
So I had to have some network interfaces in the first place,
which I did and you see.
So any of these that I have selected are created in advance,
I simply click on that and it's going to associate
that network security group
with that particular network interface.
Now as a rule of thumb,
that's probably not the normal way that I would do this.
I would more likely set these at the subnet.
So in this case, just to show that we can do this,
I'm going to say "Disassociate".
So I'm not deleting
the NSG nor am I deleting the network interface,
I'm just breaking the connection between these.
Because as a rule of thumb,
we'd like to apply NSGs at a subnet.
The reason why is because it's like
a cookie cutter approach that we can apply to multiple servers.
So if I have three web front end servers and
they all have the same rules and requirements,
we can simply take that NSG,
apply it to the subnet,
and then therefore all those virtual machines within
that subnet would get the effect of this.
So in this case, I can say "Associate"
and it's going to ask me to choose a virtual network,
and I have one in
my Azure subscription here in Azure Stack and the VNetHub.
Then within that, I actually have multiple subnets.
So I can select that, and then I click ''Okay.''
Now, I have associated this NSG with that subnet.
Finally are the "Properties",
this is very typical in all Azure resources.
We can see the specific resource ID,
and so what subscription is associated with,
what resource group, and this is
handy when you're doing ARM templates and scripting.
We see which resource group it's been placed in,
the Networks, my subscription name,
and the subscription ID.
Then finally, just like in
Azure Resource Manager with all resources,
we can have locks on it.
We can actually go up a level to
the resource group or the subscription and put a lock.
So in this case, I may want to do it for the entire resource here.
So I'll say lock name,
and I just want to show here so we'll just say TESTLOCK.
We have a couple of different lock types we can
do: a read-only or delete.
So I don't want people to delete these
and I can put notes about what this is for,
"do not delete", and click ''Okay''.
All right. Then finally, just to show you.
So we've created that but I also want to show real quickly.
If I went to an existing virtual machine,
which we have a couple here created.
So let's go to one machine here.
As we scroll down into "Networking",
then within networking, we have the network interface.
Again, on here, it says
right here we do not have any network security groups.
So what I can do is go onto
either the virtual network subnet or the network interface.
Again, like a best practice,
we want to go to the virtual network subnet.
We can click on ''Subnets.''
Then once I'm on the subnets,
I can pick one of these.
Here, so going into the subnet,
I can then select on NSG.
Note, even though I just created
an NSG and applied it somewhere else,
I can reuse that on this particular subnet as well.
There you have it. That's the way
to create network security groups within
the Azure portal by creating them all by
themselves or associating them to other objects.
I hope that helps you out. Thank you.
[MUSIC]