Hi, my name is Jing.
I'm a program manager from Microsoft Windows.
container team focus on APS HCI.
In today's presentation I'd like to
focus on AD authentication for modernize
your Windows application. As you know,
Windows container cannot be domain joined,
but a lot of applications
still need AD authentication.
What can you do?
Group Managed service account.
GMSA can help.
The second challenge is leveraging Gmsa
in Kubernetes is not an easy process.
We just announced AKS-HCI GA,
because AKS-HCI is in on premises implementation
of Azure Kubernetes service,
one of the highlights for AKS-HCI
Windows Custom is they no longer need
to domain join Windows worker node.
I have two demos today.
One is how to modernize your
Windows application using gmsa.
on standalone server.
The second demo is how easy you can
leverage built-in gmsa support to
modernize your Windows application.
Aksi HCI.
Before we jump to the demo,
first let's talk about service account.
So in Windows there are multiple
type of service account.
Service account is a user account.
Basically you can treat it
as a regular user account,
but there's no password.
You need to remember
Service account is created to run
a particular service or software.
It needs to be individually managed.
And also like password rolling and SPN.
So in large network management
of this service account can.
Become very difficult.
So this is where managed service account
come to picture.
Management service account can provide
automatically password management.
But it's a one to one mapping between
the service account itself and computer,
so you cannot, so the service account
cannot be shared across computers.
So in Windows Server 2012 Group
managed Service account was introduced.
And it can be associated with
multiple computers.
That means a group that has a member
of exactly the computer which allowed
to retrieve the password of the gmsa,
which provide a lot of flexibilities.
In the first demo I will show you how
to modernize.net two tier application
with Gmsa in Windows Container.
This application is a typical asp.net MVC
application with SQL as a backend. SQL
service using Windows authentication.
The first thing that we want to do
is to go to the domain controller
to create Gmsa account.
Domain controller.
Here's my domain controller.
You can use this command to
create the Gmsa account and grant
certain machine account to be able
to retrieve this GMSA password.
You can also view the properties for
this GMSA account and see who has the
permission to retrieve the password.
Here is my application.
You don't need to change a single line of
the code and here's the connection string.
It is connected to my SQL backend
and also the library
is my database name.
Here so you can use
Visual Studio tools
to build and push the container
image to continue registry or
you can use other ways you're
familiar with to push the image.
Yeah, here I was using the build-in tool.
You can also use the WAC tooling
container
extension to push the image.
It's a very convenient tool and also
you can even write your own dockerfile.
Next step on a standalone
domain joined Windows Server.
Have the Docker installed
Download container image of the app.
Then the next step is to
create credential spec.
Here's the credential spec.
This file contains metadata about the gmsa,
and it will be passed to the Docker
engine to run this container.
This credential spec will be reused by
AKS-HCI GMSA solution in my next demo.
The next one. We're going to
create and run the container.
So look at the parameter I'm using,
and credential spec.
OK, the container is running,
so that means my application is running.
Let's open the browser and
see if it works or not.
Oh my website is up and running,
then let's click the list of the books.
The list of the books will retrieve
the data from the SQL back end.
I can delete the record here.
I can also go to my SQL
backend to validate if the
login was using the GMSA.
OK, looks like my gmsa login is successful,
plus the timestamp and
program name are all correct.
OK, let's talk about Windows
container in Kubernetes.
Kubernetes starts supporting Gmsa
with Domain joined host last year.
Same as the demo we showed previously.
The container used host identity
to retrieve Gmsa password from AD.
Because we use host identity. That brings
the requirements for domain joined host.
That way it works when we
attempt to create container.
We use credential spec and said we need the
GMSA and host goes to retrieve the password.
This is not an issue if we
only run on a single server,
but if you are using Kubernetes solution
with multiple Windows worker node.
Trying to scale up the Windows nodes,
upgrade the node or introduce new one
cost a lot of churns n general.
Domain Join is a heavy operation.
To config GMSA end to end
Is not an easy process and it includes
quite a lot manual steps. To address this.
In new model in AKS-HCI.
We are using
"non-domain joined host" solution for gmsa.
We're connecting the node to secret store,
the store is to store the
domain user account.
That identity has permission
to retrieve Gmsa password,
When you request the
container to request the GMSA,
the host goes to the secret store to
retrieve the user identity then.
Then to the AD to get the Gmsa
password. We also introduce a couple
of PowerShell commandlet to simplify
end to end process to config Gmsa.
In this demo I will show you how easy AKS-HI
can deploy Windows application with
gmsa using non domain joined host solution.
Here we have an AKS-HCI target cluster already
with at least one Windows worker node.
To deploy Gmsa, the first
step is to install webhook.
OK, we can use this commandlet
to install the webhook.
Now webhook is successfully running.
Next - add secret with AD user
credential to the cluster,
the AD user credential is the one has
access to retrieve Gmsa password.
Here's a yaml file for demonstration purpose.
Let's go ahead to apply
the secret yaml file.
Next, let's add credential spec.
Now we're ready to create a
GMAC credential spec to cluster.
File here was the one we created
in previous demo. This json file,
along with the secret object name was
just created get passed to
AksHCIGMSACredentialSpec cmdlet.
After credential spec is installed,
we're ready for application deployment.
Here is the yaml file for deployment.
This application is the same one
as the one in my previous demo.
Notice the name of the credential spec
resource is referenced under secret
context with the secret created earlier.
Let's deploy the application.
Now we can see the application
and service are running.
Let's go to the application home
page and do more validation.
Same as last demo.
We can retrieve the list of the books,
which is from the SQL backend.
We can add a new book.
To validate even further,
you can log into the SQL back
end and see gmsa login record
reference in the credential spare.
OK.
That's all for the demo.
If you have any questions on AKS-HCI,
or Windows container,
feel free to drop a line in
our GitHub and will get back
to you as soon as possible.
Thanks for watching.