>> Welcome to this week's episode of the DevOps Lab.
This week we have Rob Barnes joining us from HashiCorp,
and we're going to start off a series
talking about Zero Trust Security
with HashiCorp Vault, and Azure so tune in.
[MUSIC]
>> Welcome to this week's episode of the DevOps Lab.
On this week's episode,
we've a very special guest from HashiCorp.
Welcome, Rob.
>> Thank you so much for having me.
Really looking forward to this.
>> Really glad to have you here, Rob.
Really excited to talk about something
actually that isn't terrible with
Hashi because there are so many other cool features,
and products, and great things to talk about.
Tell us, and everyone out there
who you are, and what you do for HashiCorp.
>> Brilliant. I'm Rob Barnes.
I'm a Senior Developer Advocate here at HashiCorp,
primarily focused on the secure product line.
In this case, we are going to be talking about vault.
But, I pretty much look at
the entire workflow, and whether our security concerns.
That's what I do in my day-to-day.
>> That's awesome. Because, when we talk about DevOps,
when we talk about the Cloud,
security is number one.
It's something that as a developer you're like,
I don't really want to talk about security
but it's a super important topic,
so really glad to have you here.
Today we're going to focus on
this zero trust security with HashiCorp Vault and Azure.
Can you go ahead and kick it off.
I think today we're going to focus more
on automating some secret management.
>> Absolutely. Actually,
before we get to secret management,
what we want to do is we want to look at access to vault.
The idea here is, what we're trying to do is we're trying to
avoid secrets being sprawled everywhere.
But, it's not just the secrets that we need to
worry about, it's also Identity.
The key thing is you want to manage your secrets, and
your identity in a central place,
and in my experience,
there's no better place to store
your identity than Azure Active Directory.
What we can do actually is when we
talk about some Philae HashiCorp Vault,
rather than having to go into vault, and
create accounts for every single developer,
we can actually just use the Active Directory we have in Azure,
and pull in all the identities from there and use
the identity to authenticate with vault.
From there, you can do whatever it is
that you're authorized to do.
But, there are a few steps that you need
to do in order to make that happen.
I can share my screen, and we can have a quick look at it from
the Azure side of things the things
that you're going to need up-front.
If you can see my screen there.
What we want to do is we want to head over
to Azure Active Directory.
I've already done some of these steps here, but
what you'll want to do is you'll want to head over
to App registrations, and create
a new app registration just by clicking this link here.
As I say I've already done it,
so we'll just click in, and we'll take
a look at some of the details you are going to
need to use Azure as your identity provider.
It's all blurred out here, but we have some details which is
the application ID or
the client ID that you might be more familiar with.
You'll also need the object ID, and the tenant ID as well.
You've got those details there.
The next thing you're going to want to do is,
the process we use in to make all this work is OIDC.
In order to do that what's going to happen is
you're going to come to Azure,
you're going to login, and then once that login is complete,
it's going to have to redirect you back to vault.
You're going to have to create a couple of redirect URLs,
which you can have a quick look inside here.
I just want to evoke locally on
my machine so I've popped two URLs.
One, this is just for my browser,
it opens from my browser,
and the bottom one is if I'm using the command line,
so either way it's going to redirect me back to that.
This is basically going to be the identity, the vault uses.
Now, in order for this to work,
you need to give it some permissions.
I'll just head over to API permissions
so we can just see what's required.
This is really important that we get this right.
The permission that we need here,
if I just expand that, is GroupMember.ReadAll.
This is a least-privileged approach.
You don't need anything more than that for this.
You grab all those things there and, April,
I know you said you were happy
to see something that wasn't Terraform but actually,
we're going to configure that using Terraform.
>> That's totally acceptable.
We're automating everything, Rob.
I love it when we automate everything, so let's go for it.
>> Amazing. Cool. We'll just head over here.
If we just take a look here at this code,
the first thing we want to do in vault.
We've got all those details out of Azure,
which is what we require to configure all of this.
The first thing we need to do is we need to enable
the OIDC off method info
which we're doing with this resource here.
We'll just pop it in a few details so we grab
the client ID from the app registration that we did.
I've just got a split in the variable,
we also have the client secret which is something
else that you create with the app registration.
This is essentially like your username, and
password to get into Azure.
We're just enabling vault at this path OIDC,
and the type of auth method is OIDC.
We're going to create a vault role.
A vault role is essentially going to map to
a set of Azure permissions.
Run this resource, and
next we will do is we want to create that role.
We talked about this default row.
We're going to call it Azure, and we're going to tie
it to the off method that we've just created.
Now anyone that knows OIDC knows that under the hood it uses JWT.
J-W-T, or how do you pronounce it I'm
not really sure how people out there are announced on it.
But, we want to add some claims to the token that comes back.
We just want to add a user claim
with the Word e-mail in there, and we also want to add
a group's claim with word groups in there which
again if we go back to the Azure Portal,
you can add claims into your app registration.
If we go to token configuration,
you can add your group claims
here you can add any extra claims in.
This is always going to be contained within your JWT token.
Essentially, we're just mapping those things there.
If the token that you get back doesn't
contain these things aired, and vault is not going to
like it and essentially it's
not authenticated, because it doesn't match.
>> [inaudible] handshake, and a happy relationship then.
>> Exactly.
>> Cool.
>> That's the idea. Essentially,
what we're doing here is,
this is just some other basic settings
which we don't really need to
focus too much into
just the redirect URLs that we need specify again.
But, the key thing here is we have a couple of
vault policies we're creating.
This is what's going to permit a user to do
certain things within vault which we'll
probably get to in another episode
as to some of the things we can do.
Essentially, when you login via this off method,
is going to give you the default policy,
and it's going to give you a policy
which you create called the Azure developers policy.
That's the first step. The second thing is,
like I said we want to manage identity centrally.
We don't want to have to do everything twice.
What we're doing here is inside vault we're going to
create something called an identity group.
That's just going to map to a group in Azure Active Directory,
so we're just going to create this as an external group we have
the concept of internal, and external groups.
But because we're interfacing with Azure which is
external to vault there'll be an external group.
Essentially, to map it we create an alias.
What we're doing is we've given this alias
the id of the identity group that we just created,
we're just pulling that into shoes and Terraform.
When mounting that to the off method that we've created,
so the OIDC off method,
and we are giving it the group ID from
Azure so anytime that group in Azure is used,
it's going to map it to this group.
The point here is what happens is
in Azure and that's going to be your source of truth,
that's going to be your central place
where you are managing identity.
You just go ahead, and configure these things here.
I've actually just written all this as a module,
so I can just go ahead, and just run some code which
will switch directory, and we'll run this code.
>> No, I think it's really good Rob
that in the past when I've worked with vault,
you've had to create account, and everything.
That single source of truth Azure Active Directory which
so many people use to login to Azure but to create
an app secure handshake between
their other services is really crucial that it can
be all managed in one place especially with
group policies, and all that other good stuff.
>> Yeah exactly. For me I've as
a consultant for a joint HashiCorp,
they didn't work in any organization that wasn't
using Active Directory as their identity database.
For me it's like the core of all for you.
If you've been listening to channel you've seen
Terraform which then would be the usual, and initialize,
which is done and we're going
to do this YOLO stuff, you only live once.
>> Love it.
>> Terraform apply, and we just hit,
"Yes." There we go.
Now we have all of this configuration stored in a vault.
Now we can go ahead, and we can test this out.
If I head back to the browser,
and we go to vault, we'll just refresh
this page just to make sure there's nothing hanging over.
Then what we want to do is choose the off method which is OIDC.
As you can see it says here, "Sign-in with your OIDC provider."
When we hit that turns opens up
a new page which has taken me to Azure,
and I'm already signed in so I'm just going to accept
the permissions requests here, and that's just sign me in.
It says sign-in with OIDC provider which is great, and
this should let me in any second now, and it lets me in.
Awesome. Now the thing that's really cool about this is that
the permissions that we had added
to the default role as what we did.
We created a secret under this secrets engineer,
and if we just take a look at that.
We gave permission, so that anyone who logs
in from this group is able to see the secret here.
We have a secret called Channel 9.
Obviously, we know it works because now we can see
the guest is Rob Barnes, and the host is April.
That's a nice view there.
That's a really nice workflow that you have.
Now in terms of onboard in your organization to HashiCorp Vault,
that you don't need to sit there, and [inaudible]
spreadsheets and add people in individually, and create groups.
Again, you can manage all in one place,
if there's going to be a change make the change in Azure it
will reflect when it comes over into HashiCorp Vault.
That's for me the core of how you're going
to implement a zero-trust mindset,
is doing things centrally rather than in
so many different places. I hope you found that cool.
>> Rob that's awesome.
We see Azure Active Directory as
the backbone in so many places, and as developers we hate talking
about it but it's so critical to deploying
our apps, and our infrastructure and everything
that goes into the Cloud.
Thank you so much for showing us how to
automate the deployment of all how it's
managed by Azure AD, and it's so simple, and easy to use.
Rob thank you, and everyone join us next time for our series
on Zero Trust Security With HashiCorp and Azure.
[MUSIC]