>> Hello, my name is Liz,
I'm a Program Manager for the Azure Governance Team.
Today, I'm here to showcase to you our new exciting capability,
which is Azure Policy for Azure Kubernetes Service.
By integrating Azure Policy and Gatekeeper on open policy agent,
we're able to have at scale control and
compliance assessment across your entire environment.
There are three main capabilities
in the functionalities of this feature.
The first is around
the real-time enforcement and compliance assessment.
When a developer tries to create a non-compliant object,
whether that be pods,
ingress, or namespaces, we are able to
deny the creation before it even takes place.
The second portion is the compliance assessment.
For many of you,
when you are assigning this policy,
you already have quite a few AKS clusters.
For DOS, we will run the full evaluation to let you
know which of the objects are
currently non-compliant for you to fix?
From there on, we run full evaluation every 20 minutes so
that you can check as to
how you are staying compliant on your environment.
We also provide a compliance reporting,
so that across your entire environment you can see
an aggregated view of how your Kubernetes clusters are doing.
You can drill down on that report so that you have a granularity
down to the pause and ingress of the non-compliant objects.
The second portion is applying the policies at scale.
By integrating with management group,
you're able to have
a single policy assignment impact your entire tenant.
This way, you can also manage
the lifecycle of your policies much easier.
Second is the concept of initiative,
which is essentially grouping of your policies.
This allows you to group your policies
together and make a single assignment
to where you're interested in.
Additionally, as your policy definitions grow over time,
your assignments will automatically inherit whatever is the
latest so that you don't have to worry
about keep trucking of the versions.
Third is our exclusion.
For DOS special snowflakes that you have,
you are able to exclude
the cluster resource group subscription
or even management groups from the policy assignment.
The last pillar is our integration with Azure DevOps.
To easily manage your policy as code,
we have built-in deployment tasks available for you to create
policy definition and assignment within Azure DevOps.
Also, when a developer is using Azure DevOps,
we provide enforcement message in a first-class experience so they
know exactly which policy has caused their deployment to fail.
Now, let's take a quick look at what it
looks like on the policy environment.
Once you've assigned your policy,
this is how your environment will look like,
for my case I have dozens of policies
that are currently evaluating against my subscriptions.
So let me search for
a particular policy that I'm currently interested in,
which is the white listed container images for my clusters.
I can see over here that I have a non-compliant cluster.
So here, I can see that I have my compliant clusters as well.
Now let's go back to the non-compliant cluster
that you just saw earlier.
Not only can I see the cluster level,
but I can also drill down to the granularity of
the pods as well so that I
know exactly which ones I need to go fix.
If I go back to the view that you just saw earlier,
I can also see how this policy has been authored.
It's a fairly simple policy definition where all I'm
checking is the fact that this is on AKS cluster,
and then I'm enforcing
the [inaudible] policy where I provide the GitHub link.
If I open up the GitHub link,
you'll be able to see that this is denying any pods that is
not using one of the white listed container images.
Then, if you get non-compliant,
you will get appropriate error message as a part of that,
so that the developer knows
precisely what policy has caused the non-compliance.
To get started, all you have to do
is search for the policy that you're interested in.
So the one that you just saw was
the white listed Container images.
This policy definition it will be already on
your environment so that you don't have
to author this definition on your own.
So now from here all I have to do
is assign this particular policy definition.
I'll provide a scope which can be a resource-resource group,
subscription or management group,
and I can also have an exclusion on that particular scope as well.
The interesting part here is that we
support parameters so that you can
specify precisely which container images need to be white listed.
From there, you just assign that policy to get started.
Now, this capability is currently in limited preview,
and hence your subscription needs to
be white listed through joined preview.
When you go into the policy experience that you saw earlier,
we have a TOC item on the menu that says join preview.
All you have to do is select the subscription
that you're interested in and onboard.
From there, you'll be able to add the policy add
on which is essentially an agent with the gatekeeper,
and policy components in there,
to be able to manage the components within your cluster.
The last portion is assigning the policy as you have
seen earlier, and that's it.
For you to learn more,
please go to our documentation link.
Thank you for watching.
I hope you have a great Microsoft Build 2019.