>> In this demo, we're going to be looking
at Azure Policy and Kubernetes.
Organizations have all different kinds of policies,
some of which are required to meet
governance and legal requirements,
others to ensure adherence to
best practices and conventions defined in the organization.
Historically, these policies have been managed and
enforced manually or through a set of bespoke tools.
The Open Policy Agent, a CNCF project,
seeks to make this process
standardized, declarative, and automated.
Azure Policy makes OPA policies easy to set up and manage.
It can be combined with both AKS clusters running in
the cloud and Arc-connected clusters
running in other environments.
In this demo, we're going to look at
Azure Policy in the context of AKS.
We'll first use the Azure Policy UI to set up
a single audit-only policy for one of our resource groups,
then we'll review the results of that audit and see
how to use it to find resources which are out of compliance.
Then we'll look at how you can use Policy Initiatives to replicate
the capabilities of the Kubernetes Pod Security Policy feature in
a standard OPA compliant way and see what
happens when we try to deploy
a resource that violates such a policy.
Enabling Azure Policy for AKS is simple,
and can be done through the portal or the CLI.
In a few minutes, the policy add-on will be
installed and the cluster will be ready to apply policies.
Azure Policy comes with a set of built-in policies that are
commonly used by organizations
that are running Kubernetes in production.
Let's take a look at how we can assign one of
those policies to our AKS clusters.
Within the assignment's UI,
I'll choose "Assign policy".
Now when I create an assignment,
I have the opportunity to create a scope,
which means choosing the Azure subscription and
optionally the resource group that I
want to have that policy applied to.
Then I can optionally choose a set of
excluded resources if there are resources
within that scope that I don't
want to have the policy applied to.
Next up, I choose the policy definition,
and this is where we can see the set
of built-in policies that are available.
So, if I search for Kubernetes,
I'll see a few dozen built-in policies with
descriptions of the definition of that policy.
So, in this case, I'm going to choose
limiting load balancer services to only be internal load balancers,
so not exposing any external IPs,
and I can give the policy assignment a name.
Then under the "Parameters" tab,
I have a couple of important options.
First, I can choose the effect of the policy.
So, by default, this particular policy is set to deny,
which means that any service I try to deploy that would create
an external load balancer will be
blocked by the Gatekeeper admission controller.
Now in this case, we're adding this policy to an existing cluster.
We want to make sure that we're not breaking
any existing workflows that our developers may have.
So I'm actually going to change this to audit,
which means that any resources
that are out of compliance will be audited,
will be visible within the Azure Policy UI.
They will not immediately block deployments of those resources.
I can also choose a set of namespaces within my cluster that
I want to be excluded from
this policy and there's a set that are built-in.
So then I'll go ahead and create that assignment.
Now once that policy is created,
I can go over to
the compliance experience and
find the assignment that I just created.
This is where I'll be able to get a view of
my compliance state relative to
that policy definition that I just deployed.
Now initially, this is going to be in a not-started state,
it'll take a few minutes for
the policy to get deployed to that set of clusters,
and for the audit to run,
and for those results to be reported back up
into Azure Policy and visible in this UI.
And then on an ongoing basis,
that audit will happen every 15 minutes.
So within 15 minutes, you always have up-to-date state
of the policy and compliance within your cluster.
After a few minutes, I can hit "Refresh" here.
And see that I'm out of compliance,
because there is this one resource that is not compliant with
that policy assignment that I just created,
and that is this external LB service
within the policy demo cluster.
So, I can pop open the Cloud Shell and take a look at
that cluster and see
if indeed there is an external load balancer service,
and there it is,
that external LB service that was referenced
within the policy experience,
and indeed you can see that it has been assigned an external IP,
and so it is in violation of that policy.
So, now let's take a look at how we can use
Azure Policy Initiatives to enforce Pod Security Policies.
Once again I go to "Assignments",
but in this case, I'll choose "Assign Initiatives".
Again, I'll choose my scope including
the resource group that I want to apply this Initiative to.
Now I'm going to choose the Initiative definition.
Now, an Initiative is a set of policies that are
combined together into a holistic group, and in this case,
what we've done is taken
the Pod Security Policies that were defined in
Kubernetes as a beta capability and made them
available as an Azure Policy Initiative.
So this case, I'm choosing the Pod Security Policy baseline,
and then within parameters by default,
these are set to be audit.
But in this case, we're going to look at what
happens when we explicitly deny
any resources that are not in compliance with that policy.
Now again, the Initiative is made up
of a set of individual policies,
including things like blocking
host network access, host volume access.
In this case, we're going to look at
the policy that blocks privileged containers.
So I've got a simple pod spec here
that defines a container that is requesting privileged access,
so requesting the ability to interact with the host machine.
And I'm just going to go ahead and try to apply
that pod spec to the cluster.
Immediately, you will see a error that is returned directly
from the Gatekeeper admission controller that is
telling me that privileged containers are not allowed,
so it's being blocked based on
that policy definition that was part of that larger Initiative.
So, wrapping up, OPA enables
policy management for cloud native environments,
and as we saw, Azure Policy and AKS make
consuming OPA policies really easy.
You have full control over the scope of
those policies application and the enforcement.
You can even take Kubernetes Pod Security Policy and
apply those in Azure Policy environment using Initiatives.
Finally, everything that you saw today in the context of AKS
can equally be applied to Arc-connected Kubernetes clusters.
So, if you're running Kubernetes clusters
in other environments and want
to share policies across those environments,
you can do that with Azure Arc.
Here are some resources for
documentation around the Azure experience,
including how to apply Pod Security Policy and pointers to some of
the upstream projects of interests like the Open Policy Agent and Gatekeeper.
Thank you very much.