Manage Key Policies on Confluent Cloud for Azure

This document provides guidelines for managing key policies for self-managed encryption keys (BYOK) in Confluent Cloud for Azure.

When you create keys in Azure Key Vaults, you must:

• Use an software-protected (RSA) key or HSM-protected (RSA-HSM) key.

• Enable purge protection. This enforces a mandatory retention period for deleted vaults and vault objects.

• Enable Azure RBAC for access to the key. Confluent creates a customer key-specific Microsoft Entra ID on our site. Use the CLI snippet provided to create matching role assignments in Azure for:

  • Key Vault Crypto Service Encryption User

  • Key Vault Reader

• For Dedicated clusters, if you have network restrictions, enable Allow trusted Microsoft services to bypass this firewall?

• For Enterprise clusters, you must configure the Firewall and virtual networks settings (under Networking) in your Azure Key Vault to Allow public access from all networks to enable Confluent Cloud access.

Update an Azure Key Vault access policy

Avoid key policy updates

Because key policy misconfigurations can cause immediate cluster unavailability and service disruption, it is recommended that you avoid updates.

Follow these steps to safely update your Azure Key Vault access policy without disrupting your Confluent Cloud cluster operations:

Prerequisites

• Administrative access to your Azure account and Key Vault service.

• Current working backup of your key policy.

• Planned maintenance window for policy updates.

• Understanding of the required Confluent permissions.

Procedure

1. Create a backup of your current working access policy. You can retrieve the current policy using the Azure CLI:

   az keyvault show \
     --name <your-key-vault-name> \
     --query properties.accessPolicies \
     > key-vault-access-policy-backup-$(date +%Y-%m-%d).json
   

2. During your planned maintenance window**, apply the policy update:

   az keyvault set-policy \
     --name <your-key-vault-name> \
     --object-id <your-object-id> \
     --key-permissions <permissions>
   

   For more information, see the az keyvault set-policy documentation.

3. Verify your cluster is still operational:

   • Check cluster status in the Confluent Cloud Console.

   • Verify producers and consumers are still functioning.

   • Monitor for any error messages or alerts.

   • Check Azure Monitor logs for any access denied errors related to your Key Vault:

     az monitor log-analytics query \
       --workspace <workspace-id> \
       --analytics-query "AzureDiagnostics | where ResourceProvider == 'MICROSOFT.KEYVAULT' and OperationName == 'KeyGet' and ResultType == 'Forbidden'" \
       --out table
     

4. Monitor your cluster for at least 30 minutes after the policy update:

   • Watch cluster metrics and health indicators.

   • Check for any encryption-related errors.

   • Verify that automatic operations (like scaling) continue to work.

   If you encounter problems after updating the access policy:

   • Immediately restore the backup policy.

   • Monitor cluster recovery for up to 30 minutes.

   • Contact Confluent Support if the cluster doesn’t recover after restoring the original policy.