(soft music)
Coming up, we are going to have a look
on how you can centrally manage
and onboard a wide range of resources,
such as windows, Linux, and SQL servers, Kubernetes clusters
and even all the resources as well.
I'm here with Ryan Willis
from the Azure management team to talk
about how you can leverage
and onboard resources to the Azure control plane.
Thanks for having me, Thomas, glad to be here.
We talk to customers obviously
about Azure arc on onboarding resources
to Azure to take advantage of the Azure control plane.
Now, one of the things often comes
up with architects who need to plan
and manage these environments.
They obviously know tools like Azure policy
or other management services, but they obviously
need to outline their hybrid or multi-cloud environment.
So they can actually like take advantage
and organize their resources.
Now how can Azure arc really help them?
So in Azure arc resource is just
like any other Azure resource.
It's gonna get registered as a resource manager
at central control plane, where everything you have
in Azure shows up and can be queried and managed.
And so that means
that all the standard organizational tools available
to you in resource manager, work for arc resources too.
So if you go onboard your Kubernetes clusters
and your servers to Azure arc,
you'll get to pick what subscription management group,
resource group these resources end up in.
And of course you can use things like tags to help organize
and keep track of which department owns these resources
what role they're serving.
So, yeah, it's really the same experience and you just pick
and choose where you want these arc servers to show up.
So I cannot just use like management group
subscriptions and tagging and all that stuff
for my Azure resources.
I can really extend this to my on premises
or multi-cloud environment.
So that is cool.
It, the same thing is also, I get often questions
by the security and compliance engineers
to ask like, okay so how can I leverage that?
What, how can I leverage Azure Arc in that scenario?
Yeah, that's a good question.
You know, from the compliance perspective
Azure policy runs on Azure resource manager.
So in order to evaluate a resource
and know whether it's compliant,
it has to know the resource exists.
And that's really the benefit of Azure Arc
is by getting all your resources
to show up in a single place
then things like Azure policy can become aware of them
and start enforcing your governance on those machines
so that you get better information about, you know
what is currently running in your environment
from a basic inventory perspective, as well
as is the particular configuration of these machines
or Kubernetes clusters or whatever resource you boarded.
You know as expected for that company's IT policy.
So IT administers obviously.
And we talk about that for a couple of times
can obviously take advantage
of some of the Azure management services
to manage the Azure resources, right?
That is one part obviously, of their job.
The other one is actually to maybe onboard resources
to the actual control plane using Azure arc.
Can you explain a little bit
about the role and how you onboard the resources
to the Azure Arc control plane?
Absolutely, so all the Azure arc products
use kind of an agent based architecture.
So in order to make your resource show
up in Azure resource manager, you'll first install an agent
on that server or Kubernetes cluster, and then project it
or really connected into Azure resource manager.
At which point it will show
up and behave just like any other Azure resource.
So the agent based architecture helps us get a connection
to each individual machine
and start managing it just like we would an Azure resource.
So does that mean like
so I need to obviously to go out to deploy these agents
does that mean like I need full internet connectivity
or do I need to have some sort
of inbound connectivity for that?
Or what's the, how can I lock it down?
Yeah that's a great question.
And the answer really depends
on each individual arc product.
So for Arc servers and Arc Kubernetes
these services are taking existing infrastructure
and making it show up in Azure.
So for the most part, they work in connected scenarios.
Having a disconnected scenario
won't allow us to project that resource into Azure.
So it needs some sort of connection into Azure
to be able to actually tell us what is currently happening
on that machine and respond to things like policies
and extension deployments that you make
from Azure that will affect the machine running
on prem or in another cloud.
That being said, all the connections are coming outbound
from that machine over two
well known IP addresses over HTTPS connections.
We document all of these in our documentation.
If you are building firewall rules or have a proxy server
in place that you need to grant access
to our backend services.
And for the really security conscious
folks who don't want to connect these servers directly
or indirectly to the public internet
we're working on Azure Arc private link scope,
which is actually gonna let you send
all the traffic that needs to go into Azure
for that machine to be Azure arc enabled
over a VPN or express route connection directly
into an Azure VNet
without having to go over the public internet.
Oh, wow.
That is awesome.
Especially the part where again
you can leverage Azure express route
to actually get all that traffic over a secure
basic connection to Azure.
Now that's that's awesome.
So we spoke about, you told me how it works.
Can we have a look
on how you can actually onboard resources?
Definitely, let's take a look at an example
for arc enabled servers.
All right.
So we are here in Azure portal.
I'm gonna head over to the Azure arc server page
where you'll see a list of all my existing servers
for we're going to go ahead and add a new one.
You're first presented with two options.
You can either onboard a single server or multiple servers
and what's happening in this process
is you're generating an installation script.
So we'll guide you
through a wizard asking you what subscription
and resource group do you want to put this resource in?
What region do you want to store the metadata
about the server or Kubernetes cluster in Azure?
What OS is it?
And then lastly, you just need some form
of authentication to be able to say, look
I'm allowed to register this resource
in this particular resource group in Azure.
For the at-scale deployment.
When you're looking at production
we'll use a service principal typically for that.
And so we'll guide you and make sure
that you are able to select a service principal
that has appropriate permissions.
Every Arc service publishes built-in
Azure active directory roles
for the least permission goals,
so that you can actually go and only give access
to this onboarding account to onboard resources.
It can't go change existing ones that can't go create
or manage other Azure resources.
So the example here was servers.
It can only onboard a new Ark server.
You can also pick and choose the tags that you want to come
on that machine by default, of course, if you have policies
in Azure that enforce your tag governance
those will apply as well as soon
as that resource is created.
And then lastly, you're presented with the script
from here it's up to you
how you want to run that on all your servers.
So typically we see customers have some tools
that they prefer to use.
It might be something like group policy
or Microsoft endpoint configuration manager could be Ansible
in the Linux world, or if you're looking
at multi-cloud and the cloud you're deploying
with like say AWS has a custom script extension
capability where you can go
and actually run a script directly on a VM in that cloud,
you could integrate this with a tool
like Terraform or that clouds native SDK
to go and run the script on those machines.
You only got to do this once.
Once the onboarding happens
it's very quick and it's not interactive.
If you use a service principle
then that machine will be onboarded to Azure.
And we can see here in the portal.
So that is the one I just onboarded is now showing
up in my resource group.
And it's ready for management from the cloud.
Now, the way we'd like to talk about arc servers
in particular is that this should be the first
and only thing that you need to go
and manually onboard to Azure.
Once it shows up in Azure
you can leverage the rest of Arc capabilities
like extensions to go and onboard to other Azure services
which might also need an agent
or an extension on that machine.
But from there on out, arc will handle it for you.
So we're the first one you need to get on that machine.
And from there, it's easy sailing
through the Azure portal policy and command line tools.
Now this makes it super easy to onboard
resources at scale doesn't matter what they're running.
If they're running on my own premises system
running on different hypervisor physical machines
or even in other cloud providers, right?
It makes it super, super simple.
And from there on I'm, then able to actually take advantage
of the Azure management services
which are then can go out and enable for that resources.
So that is pretty cool.
And I'm sure now a lot of people
are interested into Azure arc.
So Ryan, where can they find more?
Yeah. If you're interested in the onboarding scenario
in particular, there's no better place to start
than the Azure arc jumpstart.
This is a collection of scenarios that are specific
to all kinds of common environments.
Our customers are running in.
So there are sample scripts
for running onboarding for AWS there's sample scripts
for onboarding a fleet of VMware VMs.
And you know, we're going to keep updating this content
over time to cover a lot of common scenarios
or if you already have preferred tooling
then you just need to get access to that script.
You can generate it today in the Azure portal
or head over to our documentation where you can learn more
about how that script is generated
what it's doing and how to modify it for your own needs.
That is great.
Thank you, Ryan.
And again, if you want to learn more
about building hybrid applications
or managing hybrid and multi-cloud environments
check out our cloud adoption framework
and the Azure architecture center