Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy,
reliability and compliance on the Microsoft Cloud Platform.
Hey everybody, welcome to Episode 74.
This week we have myself, Michael and Mark.
Sarah and Gladys are off right now doing some pretty busy stuff.
And we also have a guest, Kemley, who is here to talk to us about some of the latest and
greatest features in Azure policy.
But before we get to Kemley, let's take a little lap around the news.
Mike, why don't you kick things off?
A couple things I share from my own observations and then some big news from a Microsoft perspective.
One of the things that came up recently was an interesting discussion around what are
the top attacks and the top things that we see and essentially how the attackers start
getting in.
Most of the attacks that we see fall into what I would call the front door, the new
triad that we have to deal with, which is email, phishing attacks, identity theft, either
as a first step or after they get the endpoint, and then of course, endpoint.
So ultimately, the attackers, usually the way they get in your environment is by taking
over the endpoint, taking over an identity or sending an email to do one of those two
things and one of those three orders.
There still are direct attacks on applications and services that are exposed to the internet,
your data center backend stuff, but the sheer volume of them given the accessibility nowadays
of all the different ways that people can work remotely, etc.
It's really, really important to have good monitoring and security operations on those
areas.
So that was one of the things that I thought would be good to share.
And then the other thing that we've seen that's almost always interesting to folks is one
of the things we see in security a lot is a bottom-up or technology-centric type of
approach.
I trace a lot of this back to the roots of when security was heavily based on, hey, we
bought this 19-inch rack appliance with a nice plastic color bezel and it does this
X job and we need someone to run it.
That's how people view the jobs, view the outcomes of security is based on the, hey,
we have a technical security capability, let's drive this outcome.
The thing that we're seeing more and more is that, especially as we get into zero trust
and all these other ways of moving fast on the business and cloud and tech front, you
got to rethink security and think about it from a top-down, outcome-driven first.
What is the outcome we're trying to achieve?
It's not about looking at logs.
It's about detecting attackers.
It's about getting rid of them quickly.
It's not about necessarily finding them on the network, with the network being the active
word.
It's really important, I found, and really helpful to look at things through that frame.
Obviously, we do still have to work with the technology and the logs and the data that
we have, but with that North Star in mind, with that what are we trying to achieve from
a security and risk perspective?
Enough of Mark's meanderings.
The news, the big one that we saw was security copilot.
Microsoft announced this.
It's in private preview, not public preview.
A limited set of customers, design partners at this point in time.
It is essentially taking that JetGPT types of technology, generative AI, I believe is
the correct term for it, that allows essentially a human to have a conversation with the AI
and then queries the data and make sense of it in a human way.
Obviously, not perfect for every answer, but pretty darn good, pretty impressive.
Basically applying that with a combination of some of the open, if I recall correctly,
some of the open AI algorithms as well as some Microsoft-specific, security-specific
ones, blended together.
It's a really fascinating technology.
Has a lot of potential as you chat with this copilot and ask it questions.
It can do, hey, can you go reverse engineer this malware?
Can you do this?
Can you look for things like this?
Really, really compelling, interesting technology.
I think it actually will be transformative.
I think of this as the way that mainframe gave way to desktop, gave way to enterprise,
gave way to cloud.
We never got rid of the old stuff.
We just created a hybrid with this new generation of technology that did amazing things.
I'm pretty excited about it.
I think it has a lot of potential, clearly in early days because it's just private preview.
But I think there's a lot of potential for it to really help.
A lot of the work I've seen so far on it seems to be essentially helping people get value
out of the tools and technology that is already there.
There's all these great code, great capabilities that people have written.
It seems to be just making it a lot easier for humans to find it, access it, and use
it without having to memorize a user interface or where it is or write a script, etc.
I really see it as unlocking the potential of humans to use the technology is the big
theme I'm seeing with this generation of technology.
For those that haven't seen it, I highly recommend checking out the Microsoft Secure video announcing
I should bring up about the way chat GPT and generational AI is going to change things.
this and demoing it, etc.
It's pretty cool, impressive stuff.
Over to you, Mike.
One of my in-laws asked me a question.
Is my job or his job going to be replaced by AI?
I said, I don't think your job is going to be replaced by AI, but it may be replaced
by someone using AI because it gives you that sort of little competitive edge.
I'm very excited for all the generational AI work that's going on.
I really, really am excited for it.
I understand that there are some concerns, but for the most part, I think it's a net
positive, but that's just a personal opinion.
I would add one thing because we did a Q&A live during the announcement day.
I was actually not in on the announcement prior to it.
That was one of the first questions that we wanted to focus on right away was, listen,
this is going to change jobs.
This is going to make people more effective, but it's not just going to snap your fingers
and replace a human with it.
You just have to learn it just like you would any new technology, especially important transformative
ones.
Mike
Accountants became better with spreadsheets.
Mike
Exactly.
Mike
Mathematicians became better with calculators and so did nerds.
I don't think you've got to embrace it.
You can't just ignore it.
You either embrace it because if you don't embrace it, somebody else is going to embrace
it.
You just want to embrace it.
Mike
All right.
Well, we've got to guess.
Let's make sure we get past the news.
Mike
Yeah, let's do that.
All right.
Let's get back to a couple of items I have.
The first one is not going to be, I'll be pretty quick.
You can now configure disk encryption for Azure Cache for Redis using customer managed
keys.
To me, this is one of the triad of things that we're seeing is customer managed keys
everywhere.
We're seeing use of managed identities everywhere and we're seeing the use of private link and
private endpoints everywhere.
This is just one of those examples.
Next one is for Azure SQL database auditing.
We now support user managed identities.
This allows you to restrict access or the destination.
It's just that you put an RBAC policy on, say, a storage account and use a managed identity
of the actual SQL instance to restrict the fact that this SQL instance can write to that
particular storage account, for example.
Again, another example of the triad, in this case, user managed identities.
Next one is there are now some built-in policies for Azure Monitor.
For example, you could deploy an environment and you can say, hey, if you've got Key Vault,
then auditing must be turned on and you must audit this particular storage account, for
example.
This is really nice to see and it's fantastic that we have Kamli here to talk to us about
some of the new aspects of Azure policy.
Also, in general availability is Azure private link.
Again, there's another one of my triad.
Azure private link support for inbound traffic and Azure API management.
Again, nice to see because now you can put a nice strong isolation boundary around your
Azure API management instances.
Staying on the topic of private link, Azure private link for Azure managed instance is
now in preview.
This is in my backyard.
This is great to see this.
We actually had a bunch of customers asking about this just recently.
Just because of the way MI works, just because of the way managed instance works, people
are wondering if they could put even tighter control around network traffic.
Now you can with private link for Azure SQL managed instance.
Next one is Azure Maps.
I didn't even know it existed, to be absolutely honest with you, but here you go.
Azure Maps is now HIPAA compliant.
This is fantastic to see actually because if you've got some applications, some healthcare
application and you want to do things like geocoding for customers or you want to calculate,
say travel times and so on.
You want to do all that geospatial kind of stuff.
Now Azure Maps is HIPAA compliant.
Now you can go ahead and actually use it in your healthcare applications.
Encryption scopes and hierarchical namespace is now available.
Encryption scopes has actually been available for a while, but not in hierarchical namespaces,
but now it is.
What this allows you to do is say, okay, that part of my namespace uses this particular
key encryption key and that particular part of my namespace uses that particular key encryption
key.
You can actually store separate keys or key encryption keys in Key Vault and you can provide
strong access policies around them and so on.
Now you can actually start segregating your storage accounts by encryption scope.
It's good to see that it's now available in hierarchical namespaces.
Durable functions, back to managed identities.
Durable functions now support managed identities for Azure Storage.
Now you can have a durable function.
I think I said that my function has read, write, delete access to that particular storage
account and nothing else, for example.
So again, this is a really good way of putting strong RBAC policies around solutions that
are using durable functions and storage accounts.
This is a new one as well.
I was really kind of amazed to see this.
I'm surprised it didn't exist.
Immutable vaults for Azure Backup.
So this allows you to have a backup that is immutable.
In other words, it cannot be changed.
It's not that there's an Azure policy around it or there's an RBAC control that prevents
people from changing it.
It actually cannot be changed.
The APIs for actually manipulating, like writing and deleting, are not there.
So it is truly immutable.
So this is really fantastic to see.
I think if anyone's using backup, I imagine that a certain set of point in time backups
will certainly be immutable.
And then the last one in the news department is ephemeral operating system disks now support
encryption at host using customer managed keys.
So if you have a VM, virtual machine, say an Ubuntu VM with ephemeral operating system
disks, you can now encrypt those.
So there's a whole bunch of different technologies that we have for encrypting data at rest in
virtualized environments and VMs, one of which is encryption at host.
And so now you can actually use customer managed keys where prior to this point in time, it
was only platform managed keys.
So that's great to see.
And again, it's another one of my example of my triad.
Customer managed keys everywhere, privately private endpoint and managed identities for
client authentication.
So fantastic to see so much progress being made.
All right.
So with that, that is the news out of the way.
So let's turn our attention to our guest.
This week we have Kemley, who's here to talk to us about some of the latest and greatest
news in Azure policy.
Kemley, welcome to the podcast.
We'd like to take a moment and just introduce yourself to our listeners.
Yeah, thank you.
My name is Kemley.
I am a PM, a product manager for Azure policy.
Azure policy sits within Azure control plane and governance, meaning my greater team does
everything from Azure resource manager core to Azure resource graph to tags and management
groups.
So a lot of the fun stuff when it comes to core arm functionality as well as governance.
I've been at Microsoft for three years now, started out as an intern, came back full time
and I've been working on Azure policy ever since.
So within Azure policy, I specifically focus on what we call life cycle, meaning how are
our Azure policy resources being created and assigned to customers environments.
But talk about anything policy related or tags or governance related as well.
Thank you for bringing me on.
Yeah, you bet.
I'm going to be honest, I'm a huge fan of Azure policy.
I've always been a fan of Azure policy.
But before we get stuck into some of the minutia and some of the new stuff, why don't you spend
a couple of minutes and just explain to our listeners some of the basics of Azure policy
and what it actually is.
So Azure policy allows you to control and governance and govern your resources at scale.
So there's three main pillars of policy.
The first one is enforcement and compliance, right?
Making sure that you're enforcing the standards that you want on your environment.
So how these standards look like are kind of due policy definitions, right?
We have built-in definitions for customers to use right out of the box.
And we also have the ability to create custom definitions, which are JSON objects to instill
your own standards that are particular for your environment.
So we allow for real time evaluation and enforcement so we can do things like deny resources from
being created.
We could modify the resource request at the time it comes in to make sure that these resource
creations stay in compliance.
On top of enforcement, we also have compliance reporting.
Meaning we do a periodic and on-demand compliance evaluations of all the resources in your environment
and then report out whether those are compliant or non-compliant to the standards that you've
assigned.
All of this is available at scale, meaning you could apply this at a management group
level, subscription level, however you may like.
And you're able to have multiple policy definitions and aggregate those states through initiatives.
And then kind of the last pillar, so the first pillar is enforcement and compliance, second
at scale.
And the third pillar is really remediation and automation.
We have auto remediation for new resources coming in for particular effects within Azure
policy definitions, but we also allow for remediation of existing resources at scale.
And you could do a lot of automation with our integrations with the rent grid to trigger
alerts or our integrations with Azure Resource Graph for querying of compliance states across
your environment.
So overall policy is a very important engine for your governance and control within your
own environment.
So one thing back in the day when I was in services, one thing I would actually mention
to customers is if they're not using Azure policy, they're doing Azure wrong.
I actually kind of stand by that today.
I think it's such a critically important part of, like you say, compliance and governance
for sure in Azure.
So yeah.
So why don't you give an example of how someone might use policies?
Just pick a canonical example and let's just sort of throw it out there.
So policies covers a lot of things.
It just really depends on what you look at.
A very basic or starter policy, I should say, is around tagging, right?
Or let's do allowed locations, right?
You only want your resources to be applied in certain locations.
We have that definition available right off the bat.
You go to your portal today or go through API, you'll see that built-in definition available.
It's called allowed locations.
You get that definition, you assign it.
When you assign it, you're specifying that what scope do you want this to be assessed
at?
So management group level, subscription, resource, resource group, those are the four scopes
available.
We usually recommend to kind of adhere to the at-scale stories.
You do it as high as possible.
So we could do, let's say, management group level.
And then you just specify what locations do you want to allow, right?
So you could say, I only want the US, so West US, East US, those handful locations, or I
only want the Asia locations, right?
So you select a list of locations, you apply that assignment, and then policy sits within
the front door of Azure Resource Manager, meaning any request that goes through ARM,
it comes through policy first.
And policy will assess that request and say, OK, where is this resource trying to be created?
If it's in Asia, OK, cool, let it go forward.
If it's, for example, in Europe, we'll say no, deny the request.
The resource can't be created, and it's blocked.
As you continue into the journey of policy, things can get really quite complex, and you
can create a lot of different conditions and clauses as to what's allowed, what's not allowed.
But the built-ins really allow for that easy flow in.
Another set of examples that are really popular is allowed skew types for storage accounts,
disabling public network access, having a certain IP ranges.
Really the world is endless, because anything that goes through ARM is able to have a policy
enforcement on top of it.
It's interesting you should bring up the allowed locations one, because I work in the Azure
Data Platform, and one of those products is Cosmos DB.
We actually make it really easy to scale out or move your data all around the world.
Very, very easy.
In fact, to the point where if you had enough rights, you could just literally click on
a button and move all your data to different parts of the world.
So that way, the data is closest to your customers.
But sometimes you might not want that, right?
Because you don't want stuff to be pushed to Germany, where all of a sudden you may
have potentially GDPR implications for doing that.
By the way, I'm not an expert in compliance when it comes to all this, and you're not
GDPR.
But I think you've got to be very careful with things like that.
So it's nice to have Azure Policy in place that just says, hey, we're going to work in
North and South America, for example, and only allow certain regions and nowhere else.
So I'm a huge fan of that one.
Another one I'm a huge fan of is to do with Key Vault.
So I can actually say only allow the HSM-backed Key Vaults.
So that way, the keys are stored in hardware.
They're not stored in software.
Now, what was interesting about that one, though, is that back in the day, you could
do that.
You could only allow a hardware-backed HSM.
The problem with it, though, is that even though you have a hardware HSM, you can still
produce a soft key.
So now there's another policy that says only allow what I call premium SKU Azure Key Vaults
and only allow hardware-backed keys.
So that way, no one can create software-backed keys at all or software Key Vaults.
Yeah.
To bring up an interesting point, you said you want, from a manageability and scalability
perspective, to have policy as high as possible.
So for example, a management group or a subscription, could I put a policy at a management group
but allow a specific resource group in a subscription to not be dependent on that particular policy?
I can apply a policy absolutely everywhere, but not in this little resource group over
there because it's some special kind of special.
Yes, you actually can.
So policy has two mechanisms to go about it.
We have both policy exclusions, which lives within the assignment, or policy exemptions,
which is its own individual resource.
So my question, if you're saying I want to exempt or exclude this resource group from
this overarching policy, it would really depend on this scenario.
So we see exclusions being used a lot, exclusions which lives within the assignments being used
a lot for scopes that we're saying we never want to touch this.
So let's say you're applying something at the root management group level, so across
your whole tenant, and you say I want to kind of permanently exclude my non-prod environment.
It doesn't matter, I don't need to govern it.
I'm just going to let that be.
So then in that case, you can use an exclusion to manage that.
You can also use exemptions.
The benefit of exemptions is that exemptions, because it's its own resource, can have its
own life cycle.
So you can create and delete exemptions as needed.
You could also add a time of expiring, meaning that that resource would automatically, that
exemption resource will expire, meaning whatever was exempted will then come back into enforcement.
The cool thing of exemptions as well is that it comes up in the compliance state, so it
will show you like that resource group is exempted, versus exclusions will not come
up in compliance.
It's just ignored by the assignment completely.
But yeah, we do have the mechanism.
It just depends on what kind of nooks and knobs you would need for that resource group.
So one thing you mentioned before, which may have been missed by some people listening,
you said that policy injects itself at the resource manager as your resource manager
or ARM level.
There's some really important implications about that, right?
I mean, if you're deploying something or even changing something after the fact, I mean,
the ARM middle layer there gets in the way, right?
I mean, policy gets in the way regardless of, as long as you're going through ARM, policy
gets in the way regardless, or more accurately, sounds a bit cynical, as your policy is enforced
regardless as long as you're using ARM.
Yes.
So yeah, I like to say that policy sits at the, it does sit at the front door of Azure
Resource Manager and it just monitors all the requests that come through ARM.
So it doesn't matter what format that the customer is using to create resources.
So it could be an ARM template, it could be through PowerShell or through the portal specifically,
policy will sit there and make sure that everything that comes in is in compliance to whatever
is standardized or whatever is assigned in the environment.
It has some cool facts, such as when you use the policy effect called modify, we're empowered
to look at these requests that come in and modify the request so it stays within compliance
and engineers or the resource creators don't have to think about, hey, is this setting
a set or did I put the correct tags that I do all this work?
The modify effects that you can assign within your environment will automatically do that
and modify those requests as they come into ARM.
On top of that, we also have a great integration with the portal team and other product teams
who are creating their own portal experiences and allowing for what we call the policy aware
portal experience.
You might have seen it as you create resources through policy, but you'll see these validation
fail or these red boxes come up or you might even see some gray boxes and things that you
can't unclick and that's all powered through policy and ensuring that whatever business
standards are assigned in your environment continue through your flow and make it easier
to create these resources so you don't select things that you're not supposed to or that
are non-compliant or not allowed.
So policy really injects itself at the beginning of the process to make sure we keep our environments
as secure as possible.
That's an interesting point.
Yeah.
I've seen some of the instances where the UI is grayed out because of policy, but again,
if you were to write like a PowerShell script or an ARM template, you could basically set
whatever you wanted in there, but the deployment or the update may get rejected, right?
Because of policy.
Yeah.
Okay.
Correct.
There's an interesting verb you mentioned before which is deny, but as your policy
is not just all about denying things, right?
There's lots of other actions that policy can actually do.
Yeah.
So we have a lot of effects and we've actually added new ones that I'd be happy to talk about.
So the ones that have existed for a while, we have append, audit, audit if not exist,
deny, deploy if not exist, disabled and modified.
I already talked a bit about modify.
Deny is pretty self-explanatory.
We will deny any requests that comes in if it's non-compliant.
Audit and audit if not exist work hand in hand in that if we don't actually do any enforcement
to request, but we audit meaning we report out all the compliance so you can continue
to monitor that and see the compliance states of your resource.
The two new effects that we have just introduced is deny action and manual.
So deny action as the word entails denies any actions that happen on the environment.
So historically policy has only looked at resource configuration.
So is this resource configured correctly?
Deny action is kind of the first step in policy looking at, well, what is the action that
I want to do on these resources and how do I prevent those actions from succeeding?
So the first action that we're looking at is delete.
So you might have heard or you sometimes it's referred to as the deny delete effect because
basically what we're doing is since we sit at that front door, we're looking, are there
any delete calls that are going to this resource or scoped at this resource?
And if we see that we will reject the delete call from coming in and block it, meaning
the resource won't be able to be deleted.
The cool thing about this is deny action works as any other effect in policy, meaning the
JSON if condition is completely open.
So you're able to add the functionality of deny deletion of anything that has this tag
or deny the deletion of any virtual machines within my production environment and just
that if flexibility.
And it works exactly the same as any of the policy you create for definition, you assign
it and you'd be able to see which resources are applicable.
Currently deny action is in public preview.
So you're able to go ahead and create those definitions and work on that.
The missing piece for a general availability which is soon to come is the matching compliance
state of protected.
So any resource that is applicable to deny action will come up as protected.
For right now for public preview, they come up as compliant, but you should see that compliance
state change when we go GA.
That deny delete, is that like a super duper management log?
It is similar in the goal, but it just comes with the at scale story of policy.
And you know, locks also allow you to deny update and deletion.
Right now we're just, policy is only focused on the deletion, not on the update scenario.
Very cool.
Okay.
Yeah.
When I first saw them, man, that looks a lot like, you know, putting locks on resources,
but I'm glad you explained the differences.
I think that's very important.
And certainly the scalability aspect is critically important as well.
You know, resource locks, if someone has the permission to that resource, they can remove
a resource lock.
Versus a policy, you have to have policy permissions to remove or exempt yourself from that policy.
Yeah.
You could be a contributor at the resource group level, right?
So now you can start removing locks.
Being a contributor, say for example, at the resource group does not mean you have the
ability to start, you know, tinkering around with policy.
Yeah.
Especially if these policies are assigned at like management.
Exactly.
The subscription owners and those people can't change that stuff.
They don't have the permissions to.
All right.
So that's sort of some of the new functionality in terms of some of the actions.
So what else is kind of either on the cusp is available now or it's in GA and you know,
what are the things you're looking at sort of further down the track?
Yeah.
So actually something that's quite top of mind for all of the Azure policy team is safe
deployment.
How do we safely deploy these policy definitions and assignments in customers environments
so we don't do breaking changes or changes that might be negatively impactful?
As we know, as we talked about effects, policies have quite a bit of enforcement and we want
to make sure we do that carefully and by hand selected rollouts, right?
Whether that be location based or resource based or eventually tag based, we need to
make sure that we're doing it in a controlled mechanism.
So it's safe deployment has been really important.
We've actually released some stuff already for safe deployment.
We have some other stuff coming up.
Particularly we did updates through to policy assignments.
So policy assignments now have a new property called resource selectors in which you could
specify what resource locations and resource types you want that assignment to apply to.
So in conjunction with the applicability that comes in with the definition, right?
All those conditions that you have and with a scope, all that information, we will also
accept any resource locations and resource types that you want us to narrow or focus
on within selectors.
So for example, we talked about allowed location definition, right?
Let's say you're rolling out this allowed location, which is a deny, right?
On your environment and you want to say, okay, I want to slowly roll this out, but I only
want this to be on a handful of resource types first, right?
I only want to, let's start with my storage accounts.
So you would specify a resource selector.
You'd say kind resource type and it's an array so you can keep on adding value.
So you'll say, let's start with storage account.
So we'll only enforce that allowed location assignment on those storage account resources.
And then you can go in and then add virtual machines and then add Cosmos DB and then add
you know, et cetera, et cetera amount of resource types.
You can do the same with locations, slowly add in more locations to roll out that policy
definition.
Eventually, we're also looking to support tags.
So it's something that the team's currently working on and how can we support a tag based
rollout, meaning, you know, if you have all your resources tagged as ring one, ring two,
ring three, you just tell us what tags to include and you can slowly roll that out.
So that's selectors.
Also within assignments, we've also added a new property called overrides.
Overrides allows you to override values that are specified within the policy definition.
So a common use case for this is, you know, hey, I see this built-in definition.
I really like it.
I want to use it, but it's only in the deny mode and I need it in audit, right?
Or it's only in modify, I need it in audit or, you know, whichever way around that you
need the effects to go.
So with overrides, you're able to assign that built-in definition and just override the
effect value.
So you could roll it out that way.
So if you want to go back to allowed locations, it's by default in deny effect.
You could say I'm going to override that effect and I'm going to start out with audit.
I can audit all my requests that are coming in, audit all my resources that currently
exist, roll that out to my environment first, and then flip the switch and switch it to
deny.
The cool thing about overrides is that you could use selectors within overrides, meaning
you can override the value for deny to only certain regions or to only certain resource
types.
Meaning as you roll out this new enforcement, you have a more controlled mechanism to where
to apply the deny instead of applying it all, you know, straight up on the whole environment.
And this is all within one assignment.
You don't have to create any new assignments, same assignment ID, you're just updating that
with whatever knobs that you need to have it in.
So that's our first phase of safe deployment.
As we continue to go into this process and work on it through all of our semesters, the
next thing that we're looking at is how can we support versioning of policy definitions,
specifically our built-in definitions.
We've heard from our customers kind of the pain points in keeping track of updates to
our definitions and what's new and what's going on within this built-in definition world.
So we are looking to introduce versioning for these definitions and it's something that
we're currently working on to be included kind of in that safe deployment process and
the upgrade experience, as well as delving into how do we support things like deprecating
policy parameters and rollbacks for changes within policy.
So overall, safe deployment is really top of mind for us and how can we empower the
enforcement of these organizational standards.
So as we continue to empower, we also have to improve a lot of latency in the work around
that.
So we actually just rolled out a whole bunch of efforts that we had to reduce the latency
and compliance view.
So usually, typically we say 30 minutes for your compliance states to populate.
I think now our average is down to 10 minutes.
So you should be seeing those compliance states populate a lot quicker and having that latency
reduced.
We're also looking to reduce latency on policy enforcement and on global replication and working
with the Azure Resource Manager team to ensure that.
Other things that we're thinking of down the line, things like what if support, I talked
a bit about versioning, having more UX around building these policies and also having like
what's new page to keep up to date as to what policies are coming out and what policies
have been changing.
But overall, policy is always focused on increasing our language and expressions while trying
to simplify the experience overall.
I'm quite excited for what we're working on now and to see the future of policy.
Yeah, I think for a lot of people, Azure policy is actually quite a bit bigger than they may
have thought.
There's a lot more moving parts to it than a lot of people may have thought.
So this is great to see.
It's definitely like peeling an onion.
This has been awesome.
I learned a lot.
Again, I'm a huge fan of Azure policy.
So it's great to see these improvements being made.
But one thing we always ask our guests is if they had one final thought to leave our
listeners with, what would it be?
I think my final thought is governance should not be an afterthought.
It should be one of the first thoughts in creating your environment.
It's important to have that active control and policy is a great mechanism to have that
and just govern at scale for all your Azure resources today, tomorrow and for the future.
Kamli, thank you so much for joining us this week.
Again, I always learn something on every episode, but I certainly learned a lot about some of
the new stuff that's coming out.
Again, I'm a huge fan of policy and I'll stick to what I said at the very beginning.
If you're not using Azure policy, you're doing Azure wrong.
That's just my personal opinion.
So again, thank you so much for joining us.
To all our listeners out there, I hope you found this podcast useful.
Oh, by the way, if you want to wear Mark when someone put looks like someone put an axe
through his fiber optic cable.
That's why I had to sort of one man this towards the end.
So anyway, thank you so much for listening.
Take care and we'll see you next time.
Thanks for listening to the Azure Security Podcast.
You can find show notes and other resources at our website, azsecuritypodcast.net.
If you have any questions, please find us on Twitter at Azure Setpod.
Background music is from ccmixtor.com and licensed under the Creative Commons license.