Skip to content

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.


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:

Deploy

  1. Download both files.

  2. Edit the AssignableScopes array in each file to your subscription IDs.

  3. Create the roles:

    az role definition create --role-definition custom-role-source.json
    az role definition create --role-definition custom-role-target.json
    
  4. 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).