>> Hey friends, if you have access to
the kubeconfig file for your AKS cluster,
you also have access to the API server to
create resources or scale the number of nodes,
and that API servers should only be accessible
from a limited set of IP address ranges.
So Ruchika is here to show us how to restrict
which IP addresses and Cidrs can access the control plane.
I'm learning how today on Azure Friday.
[MUSIC].
>> Hey friends, I'm Scott Hanselman and it's Azure Friday.
I'm here with Ruchika Gupta an engineer on AKS,
and you're going to show me how to make things more
secure with my API server on AKS.
>> Yes, that's right, Scott.
So by default, if anyone has your kubeconfig,
you can access your AKS cluster from anywhere.
Be it your office network,
your home, or even the Starbucks door near you.
>> Really? So by default,
that is the keys to the castle?
That config file allows you to do anything you want?
>> So that's right,
but that's not the only thing.
So you also have security from
Azure login and then you can have RBAC policies setup,
which will control your role-based access,
and then you can also use Azure AD for
only specific users to be able to access the API server.
>> So I'm hearing you say that this is about
a layered approach to security.
>> Yes, that is right. So it's
an additional security that you can add
to your AKS clusters with the existing securities that we have.
>> So there's Kubernetes security
and how Kubernetes manages things,
there's how the Azure RBAC
and your role-based access control system works,
and then there's the network level.
>> Yes, that's right.
So using this, you can specify
what IP ranges can have access to your AKS cluster.
You can specify only this network,
only my office network has access to these AKS clusters.
>> So I might not want someone at Starbucks doing this,
maybe I want just a virtual network
or a VPN'd in authorized users.
>> Yes, that's right. So generally,
your organizations want an additional level
of security where they say,
"These cluster should be accessible only
from my work IP addresses."
>> This is making sure that people don't even get
close to the actual control plane,
we nail them right when they come in?
>> Yes, that's right.
>> So you've got an AKS cluster already running right here?
>> Yes. So as you can see,
I have an Azure Friday resource group created,
and I have an Azure Friday Kubernetes cluster created on this.
>> So there's the research group.
>> Yeah, so here's the cluster.
Now we'll go ahead and get
the credentials for this cluster using AZ login.
So I've already done the AZ login and we'll go ahead and type in
AKS Get credentials and
specify the resource group and the resource name.
This will give you the kubeconfig file
and set it to the current context.
So once this is done,
you should be able to access
the API server using any kube control commands.
So just to give an example,
I'll do a Get nodes, this should succeed.
Yeah, so it returned you
the three nodes that this cluster currently has.
>> So if I can make sure I understand,
and this is a good reminder because I'm learning Kubernetes,
a lot of the people who are watching are learning Kubernetes,
Azure has APIs of its own at the Azure level,
the Azure Portal uses those APIs.
Then Kubernetes has this API server
and how Kubernetes talks to things.
When you're doing AZ-AKS,
you're talking to Azure.
But when you're using kube cuddle, kubectl,
you're not talking to Azure per se,
you're talking to the Kubernetes API server?
>> Yes, that is right.
So the control plane of your AKS cluster is the API server,
and which is the managed resource that Azure provides you.
So in order to talk to the API server,
you need to use the kube control commands.
>> That makes sense. It's good to remember and remind me
that AKS is just really Kubernetes,
it's just a managed Kubernetes system.
>> Yes, that's right. So we just provide you
the API server that you don't have to manage
anymore and you can make use of VMSS to scale your nodes,
and then you can use all the other network policies that
Azure provides in order to secure
your clusters and other Azure products,
in order to incorporate them with the existing clusters.
>> You said VMSS, Virtual Machine Scale Set?
>> Yes, that is right.
So you can use the VMSS as nodes to
your cluster if you want to scale them to 10,
or 50, or scale down to one.
So that's how it makes it easy.
>> So you just called it kube cuddle Get nodes.
We have three nodes running right now,
and we're just here at the office and they're available anywhere.
The IP address range is open.
>> Yes. So as you saw,
I just did a Get credentials and it was able to give me the nodes.
So if I go back to my Cloud Shell and use the same command,
we should expect a similar behavior because right now,
the API server is publicly accessible.
So I'll just use the same command.
I'll do an az aks get-credentials, specify.
>> Get escape. There we go.
>> Specify the resource group,
and specify the resource name,
which is our AKS cluster in this case.
This will give you the same kubeconfig file.
Once we have the kubeconfig file in context,
we can do our Get nodes
and this should return you the same set of nodes.
>> Proving that it is in fact available from everywhere because
a Cloud Shell runs in Azure on a totally different place,
it's not your local machine?
>> That is right. So if you look at
the IP address of my Cloud Shell,
it's this, and if you look at the local command prompt IP address,
it would be a different IP address.
>> Got you.
>> So if I do an Ipconfig.
>> Inside of Microsoft?
>> Yeah. So this has a different IP address.
So yeah.
I'll go ahead and update my AKS cluster
to now have access only from Cloud Shell IP.
So what I'll do is use
the az aks update command
and update the existing cluster that I have.
The additional parameter that's important here is
the API server authorized IP ranges,
which will actually restrict
access from the specified IP addresses.
So here I'll provide the IP address of my Cloud Shell.
As you can see, I have queried it in the query before.
So this will take a while for the command to run.
>> So at this point, az aks is calling
Azure APIs that are an extension to
the AKS because AZ is the Azure Cloud Shell CLI,
AKS is a sub-command,
and then this is the parameter API server
authorized IP address ranges.
You're not telling that to Kubernetes though,
this is the Azure Networking plane?
>> Yes, that is right. That's a very good question.
So this is all in the Azure VNet because
your API server is hosted in Azure subscriptions,
in Azure resource groups,
which are managed by the AKS severs.
>> Got you. You said it would take a little while to run.
What's happening when things take a little while,
like in this case, 10 or 20 seconds? What's really happening?
>> Yeah. So what we do is
your API server resides in our different VNnet,
which is inside AKS resource groups.
Essentially, we create our network security group rule,
specifying the source IP
address as the one that you specified in the command here,
and the destination IP address is the address of your API server.
So that way, it will restrict
network traffic only from these IP addresses to your API server,
and rest all would be blocked.
>> It's finished already right there,
and you can see it says PodCidr and ServiceCidr,
and it's got some ranges there and they're a little higher up.
There's your authorized IP address ranges.
>> Yes. So this is the thing that
got introduced as part of that command.
So as you can see,
the authorized IP ranges now has the IP address that I provided.
So if I go ahead and do a kube control get nodes,
we should expect that this command prompt has
access to the API server since we just whitelisted it.
So this should give me the same result as before.
Now, if I go ahead and type in the same command on
my local command prompt,
this should be restricted.
So sometimes it takes a little while for it to be
applied because these are the NSG rules that are getting applied.
>> The NSG, the network security groups?
>> Group rules that are getting applied.
>> So we can wait a minute and then just try again?
>> Yeah. So generally,
you can just get a coffee and come back.
>> Is this like propagation?
You know how they always say it's always DNS,
it's usually because something is propagating through the system.
>> Yes, that is true. Yeah. So while this updates,
I can just talk about all the options that you
have with your IP ranges parameter.
So like you see here,
I just provided one IP address.
In general, in production systems,
you have multiple IP addresses that you want to whitelist.
So you can provide
a comma separated list of IP addresses or you can also
provide a list of IP addresses using the Cidr notation.
>> That's the classless inter-domain routing,
and that's where you see the slash at the end of an IP address.
>> That's right. So slash 28.
So that will give you 16 IP addresses.
Also, if you want to provide access only from your AKS nodes,
you can specify 0.0.0/32.
>> Really?
>> So that will restrict all access from any public network.
Only your AKS nodes will be able to access the API server.
>> Could I hurt myself with this feature?
Could I accidentally lock myself out of my own system entirely?
>> Yes, you can. But you have a very easy way of turning it off.
So all you need to do is to do double-quotes.
So this will disable your feature.
>> I think you're going to disable it before we have it working.
>> No. So let's do it before. Let's just query.
>> So here's our failure, this is not going to work.
>> Yeah. So this should basically timeout
and we'll wait for a second before it shows you the error.
>> This is timing out because it's being
blocked at the network level,
it's not a permissions thing.
>> Yes.
>> Just the network port doesn't even exist,
it's not there to be seen?
>> That is right. So the network access
is prohibited from your network security rules.
So your traffic packet is not even able to talk to the API server.
>> So as far as it's concerned, it doesn't even exist.
The connected party did not even respond, it doesn't exist.
>> Yes. So that is what will be the expected result.
So this will give you an additional level of
security on your AKS clusters.
>> Then when you went back to the portal, when you said quote,
quote, which we're doing here is you're turning it off, right?
>> Yes.
>> When I asked you, can I lock myself out entirely?
I might lock myself out of Kubernetes, accidentally, easily fixed.
But I didn't lock myself out of
Azure Management and that's really important to note.
>> Yes. You cannot lock yourself out of that as long as you
have the correct permissions to
access the resource group and the subscription.
>> Very cool. There you go.
Now it's done and it's got an update itself, and of course,
that'll propagate and we'll be able to do that again.
>> Yes. If you look at the authorized IP ranges,
so this was the API server access profile
in which the authorized IP ranges section existed,
and as you see right now, it's not.
So that means the rule has been
deleted and now it has access from all public networks.
>> So do people who use AKS have this feature available today?
>> Yes, that is available.
So we made a GA last year during Ignite
and you can use AZ login or AZ Commandlets to do it.
You can also use your SDK,
your Terraform SDK or your Golang SDK to do the same thing.
Right now, it's not available in portal,
but we'll be rolling that out soon.
>> Because the portal uses the APIs that we build,
so we build it from the bottom
up and we make those available as a UI?
>> Yes, that's right.
>> Very cool. I'm learning all about how to restrict
my AKS clusters by IP address and
IP address range here on Azure Friday.
[MUSIC]