(upbeat electronic music)
- Coming up, we look at the latest advancements
for Linux containers that allow you
to connect your on-premises resources with the cloud
for agility, while maintaining
data sovereignty and security.
We'll look at the ability to run AKS connector
to custom or private virtual networks,
including on premises in the cloud.
Native integration to Azure Active Directory
in Kubernetes RBAC for secure access to AKS,
managed service identity at a per container level
to grant secure access to specific Azure resources,
and securing your images with content trust
in Azure container registry and deploying them
with helm charts.
So I'm joined today by one of the founding fathers
of Kubernetes, Brendan Burns, now one of
the engineering leaders in the Azure Compute team.
Welcome back to the show.
- Thanks, it's good to be back.
- So it looks like there are now lots
of great updates to make it easier
to use Kubernetes in the enterprise,
and this builds on many of the existing
advantages of using Kubernetes with containers
today from the great identity
that comes through OS virtualization, to how, from an IT
Ops perspective, orchestration can help you
to service containers and the apps running
on them without incurring down time,
and at the same time, enabling super fast scale.
And we demonstrated a lot of that
last time you were on Microsoft Mechanics.
- [Brendan] Yeah, I think that one of the great
things about Kubernetes is
it really can provide teams with agility,
so the ability to deploy containers quickly,
to roll out new versions while still
maintaining a service with zero down time.
It's self-healing, so if you happen to have
a bug and your application crashes,
your application will get started back up by Kubernetes.
It's got this application-oriented focus
that really enables you to forget about the machine
and focus on your app, and what we found is
that while it was really great for people building
new web services and maybe startups and that sort of thing,
it had some features that were missing, perhaps,
for for an enterprise environment, and, you know,
we've done a lot of work over the last six months
to really add a bunch of those features
to make it possible to gain the same advantages
in an enterprise environment with
the Azure Kubernetes service.
- Okay, great.
So how are we updating the experience
for enterprises with AKS?
- Well, the primary thing we've been looking at
is how do we improve security and manageability?
The management controls, where you may have
different groups of people managing
different kinds of resources in Azure.
- [Matt] Okay, so where do we start
with the security controls?
- So you know, the most important piece that we started
with was the network.
You know, one of the things we found
from talking to people, is that Kubernetes
has to really customize the network that it's
deploying into, and so initially
we just created a virtual network for you.
- Right. - But that doesn't work
in a lot of enterprise environments where you have
specialized circuitry, like an express route, or a VPN,
or maybe you have a networking team that manages
firewall rules and and even the creation of networking.
So one of the features that we added
was the ability to deploy a Kubernetes cluster
into any virtual network, a virtual network
that's been provisioned for you.
So for example, I'm over here on
the Kubernetes cluster create screen in the Azure portal--
- Right. - --and if I go into
the networking tab, well, in the basic configuration
there's not really anything for me to do.
- Yep - But if I click over here
on advanced, what lights up is
a bunch of different options.
So I can choose a virtual network that I wanna
deploy into, I can customize the network,
the subnets and IP ranges that the containers
and the load balancers and everything in the network uses.
This enables you to really customize the cluster
to match the needs of your existing virtual network.
And I'm showing this to you here in the portal,
but of course, you can do the same thing in PowerShell
or the CLI, if you want to integrate creating a cluster
into CICD or any other sort of automation.
- Awesome, so you mentioned access management.
What's been added there?
- So yeah, so if we go over...
If we go back up, and we look in the authentication section,
we can actually turn on Kubernetes RBAC.
So that's gonna give you fine-grained access control
to all of the resources inside of the Kubernetes cluster.
But even better than that, what we what we enabled
was the ability to use your Active Directory credentials
for authenticating into your cluster.
So we'll come over here, I'll show you a demo of that.
So what I'm gonna do right now is I'm gonna connect
using the native Kubernetes tools
to that AKS cluster that I have, and what you're
gonna see here is it's the standard device login prompt.
So anybody who's used the AZ tool, PowerShell, anything,
this is the way that you login to Active Directory
and get your credentials.
- [Matt] Right. - So if we go over here
and we get that code...
I'm actually gonna create a private window,
'cause of course I'm logged in here,
so it wouldn't be nearly as exciting
if I used that, but let's say--
- [Matt] Gotta keep it real.
So you're just gonna log into the portal
as you would normally?
- [Brendan] It's actually not even the portal.
It's actually Active Directory itself, right?
- Yep - So it's a separate
login, actually, from...
It's your same login credentials, but the
application ID that's being used is actually
devoted to Kubernetes, and of course,
it throws you this prompt to make sure you know
that you're granting permissions to this application.
- Perfect.
- So we'll continue, and then it's gonna ask me
to sign in, obviously.
- [Matt] And with this, anything native
to Azure AD works.
- [Brendan] Yeah, I mean, this is the standard
Active Directory, and in fact, at this point
it's gonna prompt me to go and, you know,
put my password in here.
- [Matt] So the key thing for enterprises here,
they don't have to change the way their
users are logging in or authenticating and so on.
- [Brendan] Exactly
- [Matt] It just fits in.
- [Brendan] All of that stuff is gonna fit in,
and here, obviously, Microsoft has two-factor authentication
set up, so I'm gonna actually send a request to my--
- [Matt] You're going to go into mobile device on me?
- [Brendan] I'm gonna go with my mobile device here.
And now we I've got my handy mobile device here
Did that actually take?
Ah yeah, there we go.
We'll wait here a second--
- Yep. - --while the
authentication comes through.
- And just as easily, you could give access to people,
you can revoke access as well.
Just the traditional-- - Yep.
So the prompt's come through on my phone here for access.
- Right, okay, I see that.
- It approved of my fingerprint.
- Yep. - They saw that.
- Alright, we'll go back over to...
So now it's gonna say, okay, you've successfully signed in.
We can close that down.
And if we go back over to the terminal,
now I've gotten access and I've seen my notes.
But of course, that took us probably 45, 50 seconds--
- Yeah. - --to go through.
That'd be pretty annoying if you had to
do that every single time.
So now that I've authorized the control line,
logged into my credentials, if I do any
subsequent commands, you know, it just
happens immediately, right?
So it's a one-time setup to authorize on every new machine.
But that gives you the confidence that,
you know, if somebody gains access to your credentials,
if they try and login from a different machine
where you haven't gone through that flow--
- Yeah. - --and they don't have
your phone, well, they're not gettin' in, right?
So it's really...
It allows the enterprise security that you expect
to access the Kubernetes cluster.
- That's the key thing there is
the enterprise levels of security.
- [Brendan] Exactly, and the policies that they have set.
- [Matt] Yeah, and that's great news for Azure AD admins
who are looking for that consistency with permissions
and authorization, and you can automate access provisioning
for convenience as well, so it's a great solution
if you've got different types of admins
where you need to define different permission levels.
- Right. - How does this extend
the access and use from specific resources
from something like a DevOps perspective?
- Well, so, of course, when you're developing
cloud-native applications, they need to access the cloud
from the application themselves, right?
So it's no longer the fact that just a user
is creating a virtual machine and then
that virtual machine runs some code.
The code on those machines oftentimes
is gonna be accessing Azure itself
for a data store like Cosmos,
or to find out about, you know, its IP address
or any other kind of information.
Obviously I don't wanna use my identity there,
because I might be on a team with a bunch of developers
and so it doesn't make any sense
for my identity to be bound in
with the front end application.
- Right. - But also probably
more importantly, I have a lot of capabilities.
I can create virtual machines, I can do
a bunch of different things.
You probably don't want your application to have that.
You wanna scope it down to the least set of privileges
that they want.
So you wanna be able to give a container
that's running in the Kubernetes cluster
specific permissions that are devoted to its role--
- Yeah. - --in the application
of front end identity or a back end identity.
- Just enough to do what it needs to do.
So we'll give you a little demo here
of a pod that's gonna have access to list virtual machines.
So what we're gonna see here
is we're gonna deploy a container, a pod,
that is gonna try to access, to list
the virtual machines that I have in my subscription.
So I've deployed that container.
We'll make sure that it's up and running.
So there you go, you can see that it's running.
It's been running for eight seconds, 10 seconds.
- [Matt] That's the top one in the list there
- [Brendan] The top one there, yeah, exactly.
So we'll go outta there.
Now what I'm gonna actually do is I'm gonna go into
sort of a split screen mode here
where I'm gonna list the VMs.
And what you see here is that I'm getting
permission denied, right?
And I'm not getting permission denied 'cause of
the demo Gods, but I'm getting permission denied
'cause I actually haven't created the identity
and associated it with this container.
- Right. - So let's
go ahead and do that.
- [Matt] So the container at this stage
doesn't have privilege.
- [Brendan] It doesn't have permissions.
The code is running, but it doesn't have--
- Right. - --the token
that gives it the permissions, right?
- Gotcha. - So I've created
an Active Directory identity for this container,
and now I have the identity and I have the container,
but I haven't associated them together.
- Yep. - So I'm gonna create
a binding that's gonna associate that identity
with the container.
And so what you're gonna see in just a second
is that the permission denied should turn into okay.
- [Matt] 'Kay, so what's happening in the background here?
- So in the background, what's happening is
the token and the identity are actually being provisioned,
They're being associated with the container that's running,
and with luck, if the demo Gods are, in fact, with me,
you'll see the container start to be able to list the VMs.
- [Matt] And is this something that you'll have to do
every time, or is this something--
- This is something every time that you associate
a new identity with a container.
- Okay. - Alright.
- [Matt] So this can take a few seconds to run?
- [Brendan] It can take some time to go through, but--
- Is there anything else in terms
of Azure Active Directory that admins out there
need to set up in order to have
this functionality available?
- No, it's taking advantage of the MSI,
managed service identities--
- Right. - --that are available.
Oh, there we go.
It's taking advantage of the managed
service identities that are...
(clapping)
Yeah, thank you, thank you, yeah.
(chuckle)
It's taking advantage of the managed service identities
that are present on the VM.
- Right. - But, of course,
that managed service identity is scoped
to a specific VM, we wanna--
- [Matt] Yep.
- There might be multiple containers
on that VM, so what we do is we take
that managed service identity and we create
these explicit service identities
that are associated with each container
and we sort of provide them to you
at the same metadata endpoint that your code expects.
- Right. - So the same code
that ran in the VM will run in the container unchanged.
- Okay. - That's pretty cool.
- Right, so the container gets its unique ID--
- Yeah. - --from the developer
or the shared account.
- Right. - You can
dynamically grant these permissions or revoke, and I--
- [Brendan] Yeah, exactly.
You know, one thing that...
Obviously, we don't necessarily like
to talk about our code getting compromised--
- Yep. - But it does happen,
and so you wanna be able to revoke those credentials,
and so what I'm doing here is I'm actually
editing the definition of the container.
This is the pod binding that it's
associated with, called demo.
I'm just gonna change this to be demofail
and we'll update that container.
And what you'll see in just a second
is that the permission is gonna get revoked
and we're gonna go back to getting permission denied
from the list of the VMs.
- [Matt] Right, so you've essentially bound it
to something that doesn't exist.
- [Brendan] Yeah, you're correct.
That identity doesn't exist and so I've bound it
to something that doesn't exist and so it should,
once the sort of eventual consistency...
Yeah, there we go, permission denied.
It's because it's actually gone in...
It had the container where it had provided a token
and it's actually ripped that token away.
- Right. - So you can,
you know, effectively, if you know
that something has been compromised, or you don't want to,
you've mistakenly granted permissions to something,
you can really easily rip those permissions away
with the running container still operating correctly, right?
- Right, okay.
- So I wanted to show also that we can
add these permissions back in.
- [Matt] Okay.
- So we can actually do the same thing
and go in and there we go.
And now if I just go back in, and I change the back--
- [Matt] You can reestablish the binding?
- [Brendan] I'm gonna reestablish the binding.
- [Matt] Okay, sounds good.
- And then it's gonna go ahead
and the permission will come back
and we'll get okay going again.
So, that's a part of what it takes
to secure an application.
But, you know, one of the other parts
of the application security is,
it's only as secure as the code itself, right?
- Right.
- So it's great that I can give these permissions
and I can revoke them, but if I have code
that I don't trust, if someone can land, you know,
a binary that I don't know about, even a rogue developer,
for example, someone who hasn't gone through
my CICD system, if they can land code into my container,
well, all this security with AAD and all that,
it doesn't really account to much, right?
- [Matt] Right.
- So the good news is that with content trust
and the image content trust that is now part
of the Azure container registry, we can actually
go ahead and do those sorts of controls.
So I'll give a little demo of that right now.
So we're gonna start out, we're gonna log into the registry,
and this is just a standard Azure container registry.
- Right. - Getting the
credentials for that.
Now that I'm logged in, it's configured this
in Docker, and we're gonna go out
and build an unsigned image, and I'm gonna push it
up to the registry.
- [Matt] This is your specific registry?
- [Brendan] So this is my specific,
personal, private registry.
Nobody except for people with my credentials
or my team's credentials
- Yep. - Of course,
you can use AAD for that authentication too,
so, you know, you can use grouping
and the right kind of stuff.
- Okay. - I've pushed it
up to the registry, but of course,
this one was unsigned, right?
So it didn't ask me for anything,
didn't make me do any work.
- [Matt] So potentially this could be malicious?
- This could be malicious, or more importantly,
like someone else, if they happened to gain access
to my registry credentials, they could
push up another image--
- Right. - --and I
wouldn't know, right?
I have no knowledge.
I can't tell the difference between
an image that I pushed, versus an image
that someone else pushed, and I don't have any guarantees.
- [Matt] Okay.
- So I'm gonna activate content trust.
It's just a simple environment variable switch,
or you can use a command line flag.
- Yep. - And now I'm gonna
start building and pushing signed images.
So I'm gonna go ahead and build this signed image,
and I'm gonna push it up.
And what you're gonna see this time
is when I actually go to push it, it's actually gonna
prompt me for a signing password, right?
So now it's actually saying I'm gonna sign that image
and I'm gonna push it.
What's the passphrase?
- [Matt] And this is something you
would've established previously?
- [Brendan] Right, so this is something that I created
when I created the registry.
- Right. - And now that image
has been successfully pushed up
to the content trust registry.
So now I wanna take a look at what happens
when we try and run an unsigned image.
So let's go ahead and try and run
that unsigned image that I pushed earlier.
What's gonna happen is it's gonna actually
try and look for that trust data--
- Right. - --and it sees
there is no signature, there is no hash in the registry,
and it says, I'm not gonna run it.
- Right. - I don't trust that image.
I don't know where it came from.
- Gotcha. - But if we go ahead
and run that signed image that I just pushed,
well, now it's gonna actually start,
and my server is running.
So therefore, I know for sure that only someone
who had the credentials to the registry--
- Yep. - --and the signing password
for this image, was the one who pushed this.
And oftentimes you'll put that in your CICD system
and have only the CICD system have access to, say,
a key vault that has that password in it.
It gives you really good, strong guarantees
that every image you're running
came in through your CICD system.
- Yep, in a trusted way.
Great, okay, so what about deploying
my entire application that's made up of, for instance,
multiple different container images?
- Right, so any real application is gonna have
a bunch of different containers coming together
to form the full application.
You know, what we've shown so far shows you how to...
You would deploy individual layers in your application,
but, you know, when you deploy the whole thing,
you need something sort of like an arm template.
And so in Kubernetes, that's the helm open source tool
that Microsoft actually helps maintain,
and so what we've done now is we've taken
those templates that you can build in helm,
and we've made them part of your container registry also.
So all of that RBAC and all of the permissions
that you were using for sharing images between
different members of your team
or across the company now can apply to the templates
that you used to deploy the entire application.
- Right. - You don't have to
put them up on a public GitHub repository or anywhere else.
You know you've only enabled the people
who really should have access to those templates
to be able to deploy your application.
- Okay, cool, so walk us through the process a little bit.
What'd you have to do with it?
- So, you know, when you write a helm chart
it's a text file, it's a YAML file.
It's oftentimes parameterized--
- Right. - --so that you can say,
hey, if I'm deploying into multiple regions,
maybe I need to use a different database
or maybe I need to use, you know, a different number
of replicas, 'cause I have more load in the U.S.
versus in Europe--
- Okay. - --or something like that.
Once you've built that chart locally, you can package it up
very similarly to the Docker build, but you package
the chart, and then just like we did, you can push it up
to the chart, and then on a different machine,
when you're gonna do the deployment,
you can pull that down, and it just deploys.
But again, if you don't have permissions,
if you don't have the right RBAC, or if you've left a team,
you won't be able to do that sort of thing.
- Okay, awesome stuff.
Well, these updates are certainly gonna help
move Kubernetes to a more tangible place
for line of business applications, and organizations
that are definitely more standardized on Azure AD.
Now, for those that are new to AKS,
what is the best place or best way to get started?
- So, you know, Azure is a great place
to run Kubernetes for the enterprise,
but I love to have people go and try it out.
So we've created this site, aka.ms/learnAKS.
That's gonna take you to the Azure documentation
to learn more about how you can deploy the Azure
Kubernetes service into your enterprise environment
and get started with containers.
- Great, and with the new networking enhancements
it's gonna be easier for enterprises to take it--
- Oh yeah, and that stuff's all rolled out and ready to go.
You can go start using it today.
- Okay, and all the role-based access control,
all the integrations, everything you've
shown today, people can--
- Everything you saw today is available right this instant.
You can go play around with it.
- Awesome, great job.
Well, fantastic updates, Brendan.
Great to see that continued fusion
between Kubernetes and Azure, and of course,
you can keep watching Microsoft Mechanics
for the latest updates.
Follow us on Twitter, and thanks for watching.
Bye for now.
- Thank you. (clapping)
(upbeat music)