Azure Key vault
- Overview of the component
- How component is accessed
- Access controls for the component
- How to deploy the component using Terraform
- An example of how to enable post-deployment configuration (if required)
- How to perform a backup and restoration
- How to conduct DR (fail-over and fail-back) and services recovery
- How to scale resources (in/out and up/down) where applicable
- How to upgrade a resource
Overview of the component
The focus of this SOP is to provide an overview of the Azure Key vault used widely in the azure environment to store secrets and keys used by different services for authentication or accessing internal services or even the admin passwords for virtual machines.
How component is accessed
The Azure Keyvault can be accessed via the Azure Portal for each Azure subscriptions where the Keyvault have been deployed.
Keyvault can be found in the Azure subscriptions by searching for ‘Key vault’ in the Azure portal
This will then load the page where all existing key vaults for the subscription(s) selected will be displayed
Search for the key vault from the list and click on the name to open the key vault control pane.
Access controls for the component
Access to these services is controlled via Azure RBAC and AAD integration. These resources only accept CRUD operations from the following user or group roles:
- Owner
- Contributor
- Custom Roles (none deployed as part of DTP but in the case of future additions)
Additionally, the f Service Principals have access to create/maintain these resources from the environment deployment for their relevant subscriptions:
How to deploy the component using Terraform
The Terraform to configure key vault is based within the following repository:
main.tf (module key-vault-rbac)
data “azurerm_client_config” “current” {}
# Create the Azure Key Vault
resource “azurerm_key_vault” “key-vault” {
name = var.name
location = var.rg_location
resource_group_name = var.rg_name
enabled_for_deployment = var.enabled_for_deployment
enabled_for_disk_encryption = var.enabled_for_disk_encryption
enabled_for_template_deployment = var.enabled_for_template_deployment
enable_rbac_authorization = var.rbac_authorization_enabled
purge_protection_enabled = var.purge_protection_enabled
soft_delete_enabled = var.soft_delete_enabled
soft_delete_retention_days = var.soft_delete_retention_days
tenant_id = data.azurerm_client_config.current.tenant_id
sku_name = var.sku_name
tags = var.tags
network_acls {
default_action = var.network_acl_default_action
bypass = “AzureServices”
#virtual_network_subnet_ids = var.virtual_network_subnet_ids
}
}
Variables.tf
##################################
# Azure Resource Group variables #
##################################
variable “rg_name” {
type = string
description = “The name of an existing Resource Group”
}
variable “rg_location” {
type = string
description = “Define the region the Azure Key Vault should be created, you should use the Resource Group location”
}
#############################
# Azure Key Vault variables #
#############################
variable “name” {
type = string
description = “The name of the Azure Key Vault”
}
variable “sku_name” {
type = string
description = “Select Standard or Premium SKU”
default = “standard”
}
variable “enabled_for_deployment” {
type = string
description = “Allow Azure Virtual Machines to retrieve certificates stored as secrets from the Azure Key Vault”
default = “true”
}
variable “enabled_for_disk_encryption” {
type = string
description = “Allow Azure Disk Encryption to retrieve secrets from the Azure Key Vault and unwrap keys”
default = “true”
}
variable “enabled_for_template_deployment” {
type = string
description = “Allow Azure Resource Manager to retrieve secrets from the Azure Key Vault”
default = “true”
}
variable “rbac_authorization_enabled” {
type = string
description = “Enabling RBAC authorization”
default = “true”
}
variable “tags” {
description = “A mapping of tags to assign to the resource”
type = map(string)
default = {}
}
variable “purge_protection_enabled” {
description = “”
type = bool
}
variable “soft_delete_enabled” {
description = “”
type = bool
}
variable “soft_delete_retention_days” {
description = “”
type = number
}
variable “network_acl_default_action” {
description = “Allow or Deny”
type = string
}
Outputs.tfvars
output “id” {
description = “Key Vault ID”
value = azurerm_key_vault.key-vault.id
}
output “uri” {
description = “Key Vault URI”
value = azurerm_key_vault.key-vault.vault_uri
}
/*
output “key-vault-secrets” {
value = values(azurerm_key_vault_secret.secret).*.value
}*/
output “kv_name” {
value = var.name
}
Whenever we need to deploy a key vault, we call the key-vault-rbac module in the code. The key pre-requisite for all these jobs is that a virtual network is deployed to take a private IP address from.
For example, a key vault is created within the alpha-platform-env-secrets-init-az repository.
main.tf
module “kv” {
source = “./modules/key-vault-rbac”
depends_on = [
module.kv_rg
#,data.azurerm_subnet.devops_snet
]
# RG details
rg_name = module.kv_rg.name
rg_location = module.kv_rg.location
# KV Details
name = lower(var.keyvault_name)
sku_name = var.keyvault_sku_name
enabled_for_deployment = var.keyvault_enabled_for_deployment
enabled_for_disk_encryption = var.keyvault_enabled_for_disk_encryption
enabled_for_template_deployment = var.keyvault_enabled_for_template_deployment
rbac_authorization_enabled = var.keyvault_rbac_authorization_enabled
tags = var.keyvault_tags
purge_protection_enabled = var.keyvault_purge_protection_enabled
soft_delete_enabled = var.keyvault_soft_delete_enabled
soft_delete_retention_days = var.keyvault_soft_delete_retention_days
#virtual_network_subnet_ids = [data.azurerm_subnet.devops_snet.id]
network_acl_default_action = var.keyvault_default_network_action
}
Variables.tf
variable “keyvault_name” {}
variable “keyvault_sku_name” {}
variable “keyvault_enabled_for_deployment” {}
variable “keyvault_enabled_for_disk_encryption” {}
variable “keyvault_enabled_for_template_deployment” {}
variable “keyvault_rbac_authorization_enabled” {}
variable “keyvault_tags” {}
variable “keyvault_purge_protection_enabled” {}
variable “keyvault_soft_delete_enabled” {}
variable “keyvault_soft_delete_retention_days” {}
variable “keyvault_default_network_action” {}
<environment>.tfvars
keyvault_name = “kayvault-name”
keyvault_sku_name = “premium”
keyvault_enabled_for_deployment = true
keyvault_enabled_for_disk_encryption = true
keyvault_enabled_for_template_deployment = true
keyvault_rbac_authorization_enabled = true
keyvault_tags = {
“Environment” = “environment-name”
“Cost Centre” = “”
“Data” = “Private”
“Department” = “department-name”
“Application id” = “”
“Application tier” = “t3”
“Application category” = “application-category”
“Region” = “uae-north”
“Maintenance” = “”
“Technical Contact” = “”
“Expiration Date” = “”
“Time Window” = “”
“Description” = “”
“Regulatory Compliance” = “”
}
keyvault_purge_protection_enabled = true
keyvault_soft_delete_enabled = true
keyvault_soft_delete_retention_days = 7
keyvault_default_network_action = “Deny”
An example of how to enable post-deployment configuration (if required)
How to perform a backup and restoration
A backup is intended to provide you with an offline copy of all your secrets in the unlikely event that you lose access to your key vault. Back up secrets only if you have a critical business justification. Backing up secrets in your key vault may introduce operational challenges such as maintaining multiple sets of logs, permissions, and backups when secrets expire or rotate.
Key Vault maintains availability in disaster scenarios and will automatically fail over requests to a paired region without any intervention from a user. If you want protection against accidental or malicious deletion of your secrets, configure soft-delete and purge protection features on your key vault.
To back up and restore your Azure key vault to a region of your choice, complete the steps that are detailed in Azure Key Vault backup.
How to conduct DR (fail-over and fail-back) and services recovery
The contents of the key vault are replicated within the region and to a secondary region at least 150 miles away, but within the same geography to maintain high durability of the keys and secrets.
If individual components within the key vault service fail, alternate components within the region step in to serve the request to make sure that there is no degradation of functionality. Clients don’t need to take any action to start this process, it happens automatically and will be transparent to them.
In the rare event that an entire Azure region is unavailable, the requests that you make of Azure Key Vault in that region are automatically routed (failed over) to a secondary region except in the case of the Brazil South and Qatar Central region. When the primary region is available again, requests are routed back (failed back) to the primary region. Again, IT teams don’t need to take any action because this happens automatically.
How to scale resources (in/out and up/down) where applicable
Azure handles the scaling and load balancing for these services so there is no requirement for client to be involved in this process.
How to upgrade a resource
This particular resource does not need to be upgraded. In the event that Azure updates their service information the resource will need to be updated based on the process outlined by Microsoft Azure for specific scenarios.