Functionality and Usage of Key Vault - AZ-900 Certification Course
Summary
TLDRThis lesson delves into Azure Key Vault, a secure service for managing application secrets, keys, and certificates. It emphasizes the importance of not hardcoding sensitive information in application code. The service supports three entities: secrets, keys for cryptographic operations, and certificates for lifecycle management and distribution. Azure Key Vault offers two authorization methods: traditional access policies and more granular role-based access control (RBAC). Managed identities are highlighted as a solution for authentication challenges, allowing apps to access Key Vault with built-in permissions. The video also mentions Key Vault's integration with Azure services for encryption.
Takeaways
- 🔑 Azure Key Vault is a service designed to securely store and manage secrets, keys, and certificates for applications.
- 📜 Secrets in Key Vault can be read and written, making them suitable for storing passwords or shared access signatures.
- 🗝️ Keys within Key Vault support cryptographic operations and can be generated or imported but cannot be exported.
- 📄 Certificates in Key Vault focus on lifecycle management and distribution, ensuring secure and efficient handling.
- 🛡️ High-security needs can be met by running Key Vault on top of HSMs (Hardware Security Modules) for enhanced protection.
- 🔑 Access to Key Vault is controlled through authentication and authorization, with two types: access policies and role-based access control (RBAC).
- 👤 Access policies provide permissions for users but lack granularity, applying to all entities of a certain type within the vault.
- 📋 RBAC offers granular permissions, allowing different users to have access to specific secrets, keys, or certificates with various actions.
- 👥 Role assignments can be made at the Key Vault level or at the individual entity level, providing precise control over access.
- 🐔 Managed identities in Azure can be used to authenticate applications to Key Vault without storing passwords within the vault.
- 🔄 Azure Key Vault is integrated with other Azure services, allowing for 'Bring Your Own Key' scenarios for encryption and enhanced security.
Q & A
What is Azure Key Vault and what is its primary purpose?
-Azure Key Vault is a cloud service designed to securely store and manage cryptographic keys, secrets, and certificates. Its primary purpose is to provide a secure way to store sensitive information such as passwords, tokens, and database connection strings, without hard-coding them into application code.
Why is it not secure to put secrets directly into application code?
-Putting secrets directly into application code is insecure because it increases the risk of accidental exposure or leaks. If the code is shared, accessed, or compromised, the secrets could be discovered by unauthorized parties.
What are the three types of entities supported by Azure Key Vault?
-The three types of entities supported by Azure Key Vault are secrets, keys, and certificates. Secrets are readable and writable pieces of data like passwords or tokens. Keys are cryptographic keys that can be generated or imported and used within the vault but cannot be exported. Certificates are managed for lifecycle and distribution purposes.
What is the difference between a secret and a key in Azure Key Vault?
-A secret in Azure Key Vault is a piece of data that can be both read and written, such as a password or a shared access signature. A key, on the other hand, is used for cryptographic operations and can be generated or imported into the vault but cannot be exported or taken out of the vault.
How does Azure Key Vault handle the lifecycle management of certificates?
-Azure Key Vault provides lifecycle management for certificates, which includes issuing, renewing, and revoking certificates. It also handles the distribution of certificates to ensure they are accessible to the services that require them.
What is the role of Hardware Security Modules (HSMs) in Azure Key Vault?
-Hardware Security Modules (HSMs) are physical devices designed for the secure storage and management of sensitive data. In Azure Key Vault, HSMs can be used to enhance the security of storing and managing secrets, keys, and certificates.
What are the two types of authorization methods available in Azure Key Vault?
-The two types of authorization methods available in Azure Key Vault are access policies and role-based access control (RBAC). Access policies provide permissions at a more general level for all entities of a certain type within the vault. Role-based access control allows for more granular permissions, enabling different access levels for different entities within the same vault.
Why is role-based access control (RBAC) generally preferred over access policies in Azure Key Vault?
-Role-based access control (RBAC) is generally preferred over access policies because it offers more granular permissions. With RBAC, different users or services can be given access to specific secrets, keys, or certificates within the same vault, providing a more flexible and secure access management system.
What is a Managed Identity in the context of Azure services?
-A Managed Identity in Azure is an identity for an Azure service that is automatically managed by Azure. It provides a way for applications running in Azure to authenticate to other Azure services without the need for explicit credentials.
How can Managed Identity be used with Azure Key Vault?
-Managed Identity can be used with Azure Key Vault by assigning the identity permissions to access specific secrets, keys, or certificates within the vault. This allows applications to authenticate using their built-in managed identity and access the resources they have been granted permissions to.
How does Azure Key Vault integrate with other Azure services for encryption purposes?
-Azure Key Vault integrates with other Azure services for encryption by allowing users to 'bring your own key' (BYOK) for services like storage accounts or database encryption. The keys used for encryption are stored and managed within the user's Azure Key Vault, providing control over key rotation and revocation.
Outlines
🔑 Introduction to Azure Key Vault
The first paragraph introduces the Azure Key Vault service, which is designed to securely manage and store secrets, keys, and certificates. It explains the common issue of applications needing access to sensitive information without hardcoding them into the application code to avoid security risks. Azure Key Vault supports three types of entities: secrets, keys, and certificates, each with specific capabilities and permissions. Secrets can be read and written, keys can be generated and used for cryptographic operations but cannot be exported, and certificates are managed for lifecycle and distribution. The paragraph also touches on the option to run Azure Key Vault on top of HSMs (Hardware Security Modules) for enhanced security. It concludes with an explanation of authentication and authorization methods in Azure Key Vault, including the difference between access policies and role-based access control (RBAC), with a preference for the more granular RBAC.
👤 Role-Based Access Control in Azure Key Vault
The second paragraph delves into the role-based access control (RBAC) feature of Azure Key Vault, providing a granular level of permissions that allows for different users to have access to different secrets, keys, or certificates within the same vault. It illustrates how individual access can be managed at the secret level, using 'Clark Kent' and 'Bruce Wayne' as examples to show how specific users can be given reader or user roles for particular secrets. The paragraph also addresses the common challenge of authenticating to the Key Vault, especially when the application's authentication credentials are to be stored within the Key Vault itself. It introduces the concept of 'Managed Identity' in Azure, which provides a built-in identity for compute resources that can be granted permissions in RBAC, thus solving the chicken-and-egg problem of authentication. Finally, it mentions that Azure Key Vault is often used in conjunction with other Azure services for encryption purposes, allowing for the management of encryption keys within the Key Vault.
Mindmap
Keywords
💡Azure Key Vault
💡Secrets
💡Keys
💡Certificates
💡Hardware Security Modules (HSMs)
💡Authentication
💡Authorization
💡Access Policy
💡Role-Based Access Control (RBAC)
💡Managed Identity
💡Bring Your Own Key (BYOK)
Highlights
Azure Key Vault is designed for securely managing secrets, keys, and certificates for applications.
Secrets in Azure Key Vault can be read and written, such as passwords and shared access signatures.
Keys within Azure Key Vault support generation, import, and cryptographic operations without exportability.
Certificates in Azure Key Vault focus on lifecycle management and distribution.
High Security Module (HSM) support is available for enhanced security of sensitive entities.
Authentication is required to interact with Azure Key Vault as it is an Azure resource.
Azure Key Vault offers two authorization types: Access Policy and Role-Based Access Control (RBAC).
Access Policy provides permissions for all entities of a type within the vault, lacking granularity.
RBAC allows granular permissions, enabling different access to various secrets, keys, or certificates.
Managed Identity can be used for authentication, solving the chicken-and-egg problem of storing authentication secrets.
Azure Key Vault integrates with Azure services for encryption, allowing management of encryption keys.
Key Vault supports the rotation and revocation of keys, enhancing security practices.
Individual access control can be configured at the secret level for fine-grained permissions.
The transcript discusses the practical applications of Azure Key Vault in managing application secrets securely.
Differentiating between the old style Access Policy and the more granular RBAC in Azure Key Vault.
Role assignments and permissions are detailed at both the Key Vault and individual secret levels.
The importance of Azure Key Vault in distributing and managing certificates across web servers.
Azure Key Vault's role in the broader Azure ecosystem for secure and compliant key and secret management.
Transcripts
in this lesson we're going to explore
the functionality and usage of azure key
vault
now very often we're going to have some
application
that needs
a secret it needs maybe a password
maybe it needs some kind of shared
access signature or token to access some
other service maybe i need to go and
access some database something else
and we don't want to put those secrets
within our application code it's going
to get leaked it's not secure
i might need
keys i might need to store a private key
and perform cryptographic operations
then we have a whole set of web servers
and i'm using certificates so i need to
think about how do i distribute those
certificates how do i manage the life
cycle like renew them
so azure keyboard
is a service in azure that is designed
for exactly this
it supports three different types of
entity
so we have a secret
so a secret is something that i can both
read
and write
i.e it could be a password it could be
some
shared access signature but i can
add that secret to the key vault and i
can read it back out
then there's the idea of keys
now with a key i can generate it
i can import it so i could bring in an
existing
i can perform cryptographic actions
within the key vault
but i cannot export it i cannot get it
out
it lives within that key vault
and then i have to use it via the key
vault
then there's the idea of
certificates this is really all about
kind of the life cycle management
of those certificates
and also the distribution of them
now for some of these entities i have
the option of actually running this
azure key vault and the storage and
usage on top of hsms
so hsms are actual hardware security
modules designed for the storage and
safe keeping
of these types of entity that i want to
protect so these three different types
in terms of interacting with the key
vault you obviously it's an azure
resource so i have to authenticate to it
and then i can be given permission
to these now currently there's two
different types of authorization in
azure kevo
if we jump over and look at a key vault
what we can actually see
is
we have the old style so the old style
is when i look at my security we have an
access policy
and so an access policy is really just
about the idea i can add a certain user
and i can specify what permissions they
get
but it's for each of the three types but
it's not granular
i don't have the ability
to say well i get this permission to
read a specific secret
so i have the option of access policy
but it's not granular
it would be for everything of that type
within the vault
so in that model if i wanted people to
only have access to certain secrets i'd
have to put them in a different vault to
give them that set of permissions
or
i can use role-based access control
so in role-based access control that is
granular so i can think about hey i get
a great granularity
that i could have lots of secret or keys
or certificates in a single vote and
give different people access to
different secrets to different keys to
different certificates and perform
different actions
whereas access policy
it's really no granularity
it's just hey everything
within the vault of a certain type so
generally we're going to prefer that
role-based access control option and we
can see that so if i jump over to my
other keyboard
here if i look at my access policy i've
selected to use
azure role-based access control so i'm
not configuring any permissions here
i use the regular access control
and i do role assignments
and within here i can see things like
well there's a key vault administrator
but then i actually have different
permissions
on the actual different entities
themselves so at the key vault level
well i can't really see very much
because what i've done is i have
different secrets
and at an individual
secret levels if i select secret one
it has its own access control
and here we can see on this particular
secret hey clark kent
was given
the key vault reader role
and i can also see for a key vault
secrets user
hey bruce wayne actually has the ability
to use the secrets so this particular
secret bruce wayne can use but not clark
kent clark kent just says regular key
vault reader at the kind of the azure
resource manager level but doesn't have
access to the secret itself
if i looked at my other secret secret 2
looked at its access control
well then we'll see
hey this time
key vault secrets user
is clark kent so clark kent can read
this secret and not bruce wayne so we
get this really nice granularity
that we can do
now
one thing that's actually super common
is obviously i have to authenticate to
the keyboard in the first place i have a
chicken and egg problem i can't store
the password in the key vault that the
app's going to use to authenticate to
the keyboard
so a very common
combination of technologies is if this
was running in azure there's something
called managed identity
so managed identity is an identity that
is tied to
a particular instance of a compute
resource
and then what i could actually do as
part of this rbac for example or the
policy
i could give the apps managed identity
which is built in it's just available as
a token it can leverage
i would give that identity so app one's
managed identity some of these
permissions
so it's authenticated with its built-in
managed identity
and then it gets permissioned to
whatever its identity was given access
to
so that's really the idea
no azure key vault is also used by a lot
of azure functionality a lot of services
will let you bring your own key for
example to encrypt a storage account um
for a database encryption
when you bring your own key what it's
actually doing is it's that key is in
your key vault so you have management of
the key you can pick when to rotate it
when to revoke it
so if you do bring your own key what's
actually happening is
it's going to use azure key vault for
that so hey if i have the need for
secrets or keys or certificate
management in azure
i'm going to use azure keyboard
Посмотреть больше похожих видео
Azure DevOps Workload Identity Federation with Azure Overview. NO MORE SECRETS!
HashiCorp Vault Secret Engine and Secret Engine path - Part 4 | HashiCorp Vault tutorial series
Introduction to HashiCorp Vault with Armon Dadgar
Building a Multi-tenant SaaS solution on AWS
Upgrading SharePoint apps from Azure Access Control service to Azure Active Directory
Benefits and Usage of Serverless Technologies - AZ-900 Certification Course
5.0 / 5 (0 votes)