Ever wonder how you can securely store
your digital identity information?
Well, Azure Key Vault has got you covered
and I’m going to tell you all about it.
Coming up now.
Hello, everybody.
My name is Adam Gordon, an edutainer here at ITProTV,
back with another exciting episode
on our 'What is Azure?' serial.
In this conversation,
we are going to talk about the Azure Key Vault.
We always answer three questions
about the service that we're focusing on.
What is it?
Why would you want to use it?
And, of course, how can you actually deploy the service
or feature that we are going to be focusing on?
Let's begin by jumping in
and talking about what the Azure Key Vault is.
It provides secure cryptic graphic storage for us.
That may sound like a mouthful, and it is.
But, what it really means, is that it allows someone,
like our Power User sitting down here to go ahead,
and once the Key Vault is created,
use it to safely put important stuff away,
and have it stay there,
so they know definitively that only authorized applications
can access that information, to prove their identity
when they are interacting with the Azure directory.
I've got some examples of things
that would typically be stored in the Key Vault;
a certificate for instance.
Perhaps a password or a passphrase, or an actual key.
Pretty good we named it the Key Vault,
considering we put keys into it.
Not the kind of key you have on your key-ring,
not the kind of key you use to start your car,
but part of what we would think of as a key set or key pair.
A private key that is going to be known only to the issuer,
the person that creates the key, or uses it.
As a result, or if it's a public-private key pair,
part of a key set can be used to securely identify us,
show other people who we are, and or, allow other entities
like applications to securely access resources by using this key.
This may be an API key,
a service key that is available and stored here,
that an application can use to securely interact with,
and access and provide services.
Any and all of these things take place in the Key Vault.
This is really what the Key Vault provides to us.
Now, there is a little gotcha with the Key Vault.
It's really not a big deal, but it is something to call out
when we are talking about what it is.
There are two types of Key Vaults that can actually be deployed.
We have what is known as a Standard Key Vault,
which essentially would do what I just described to you,
using the Manage Services, which Microsoft provides,
and you pay a premium for any kind of service
as an add-on when you use Azure.
So there is a small additional fee to be able
to bring Key Vaults in and use them, but it is pretty minimal.
But, when you use a standard Key Vault, we get basic services.
But, the Key Vault is hosted by Microsoft,
on infrastructure that other tenants,
other Azure customers may use.
The Key Vault is dedicated to you,
to your Azure Active Directory, to your applications.
You are going to have exclusive use of it,
but it is going to co-mingle and co-exist
with other tenants' Key Vaults.
We are not worried about that;
Microsoft does a really good job of security.
We just want to know that it does live that way.
If we think about the second kind of Key Vault,
what is called an HSM,
a Hardware Security Module backed Key Vault.
This is a premium level Key Vault.
Again, we pay an up-charge for that.
We get a dedicated piece of hardware,
this external little USB thumb drive,
you can almost think of it like.
That stores the Key Vault
and all the information we put on it separately,
so that we have a little additional security
if we need that level of security.
We have dealt with what the Key Vault is,
the kind of services that it may be able to provide.
It really helps us begin to shift, and answer the question,
why would we want to use it?
Perhaps a developer, just like the one sitting down here,
has gone ahead and created an application for us, right?
It is going to be pretty important.
We like applications on the Azure platform.
They are web-enabled,
available for users both inside of our Azure Active Directory,
so users that are going to be inside of our organization.
Potentially can also be available to users outside,
depending on how we chose to set them up.
If we are thinking we are just going to limit
the use of the application to internal users,
then this application has to have its own identity.
Has to be called something other than just 'The Application'.
It has to prove its identity,
so we can securely interact, use and it,
and maybe securely provide services as we suggested.
It can do that by leveraging the Azure Key Vault.
By using that password; that certificate,
that API service key that may be stored,
or that we can store there, in relation to the application.
So the 'why' of the Azure Key Vault,
is that it expands our ability to offer secure services,
like Applications to our internal users,
and potentially beyond that, to anybody;
customers from outside
that may also want to consume these services.
Now, we have to connect the Key Vault
to the Application on the Azure Active Directory,
to let them communicate, once we create the Key Vault,
and store the information there.
We have authentication requests
that the Application may make, and need access
to these resources to facilitate.
So we would typically draw a line coming over this way.
We would make this line bi-directional,
indicating this flow the Key Vault
and the Azure A.D are interacting.
But the reality is, the line passes through the Application
on its way to the Azure A.D.
I just didn't want to nick my cloud at the top there.
It took so long to draw it and make it perfect for you.
But you can imagine that what we are actually seeing
is this communication taking place here, bi-directionally
we would imagine a line that goes straight through.
By doing that, we are allowing the application
to securely access those resources
that allow it to identify itself,
and to use them in relation to the Azure Active Directory,
to interact with users when they consume services.
We have seen the 'what', we have talked about the 'why'.
Now what we need to do is go take a look at the 'how'.
I'm going to show you exactly
how to deploy an Azure Key Vault, and the steps involved
to make it something you can actually use.
Alright everybody, so we are jumping into the 'how'.
How do we actually deploy the Azure Key Vault?
I got an Azure resource group already set up for us,
I call it Azure K.V,
just so we know what it's going to be used for.
I am just going to zoom in, in just a sec
and show you exactly what we're going to do.
We are going to use our add capability
right at the top of our toolbar there.
We are going to search in the Azure Marketplace,
look up the Key Vault,
and begin walking through the wizard to do the deployment.
Let me just zoom in here.
You can see our Azure K.V resource group.
We are going to click add, we are going to go to the Marketplace.
This is just the area where all of the Azure services
and feature capabilities are available.
We don't see what we want automatically,
we can browse by category.
We can just start typing in, in the search area here,
what it is we want, and sure enough,
you can see as I do that, anything with the word 'Key',
and the word 'Vault', and it shows up.
We are going to choose Key Vault.
This is the Microsoft Key Vault Solution.
That's the icon we are looking at.
We are going to be able to see a little bit of an overview here
if we want more information.
What the plans are in terms of the standard
versus the premium that I mention, and we can click create.
We are going to go ahead and do that.
When we click create,
we are going to get our little multi-tab wizard
that we often use for many of these activities.
We are going to go ahead, scroll down.
We are going to note here,
even though we are not going to be able to...
need to make I should say,
a decision about a resource group
because we are already starting out in one.
We do have the option to create a new resource group
if we need to.
We want to give our Key Vault a name,
specify our region, and the pricing tiers
where we make the choice
between standard and premium, to get that HSM,
that Hardware Security Module Backed Key Vault,
if we need a more secure one.
A more compliant one, with some of the higher-level standards.
I am going to give this a name,
let's just call this 'courtneykv1'.
I just want to make sure that we see that green check
at the far right-hand side,
indicating that the name is unique and we are good to go.
We've got that.
We are then going to come down here,
just take a look quickly at our pricing tier option,
and notice we do have standard and premium,
which does have the HSM backed capability.
We always can go in
and use our little information dialogue there,
to get more information, follow a link typically,
and find our pricing and any kind of details we may need.
We do have the ability here to specify, at the bottom,
under our soft delete area, which is enabled by default.
Meaning we will retain a copy of that key
for a period of time if we chose to.
We do see days to retain deleted faults.
Meaning we have the ability to come back
and get that information back if we inadvertently delete it.
Default is 90 days, we can modify that,
choose what we want to put there.
You can accept the default to modify them.
We have purge protection.
Notice it is disabled by default, allowing the Key Vault
and the objects to be purged during the retention period.
Meaning, anytime between those 90 days, I can go in.
You know, I just want to get rid of it,
I don't want to wait the 90 days until it's gone.
That would allow me in the default setting to do that,
but I can enable essentially a blocking protection.
When I enable, what that does it...
it says, during the retention period,
you cannot go in and delete that Key Vault and the Keys
until that period is expired.
This may be necessary
because of the regulatory and statutory concerns.
You may need to enable that feature.
Microsoft notes for us at the bottom,
which once we turn on that purge protection,
we are not able to disable it,
meaning that it is permanently available,
and attached to the Key Vault.
So, just act accordingly
and make sure you make a wise choice here.
Right, so we have done our options here,
just going to go ahead and go to the access policy tab.
This is where we can decide what kind of services we want
the Key Vault to be made available for,
to have interaction with the Key Vault.
Things like virtual machines can leverage the Key Vault.
The Azure Resource Manager can use it for secure deployments.
The disk encryption capability,
to be able to encrypt the hard drives
or elements on certain virtual machines
that have to be encrypted, can also leverage the Key Vault,
and get those secure keys necessary
to do the encryption and access them.
So we can specify those options if we want to,
simply by checking off one or more of them
and making a selection.
We then have to choose our permission model.
Do we want to use the Vault access policy
and grand additional access elements
by using the add access policy,
and add users into our system services identities?
In other words, that can access the Key Vault.
I will show you what that looks like down below.
Or, there is a new option called Azure Role-Based control.
We can use pre-existing controls
that are defined in the Azure Active Directory
and have those be the elements that drive access
to the Key Vault.
It is up to us to decide.
If I chose the Vault Access Policy,
you will see that by default,
I have already got my assigned user,
my alias, o365guy in there.
I've got key permissions that are selected.
Secret permissions that are selected.
Certificate permissions that are selected.
I can assign and define those as needed for individual users,
stacking them up, granting them access.
We are then going to go to our networking area.
We specify our networking capability here,
what kind of connectivity method do we want to use.
Public endpoint, meaning all networks can see,
interact with the Key Vault.
Public endpoint only selecting networks
from within the list that I will be providing.
Or, private endpoint, meaning it can only be a network,
a private network that...
as you can see, I can specify here
that it is going to allow access to this resource,
probably for a small group of virtual machines
or applications, maybe in a select area.
You can think of this as almost like assigning its own sub-net,
if you are familiar with sub-nets in your infrastructure.
We would do that when we want to narrowly define
how we are going to grant access.
So we make our appropriate choice here.
Then, if we want to use meta-data tags
to identify the Key Vault, we can do that.
Now we click review and create, we wait for validation to run.
We always like to see the green box
that shows validation has passed, meaning we are set to go.
We have a nice summary of everything
we are going to have happen here.
We come down here, we click create.
Within about thirty seconds to a minute,
our Key Vault becomes available.
We can begin to use the Key Vault
for any number of solutions that we have defined
and or business cases that match the criteria
and the services that the Key Vault is going to make available.
For more information on how to use the Key Vault fully,
and see how to develop solutions with its end to end.
Can always check me out at ITProTV,
where we have a full selection
of different Azure courses available for you,
until I come back with another exciting
'What is Azure?' serial episode.
I am going to wish you happy Azuring, and I will see you soon.