Deploy Azure OpenAI with Customer-Managed Keys Using Terraform and Azure Verified Modules

Why Customer-Managed Keys Matter for Azure OpenAI

When deploying Azure OpenAI Service in enterprise environments, encryption at rest is enabled by default using Microsoft-managed keys. However, many organizations operating under strict compliance frameworks — such as GDPR, financial regulations like PCI DSS, or data sovereignty requirements — need full control over their encryption keys.

Customer-managed keys (CMK) give you that control. With CMK, your encryption keys are stored in your own Azure Key Vault, meaning you can rotate, revoke, and audit key access independently. If a security incident requires immediate data access revocation, you can disable the key and effectively render the data inaccessible — something that is not possible with platform-managed keys.

For organizations handling sensitive data through Azure OpenAI — whether it is customer communications, financial documents, or healthcare records — CMK is not optional. It is a compliance requirement.

What Are Azure Verified Modules?

Azure Verified Modules (AVM) are Microsoft's official, pre-built Terraform and Bicep modules published to the public registries. Unlike community modules, AVM modules are:

• Tested — Every module goes through automated testing including unit tests, integration tests, and end-to-end deployment validation
• Maintained — Microsoft teams actively maintain and update modules to align with Azure API changes
• Consistent — All modules follow the same interface patterns, naming conventions, and best practices
• Supported — Backed by Microsoft with GitHub issues and regular release cycles

Using AVM modules significantly reduces the amount of boilerplate Terraform code you need to write and ensures your deployments follow Microsoft's recommended patterns.

Complete Terraform Deployment

The following Terraform configuration deploys an Azure OpenAI Service with CMK encryption using Azure Verified Modules for both Key Vault and the Cognitive Services account:

Running the Deployment

Once you have the Terraform configuration in place, initialize and deploy:

Key Design Decisions Explained

Purge protection is required for CMK. Azure enforces this — if your Key Vault has purge protection disabled, you cannot use its keys for CMK encryption. The 90-day soft delete retention ensures that even accidental key deletion does not immediately render your OpenAI data permanently inaccessible. This is a hard requirement from Azure, not a best practice suggestion.

System-assigned managed identity over user-assigned. A system-assigned managed identity ties the identity lifecycle directly to the OpenAI resource. When the resource is deleted, the identity is automatically cleaned up, reducing orphaned identity sprawl. For CMK scenarios, this is the simpler and more secure approach — you do not need to manage a separate identity resource.

Network ACLs default to Deny. The configuration starts with a deny-all network posture and only allows specific IPs. In production, you would replace the IP rule with private endpoints for full network isolation. Starting restrictive and opening as needed is always safer than the reverse.

Azure Verified Modules reduce risk. Instead of writing raw azurerm resources with all the CMK wiring manually, the AVM modules encapsulate the correct resource relationships, role assignments, and configuration patterns. This means fewer opportunities for misconfiguration and a deployment that aligns with Microsoft's tested patterns.

Further Reading

For more details, consult the Azure OpenAI managed identity documentation and the Azure Verified Modules registry.