Replication RBAC¶
Replication needs read permissions on the source vault and write permissions on the target vault. This page lists the Azure role assignments required, both the built-in roles (fastest) and a least-privilege custom role (recommended for production).
Verify against your tenant
The data actions listed below are the set CertifyClouds calls on the source and target vaults. Azure's live RBAC reference is authoritative, verify this list against your specific tenant configuration before relying on it as a compliance artifact.
Identity¶
Replication uses the same Azure identity CertifyClouds is already authenticated with: managed identity, service principal, or Azure CLI. There is no separate replication identity.
You can confirm which principal your deployment is using from Settings > Azure Identity, or via:
# For managed identity deployments
az vm identity show --resource-group <rg> --name <vm> --query principalId -o tsv
# For service principal deployments
echo $AZURE_CLIENT_ID
Replace PRINCIPAL_ID in the examples below with the output of the command above.
Required Data Actions¶
These are the exact data actions the engine invokes.
Source vault (read)¶
| Operation | Data Action |
|---|---|
| Read secret value | Microsoft.KeyVault/vaults/secrets/getSecret/action |
| Read certificate metadata | Microsoft.KeyVault/vaults/certificates/get/action |
| Download certificate as PKCS12 (uses underlying secret) | Microsoft.KeyVault/vaults/secrets/getSecret/action |
| Back up a key | Microsoft.KeyVault/vaults/keys/backup/action |
Target vault (write)¶
| Operation | Data Action |
|---|---|
| Set secret value | Microsoft.KeyVault/vaults/secrets/setSecret/action |
| Read secret (conflict check) | Microsoft.KeyVault/vaults/secrets/getSecret/action |
| Import certificate | Microsoft.KeyVault/vaults/certificates/import/action |
| Read certificate (conflict check) | Microsoft.KeyVault/vaults/certificates/get/action |
| Restore key from backup | Microsoft.KeyVault/vaults/keys/restore/action |
| Read key (conflict check) | Microsoft.KeyVault/vaults/keys/read/action |
No control-plane Actions are required. Replication never creates, deletes, or modifies the vaults themselves, only the items inside them.
Option A, Built-in Roles (fastest)¶
Fastest way to unblock yourself. Broader than strictly necessary.
Source vault¶
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Secrets User" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<source-vault>
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Certificate User" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<source-vault>
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Crypto User" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<source-vault>
Target vault¶
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Secrets Officer" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<target-vault>
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Certificates Officer" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<target-vault>
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Key Vault Crypto Officer" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<target-vault>
Cert + secret overlap is expected
Azure stores the private key portion of certificates in the underlying secret store. The getSecret action appears on both the source and target data-action lists for this reason, it is not a duplicate, it's how certificate private keys are fetched.
Option B, Custom Least-Privilege Roles (recommended)¶
Two custom roles, one for source, one for target, with exactly the data actions listed above and nothing else. Use these in production.
JSON definitions¶
The canonical definitions live alongside this doc:
custom-role-source.json, data actions for source readcustom-role-target.json, data actions for target write
Deploy¶
-
Download both files.
-
Edit the
AssignableScopesarray in each file to your subscription IDs. -
Create the roles:
-
Assign to your principal:
az role assignment create \ --assignee $PRINCIPAL_ID \ --role "CertifyClouds Replication - Source" \ --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<source-vault> az role assignment create \ --assignee $PRINCIPAL_ID \ --role "CertifyClouds Replication - Target" \ --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<target-vault>
Scope the assignment to individual vaults when you can, narrower blast radius.
Verifying¶
After role assignments, run the Validate connection step in the config wizard. It verifies CertifyClouds can read from the source vault and write to the target vault under the deployment's identity, surfaces the geography of each side, and lists any RBAC gaps or soft-deleted items it found. The wizard refuses to save until validation returns clean.
If issues are reported, see Troubleshooting for how to interpret each one.
RBAC propagation lag
Azure role assignments can take up to 5 minutes to propagate. If validate fails immediately after role assignment, wait a few minutes and retry before debugging further.
Known Scope Constraints¶
- No control-plane Actions needed. Replication is all data-plane.
- No cross-subscription role design in v1. You assign at the vault level (or subscription level if you prefer) in each subscription that hosts a source or target vault.
- Same identity for source and target. If you need separate identities (e.g. different subs with different service principals), that requires a feature-flag scenario we don't support in v1.
- Tenant boundary is hard. Both vaults must be in the same Azure AD tenant. Cross-tenant replication is not supported (see index).