>> We all know Secrets Management is important,
including in your containerized solutions.
Yoko is here to show us how we can use HashiCorp Vault with
Azure Kubernetes service to store and retrieve secrets easily,
today, on Azure Friday.
[MUSIC].
>> Hey everyone. Donovan Brown here with
another episode of Azure Friday.
Today, we're going to learn about using
HashiCorp Vault inside of Azure Kubernetes service.
So, we talked about it earlier,
about using HashiCorp Vault for secrets management.
But now we're going to be talking about it in
a more containerized scenario, right?
>> Yes.
>> Okay.
>> Containerization has been a common practice nowadays.
>> Yeah, it's huge. It's very popular.
>> Yeah, Kubernetes are popular orchestration tools.
>> Every much one, yeah.
>> Then next questions people start
asking is where to put the secrets.
>> Yeah.
>> Like if your container needs to talk to external database,
then where are you going to put the database credentials?
>> Right.
>> HashiCorp Vault is an open source secret management tools.
So, it can be a good solution for that.
>> Got it.
>> Then, our users recently started asking more and more,
can we use HashiCorp Vault with Kubernetes?
That's a question we are getting a lot.
The answer is, yes, absolutely.
To help that, so HashiCorp Vault use client-server model.
So, that means the container that needs to talk
to Vault to retrieve secrets,
that clients have to first authenticate with a Vault server.
>> Got it.
>> Basically, make sure that
it's valid client to talk to that server.
>> So, what I would do as a Kubernetes,
if I'm running a Kubernetes cluster,
whatever that service account,
I would think over the HashiCorp Vault
and basically give that permissions?
>> Yes.
>> Then what you're going to show me now is
what the communication looks like between
that server's account inside of
Kubernetes cluster talking to HashiCorp Vault?
>> Yes, exactly.
So, here, the client can be Kubernetes but also can be
any applications or can be user.
>> Sure.
>> We do have a number of authentication methods that we support,
and Kubernetes is one of them.
So, as you mentioned,
Kubernetes using that service account,
we can validate that container's identity.
>> Okay.
>> So to demonstrate this,
to save some time,
I've already have Kubernetes authentication method configured.
>> Okay.
>> So, this Vault server that's actually running on the Azure VM,
already knows about this service accounts.
>> Got it.
>> I have a Kubernetes clusters running on AKS already.
I love it how you can just copy the commands,
still on the dashboard. It's so nice.
>> Yes.
>> So, I already have a Kubernetes dashboard running.
To just demonstrate, I simply have
a Linux container running and Alpine image.
Nothing particular.
So simple container.
>> It sounds like we have several machines here.
Inside of our Kubernetes cluster,
we have an Alpine image just sitting there, right?
That's what we're going to use to
show how we can actually connect to the Vault.
The Vault is actually running in a Linux machine,
also running in Azure.
But not inside my cluster.
>> Exactly. Perfect. Yes, because
this is just a plain Linux container,
it doesn't know anything about Vault.
So, I'm going to just use Curl to make
the direct press API invocation against the Vault server.
So, I've already done this.
Also, I already put
the Vault server's location as an environment variable.
So, I don't have to type it up.
>> Sure.
>> Similarly, I also have
that Kubernetes tokens store as an environment variable as well.
So, remember this is a container,
this is the identity of a container.
>> Got it.
>> So, now I'm going to do the authentication.
So, this command, this is the API call.
This container is doing login,
invoking login endpoints against
the Vault server's API using
Kubernetes authentication method that I've already configured,
and passing Kubernete token as an input in a payload.
Also here, I say example.
This is basically same example role.
This is the same, very similar,
to IAM role in Azure.
So that dictates how much of
a secret this particular client can read.
>> So, he's requesting access to the example role, right?
>> Yeah.
>> This is who I am, and please go log me in.
>> Yes.
>> Got it.
>> Yes.
>> Okay.
>> So as a matter of fact,
the Kubernete token was valid service accounts,
so Vault server return the client token.
Here, you can see the role is set to example,
and here it has token policies.
In Vault server, we use
policies to control the access of the clients.
>> So, this is what permissions it has to do.
>> Exactly. So, this policy only gets
free and list permissions against this particular endpoint.
>> Got it. So, you can't add any new secret?
You can't delete them, but you can
read and list them to see your secrets server?
>> Yes.
>> So basically, this container I determine
this is all this container has to be able to do.
>> Perfect.
>> It shouldn't be able to do anything else more than that.
So I'm going to show that I'm not lying.
>> This is a real demo?
>> Yes. So, every request,
you have to pass the valid token in the header.
>> That you received when you're authenticating?
>> Yes.
>> Okay.
>> Then, I've already have Vault
address as our environment variable,
and I have this.
Just put in posh JQ for pretty output.
So, this is the secret that this container was able to read.
>> Right.
>> To verify that I'm not lying to you,
I have some secrets already pre-populated.
>> Got you. There you go.
>> So password, username, app user,
so this is exactly the same as
this container was able to read from the Vault server.
>> Perfect. So, if I needed a connection string
or whatever my application needed,
I would be able to use these commands to authentic me?
>> Right.
>> Perfect.
>> So, to make sure,
so let's say I try to read
secrets from somewhere I don't have access to.
It will say "Permission Denied" because
the Vault Server policy dictates the access.
>> Got it.
>> So this sounds like
a pretty reasonable solution for our Kubernetes users.
But then, what if you have a dozen of containers running in a pod?
So, does that means do I have to do this same thing,
authentication from every single container?
That sounds like a lot of similar repeated process.
To solve that, we also have what we call Vault agents,
which is same thing as a Vault service binary,
same binary that you download from Vault project website.
Instead of running it as Vault server,
run it as a agent mode.
What it does is, again,
so you were just running,
Vault agent runs on the client side instead of server side.
So, it does the authentication and acquire client token,
and put that token into sink.
Sink is a location where agents will put the token inside.
Then other containers within the same pod,
instead of going to the vault to authenticate,
just use that over the acquire
token to use that and put it in the header,
and make that API requests against the vault server.
>> I see.
So, you cache in your credentials essentially on the server?
>> Yes.
>> Okay. Got it. Then any of the images in that pod,
or containers running in that pod,
will then be able to authenticate It.
So, without having it re-authenticating the server?
>> Right, exactly, and vault agent will manage that.
I'm not going to have enough time to demonstrate that,
but if you want to give it a try,
it's nothing but just running in
the- We actually do have an official docker image for Vault.
So, if you want to give it a try,
run it on your pod,
just use that vault image,
the latest image, to try it and run it in a Agent mode.
We do have a learn website.
I actually have a vault agent with Kubernetes demo,
and this gives step-by-step instructions to
do exactly what I just mentioned
about what if you have a multiple pod,
multiple containers within a pod.
>> Got it. So, this help you authenticating and saw that as well.
Now, I've seen you calling out straight rest API calls.
So obviously, any language do can make a rest API call,
which is almost all of them,
could make those same calls.
But are there client side APIs
or clients that I could use if I'm already a.NET developer,
VB, or Ruby, or something? It looks like there are. Great.
>> Yes.
>> So, their libraries are going to allow me to,
they're going to obfuscate and encapsulate all that rest API
communication and I just use their API to make the same call?
>> Yes.
>> Okay.
>> If you have a special language preference.
>> Yes. So we have Ruby,
we have Go, and I think we also have some other ones too.
>> Community, C Sharp, dot-
>> Yes, C sharp and.
NET. Awesome. Cool. Well, this is great.
So though, we can make sure that
our containers secrets are just as easy to manage as our secrets
from anywhere else by being able to
authenticate the service account for
Kubernetes cluster inside of HashiCorp Vault?
>>Yes.
>> Perfect. Thank you so much.
So we're learning all about using
HashiCorp Vault inside of our containers here on Azure Friday.
[MUSIC]