Azure Key Vault Overview Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
14 hours 28 minutes
Difficulty
Intermediate
CEU/CPE
15
Video Transcription
00:00
>> Hello, Cybrarians.
00:00
Welcome to Lesson 2.2,
00:00
of Module 2 of this course titled is
00:00
AZ -301 Microsoft Azure Architect Design.
00:00
Here are the concepts that we'll
00:00
be covering in this video.
00:00
We'll start out by covering the differences between
00:00
the management plane and
00:00
the data plane of Azure Key Vault.
00:00
I'll be highlighting to you,
00:00
best practices around least privilege access
00:00
to sensitive keys and secrets.
00:00
I'll then cover the integrations that Microsoft
00:00
has built between Azure Key Vault and
00:00
other services in Azure and even beyond
00:00
services in Azure to other Microsoft services.
00:00
Finally, I will talk about what managed identity is,
00:00
the different types of managed identity,
00:00
and how it helps developers who needs to write codes,
00:00
that make use of secret keys and
00:00
certificates that are stored in Azure Key Vault.
00:00
Let's get into this.
00:00
Key Vault has two service tiers,
00:00
the standard service tier,
00:00
and the premium service tier and we have to select
00:00
the option that we want at the time of deployment.
00:00
Now, both of
00:00
these service tiers have similar functionalities,
00:00
with the exception of one main difference.
00:00
The standard service tier supports
00:00
only software-protected keys,
00:00
while the premium service tier supports
00:00
both the software and HSM-protected keys,
00:00
which means the main advantage for going for
00:00
the premium service tier is not
00:00
necessarily in terms of functionality,
00:00
but in terms of compliance.
00:00
One of the key concepts to
00:00
understand about Azure Key Vault,
00:00
it's the separation between
00:00
the management plane and the data plane.
00:00
This understanding is very critical to truly
00:00
unfathom the principle of
00:00
least privilege for your Key Vault resources.
00:00
What do I mean by this?
00:00
On the right-hand side, I have
00:00
an Azure Key Vault resource,
00:00
and on the left-hand side,
00:00
I have two roles within an organization,
00:00
security administrator and the application developer.
00:00
The security administrator in this case,
00:00
is responsible for proper safekeeping of secrets,
00:00
while the application developer just
00:00
simply wants to write their code and write
00:00
their applications to be able to
00:00
make use of certain resources that have
00:00
certain keys or secret or
00:00
certificates that may be stored in a key vault.
00:00
The security administrator may
00:00
require permission to be able to see the login for keys,
00:00
secrets, and certificates who is making calls for
00:00
setting operations to these different items.
00:00
While the application developer just simply needs the URI
00:00
or the codes to be able to
00:00
access these items in the Key Vault.
00:00
To be able to achieve this separation,
00:00
what we can do is we can assign
00:00
permissions to the security administrator
00:00
on the management plane using role-based access control.
00:00
That's how we give permission to
00:00
the management plane of Azure Key Vault.
00:00
That in itself does not grant permissions into
00:00
the data plane or into
00:00
the items that are stored
00:00
within the Key Vault, so that's great.
00:00
Then we can give the code that
00:00
the application developer is
00:00
creating or wherever they're running the code,
00:00
we can give that access into
00:00
the data plane using something called access policy.
00:00
That's how the data plane
00:00
access is controlled using, access policy.
00:00
Let's talk about Azure services supports that are
00:00
natively built-in with Azure Key Vault.
00:00
Let's start by talking about keys.
00:00
There are certain services in
00:00
Azure that are encrypted at rest.
00:00
The encryption key that they use by default,
00:00
are Microsoft-managed keys and Microsoft gives us,
00:00
in some cases,
00:00
the option to be able to use customer-managed keys.
00:00
That is where Azure Key Vault comes in
00:00
because for the services that you can see on the screen,
00:00
there's integration with Azure Key Vault so
00:00
that the keys that they use can be
00:00
stored in Azure Key Vault
00:00
and the keys can be managed by the customer.
00:00
For example, an Azure storage account by default,
00:00
it's encrypted with Microsoft managed keys,
00:00
what we can do is we can go ahead and just select
00:00
a single option to
00:00
switch that over to customer-managed key,
00:00
specify our Azure Key Vault,
00:00
and then give the storage accounts service permission to
00:00
be able to retrieve the encryption key
00:00
from Azure Key Vault.
00:00
That key is managed by the customer in this case,
00:00
the same goes for the other
00:00
services that you see on the screen.
00:00
Now, with something like Azure disk encryption,
00:00
which uses BitLocker if you're using
00:00
Windows and uses LAN Crypt if you're using Linux.
00:00
The keys for the encryption can
00:00
also be stored directly into Azure Key Vault.
00:00
Let's talk about secrets.
00:00
There's also opportunity to be able to
00:00
use customer-managed secrets in this situation.
00:00
For example, I showed you a slide earlier,
00:00
where whenever you're deploying a virtual machine,
00:00
we can supply an administrative password
00:00
that the virtual machine will be using,
00:00
by simply passing a Key Vault reference into
00:00
our parameter file in Azure ARM template
00:00
and the same goes for the other cases
00:00
that you see on the screen.
00:00
Customer can supply admin password,
00:00
for a SQL database that it creates
00:00
directly via Azure Key Vault.
00:00
Customer can supply place secretes
00:00
into Azure Data Factory scopes and
00:00
customers can supply secretes
00:00
into Azure Kubernetes Services containers.
00:00
When it comes to certificates,
00:00
Azure Key Vault supports certain services to be able
00:00
to retrieve certificates directly from Azure Key Vault,
00:00
and that is the case that you are seeing here.
00:00
Services like Azure API management, CDN,
00:00
application gateway, Azure Web App, Azure Functions,
00:00
and Azure Kubernetes Services containers can directly
00:00
retrieve the certificates from Azure Key Vault.
00:00
Let's talk about Azure Key Vault
00:00
and managed service identity.
00:00
This is one of those topics that I could have
00:00
covered on the Azure Active Directory
00:00
by thing that one of the most popular used cases
00:00
of Managed Service Identity is
00:00
integration with Azure Key Vault,
00:00
which is why I'm covering it in this section.
00:00
Take a situation, for example,
00:00
where I have an Azure Key Vault with my keys, secrets,
00:00
and certificates in it and I
00:00
have certain resources in Azure like Azure Function,
00:00
Azure Virtual Machine,
00:00
or Azure Web App that host in my code.
00:00
And my code needs to be able to retrieve
00:00
certain secrets within the Key Vault.
00:00
The old way to go about that is,
00:00
I'll go to Azure Active Directory,
00:00
which is what Azure Key Vault trusts and
00:00
uses and I'll create a service principal,
00:00
which will have an ID and a key.
00:00
I'll then reference the ID and the key in my code,
00:00
which my code can then use the ID and
00:00
the key to authenticate against Azure Active Directory.
00:00
Once it's been authenticated,
00:00
screen will transform that into a token.
00:00
Then the token can be used to gain
00:00
access to the value of the secret or the key or
00:00
the certificates that's stored in
00:00
Azure Key Vault and that'll be
00:00
controlled via an access policy.
00:00
That's the way that will have
00:00
operated before we have managed service identity.
00:00
But what does that look like with
00:00
Managed Service Identity? Let's have a look.
00:00
The same scenario, but in this case what
00:00
happens is my code is still running on an Azure service,
00:00
provided I'm creating a service principal,
00:00
I can simply associate and manage
00:00
identity with the service that my code is running in.
00:00
What it allows me to do is that my code,
00:00
whenever it need to access
00:00
that item in Key Vault
00:00
can simply make a local metadata call,
00:00
which will automatically authenticate against
00:00
Azure AD and my code ends up
00:00
getting a token which can then be used
00:00
to access the item in the Key Vault.
00:00
You may be thinking, what's
00:00
the difference between these two.
00:00
The difference is that saves me from having
00:00
to create a service principal and
00:00
referencing that service principle within my code.
00:00
Also I have to manage
00:00
the lifecycle of that service principle.
00:00
In this case, this is managed for me cause I can
00:00
simply associate an identity
00:00
to my service where my code is running in and I can
00:00
give that service permission to
00:00
certain items in the Key Vault.
00:00
Let's talk about the difference between system
00:00
assigned versus user-assigned managed identity.
00:00
These are the two types of
00:00
managed identities that we have in Azure.
00:00
Take a situation where I have
00:00
my code running across multiple resources,
00:00
as you can see on the screen.
00:00
If I'm going to be using system-assigned managed identity
00:00
there's more work to do.
00:00
The first thing I'll need to do is, I will
00:00
need associate
00:00
system-assigned managed identity to
00:00
each resource where my code is
00:00
running on and I'll then need to grant each
00:00
system-assigned managed identity permissions
00:00
using access policies to
00:00
the information in the Key Vault.
00:00
This has to be done individually.
00:00
My code can then make
00:00
local metadata call to retrieve the token,
00:00
which can then be used to access
00:00
the information in Azure Key Vault.
00:00
In this scenario, what I've ended up doing this,
00:00
I've ended up using two system-assigned
00:00
managed identities and
00:00
two access policies for the permissions.
00:00
Now, let's say I have 10 resources,
00:00
that means I'll need
00:00
ten system-assigned managed identities,
00:00
and ten access policies to grant permission.
00:00
Now, let's compare that
00:00
against user-assigned managed identity.
00:00
In this scenario, I'll simply have to create
00:00
one user-assigned managed identity.
00:00
I can then associate that user-assigned
00:00
managed identity with my resources
00:00
that I have run in my code.
00:00
I can also simply give this
00:00
user-assigned managed identity permission,
00:00
use an access policy
00:00
into the information in the Key Vault.
00:00
It's the same scenario of my code,
00:00
makes a local metadata call to restrict talking,
00:00
which can then be used to access
00:00
the information within the Key Vault.
00:00
But in this case,
00:00
I've used a single user-assigned managed identity
00:00
and a single access policy,
00:00
which means less management work for me to do.
00:00
You can see that's user-assigned
00:00
managed identity skills well when you're
00:00
talking about a scenario like this.
00:00
Let's do a quick review of what we've covered so far.
00:00
We've discussed an overview of Azure Key Vault.
00:00
We've also covered what a secret is, what a key is,
00:00
and what a certificate is as
00:00
far as Azure Key Vault is concerned.
00:00
We've looked at the differences between
00:00
the management plane and the data plane in
00:00
Azure Key Vault and how that helps us to
00:00
enforce the principle of least privilege.
00:00
We've done a view of
00:00
Azure services integration that
00:00
Azure Key Vault supports,
00:00
and finally, we've looked at
00:00
Azure Key Vault and managed identity.
Up Next