MICHAEL WITHROW: Hello. Welcome to the demo of
Azure AD Workload Identity on AKS.
My name is Michael Withrow.
I'm a Senior Product Manager on
the Azure Kubernetes Service at Microsoft.
Workload Identity is the next evolution of pod identity,
which exist in Public Preview on AKS today.
Workload Identity allows Kubernetes pods
to access Azure resources.
Previously with pod identity,
IMDS was leveraged for identity transactions.
Now, with Workload Identity,
service account token, volume projection,
and issues allow for a trust between Kubernetes
and Azure AD to allow
the pod to use a token for identity.
This also removes the scale and performance issues
that existed for identity assignment,
supports Kubernetes clusters hosted
in any Cloud or on-premises,
and now supports both Linux
and Windows-based workloads,
and removes the need for
COD resource definitions in pods
that intercept instance metadata traffic.
This also avoids the complication
and error-prone installation steps
such as cluster role assignments
from the previous iterations.
Today for the demo,
we're going to set up
an AKS cluster with OIDC issuer enabled,
enable Workload Identity,
set up a key vault with a secret,
create an identity,
create an access policy for
that identity to access key vault,
create a Kubernetes service account with that identity,
establish a trust between AKS and Azure AD
using that service account and that identity,
and then deploy a sample workload.
To help with the demo, I pre-created an AKS cluster
with the feature flag enable OIDC issuer enabled.
The key parameter is that you can see down here
I have OIDC issuer profile enabled equals true
and there is an issuer URL,
which is specific to that AKS cluster.
I can also run an AZ AKS show
and extract out that information
from an automation perspective.
We will use this later to establish a trust with AAD.
Then I'm going to essentially
grab the credentials of the cluster
because I need authenticate to the cluster
because in order to install
Workload Identity today,
we are doing a Helm chart,
but eventually, that will be
a feature flag in the configuration.
You can see we've ran the Helm chart,
you can see that actually deployed,
then we ran a curl to actually configure the webhook.
Then from here,
we can actually run an export
to extract out the environment variables.
We'll need to set up key vault, and the application,
and the service account,
and the trust within the cluster.
Now I'm going to run a key vault create, sorry.
To actually create the key vault,
then I'm going to run
another command to actually create a sequel.
From here, we're essentially now ready
to start creating the application
or the identity that's going to be leveraged.
For here, we're actually running
a service principle call for this configuration.
This is what works today, but eventually,
we'll be adding in a managed identity as well.
Once that's there,
we're actually going to extract out the client ID
because we're going to need that
for the rest of the configuration.
Then from there, we're actually going to create
an access policy on the vaults
for that particular identity.
Now that that's set,
now we can actually go through
and actually create a service account
within Kubernetes using the value
that we applied before.
And you can see
that service account Workload Identity was created.
Now from there, we can actually get
into creating the Trust.
Now that exporting out the application object ID
and then I'm going to use
that for the body of the JSON.
Now I can use that
to actually establish the rest call.
There, the actual Trust is actually established
and now I can actually go through
and provision my workload.
Now you'll see this is essentially deploying a pod.
You'll see the service account is in there.
You'll see here it's actually set up to talk to
key vault to actually grab
that secret that I needed before.
Now you can see that that pod quick start
was actually created.
Now I'm going to go through
and actually describe that pod.
Now you'll see the actual key vault,
the secret, you'll see the client ID,
you'll see the tenant ID,
and you'll see the Azure Federated token file.
That's necessary.
Now when I look at the logs,
you can actually see that
I successfully got the secret
from the vault using that identity.
Lastly, as we look,
we can actually go into the cluster.
We can actually go into the workloads
and you can go look at the pods
and you'll see we have a quick start pod.
Now when I look at the volumes,
you'll actually see that projected volume
there that's present on that check report.
Now, in summary, we walked through
leveraging Workload Identity
for Kubernetes pods to more securely
integrate with Azure AD through OIDC.
Workload Identity is language specific
and works on both Linux
and Windows-based workloads.
Click the link below to get more resources
for how to implement this configuration.
Thank you.