Key Vault to Key Vault Replication (PRO + ENTERPRISE)¶

Replicate Azure Key Vault items, secrets, certificates, and keys, from a source vault to a target vault within the same Azure tenant. One general-purpose feature covers three real use cases:

• Disaster recovery: keep a warm secondary vault in a different region
• Environment sync: promote curated items from dev to staging to prod
• Regional redundancy: reduce latency for geo-distributed workloads

When to Use Replication¶

How It Works¶

Source Vault                                Target Vault
┌─────────────────────┐                     ┌─────────────────────┐
│ prod-eu-kv          │                     │ prod-us-kv          │
│                     │                     │                     │
│ ├── db-password ────┼──── replicate ─────►│──► db-password      │
│ ├── api-key ────────┼──── replicate ─────►│──► api-key          │
│ ├── tls-cert ───────┼──── import PFX ────►│──► tls-cert         │
│ └── signing-key ────┼──── backup/restore►│──► signing-key      │
└─────────────────────┘                     └─────────────────────┘
                           │
                           ▼
                  CertifyClouds engine
                           │
                  1. Expand vault pair into per-item records
                  2. Check conflicts on first write
                  3. Push to target via SDK
                  4. Record history + audit

Expansion Model¶

A replication config represents a source → target vault pair with a rule (e.g. "all tagged with replicate=true"). On save, the expander walks the source inventory and creates one record per matched item. Records are what actually sync. This means:

• The records table shows exactly what will move, per item, with its current status
• Excluded items, soft-deleted source items, disabled items, and cross-geography keys appear with their blocked_* reason and are never attempted silently
• Flap protection: an item has to go missing for two consecutive expansion cycles before its record is disabled. Recovered items auto-reactivate

Per-Item-Type Flow¶

Key replication is same-geography only. Azure's backup/restore operations are not cross-geography. CertifyClouds blocks cross-geography key replication up front (see Troubleshooting → cross_geography_key).

Wizard Walkthrough¶

Navigate to Automation > Replication & Sync > Create config. The wizard is seven steps.

1. Target Type¶

Pick Azure Key Vault. AWS Secrets Manager, Parameter Store, ACM, GCP Secret Manager, and GCP Certificate Manager are the non-Azure sync targets, this page is specifically the Key Vault → Key Vault flow.

2. Source Vault¶

Cascading dropdowns for subscription → vault name. Only subscriptions and vaults CertifyClouds has already discovered appear, if a vault is missing, run a Discovery scan first.

3. Target Vault¶

Same selector for the target. Target vault must differ from source.

4. Validate Connection (required gate)¶

The wizard validates the connection server-side before allowing save. The validation result shows:

• Source geography and target geography badges
• Whether CertifyClouds can read from the source vault with its current identity
• Whether it can write to the target
• Whether source and target are in the same geography (affects key replication only)
• Any RBAC gaps or soft-deleted items

You cannot save the config until this step returns green. If it doesn't, see RBAC for the required role assignments.

5. What to Replicate¶

Two choices on this page:

Item types: checkboxes for secrets, certificates, keys. At least one must be selected.

Rule: how CertifyClouds decides what's in scope:

Tag rules evaluate a single tag only, no AND/OR composition in v1.

6. Behaviour¶

• overwrite_on_conflict: default false. When false, the first write to a target that already has an item with the same name blocks with target_conflict_active and requires explicit acknowledgement. When true, conflicts are overwritten immediately (source is truth).
• propagate_deletes: default false. When true, deleting an item on the source deletes it on the target on the next cycle.
• Sync interval: 5 minutes to 24 hours, default 24h. This is the expansion + sync cadence. Manual triggers are always available.
• Alerts: opt-in to email/webhook alerts for repeated failures, cross-geography blocks, and conflicts.

7. Preview¶

The wizard previews up to 1000 items with the status each would take (active, blocked by conflict, blocked by cross-geography key constraint, excluded by rule, etc.). Use this to sanity-check the rule before saving.

If the preview times out, the table is marked partial and the config falls back to a full expansion on the next worker cycle.

Operating the Feature¶

Manual Triggers¶

• Replicate now (per record) - re-syncs one record. Labelled Retry when the last attempt failed.
• Replicate now (toolbar) - syncs all enabled records on the config.
• Re-expand rules - re-runs the rule expander against the current source inventory. Audit-logged.
• Acknowledge conflict - explicit click to unblock a record stuck in conflict state. Single or bulk.

Deletion Propagation¶

Opt-in per config. When on:

• Source item deleted → target item soft-deleted on next cycle
• Source item soft-deleted (still recoverable) → target is not touched (source items that are soft-deleted are skipped, not replicated as deletes)

In-app purge of target items is not exposed in v1, blast radius is too high. If a soft-deleted target is blocking a first write, the UI provides an Open Azure Portal ↗ deep-link to the target vault's deleted items blade for manual purge.

Correlation IDs¶

Every expansion and sync carries a correlation ID. You'll see it in:

• The X-Correlation-Id response header
• WebSocket event payloads
• Audit log context.correlation_id
• Backend log lines for the run

When opening a support ticket, quoting the correlation ID lets us pull the exact run out of logs immediately.

Limitations¶

The following are not currently supported:

• Cross-tenant replication: same-tenant only
• Bidirectional replication: source is always source-of-truth
• Cross-geography key replication: Azure backup/restore is same-geo only; applies to software and HSM keys alike
• Certificate policy or issuer replication: only current material is replicated; target certs import with issuer_name="Unknown" so no renewal attempts run from the target
• Key / certificate / secret version history: latest version only
• Event Grid push triggers: interval polling only
• BYOK workaround for cross-geography keys
• Forced purge of soft-deleted target items: use the Azure Portal deep-link
• AND/OR tag rule composition: single tag only
• Per-record scheduling: config-level interval only
• In-app purge of target items

Related¶

• RBAC reference, required Azure role assignments for source and target
• Troubleshooting by error code, every stable error code with a fix
• Custom role JSON: source
• Custom role JSON: target