Dependencies (PRO + ENTERPRISE)¶

Dependencies maps which Azure resources consume Key Vault credentials, enabling blast radius analysis and coordinated full-stack rotation.

Overview¶

Dependencies solves a critical question: "If I rotate this secret, what breaks?"

• Resource discovery: Find all Azure resources that use Key Vault credentials
• Dependency mapping: Map credentials to their consumers
• Blast radius analysis: Understand impact before rotation
• Full-stack rotation: Rotate credential AND update all dependent resources
• Best-effort rollback: Attempt to restore previous state if any update fails (success depends on the resource type; some Azure resources don't support clean rollback - see the per-resource notes below)

Supported Resource Types¶

Dependencies discovers and maps across Azure compute, integration, messaging, data, and DevOps resource types for blast-radius visibility. Automated full-stack rotation is currently available for a subset (App Services, Function Apps, Container Apps, SQL Servers, and Azure DevOps service connections and variable groups); the remaining types are discovered and mapped so you can see what will be affected, and rotation for those is coordinated manually using the dependency graph.

Compute¶

DevOps¶

Integration¶

Messaging¶

Data¶

How Dependency Mapping Works¶

Discovery Phase¶

CertifyClouds reads the settings of supported Azure resources (app settings and connection strings), finds the Key Vault references in them, and links each one to the secret it points at.

Match confidence¶

Each discovered mapping is graded High / Medium / Low based on how strong the link between credential and resource is - exact Key Vault references are highest confidence, looser inferred matches are lower. Lower-confidence matches surface in the UI with a "Verify before acting" hint so customers can review before automating around them.

Viewing Dependencies¶

Dependency Graph¶

1. Go to Assets tab
2. Click on a vault
3. Select a secret
4. View Dependencies panel

The dependency graph shows:

• Secret at the centre
• Connected resources (App Services, Functions, etc.)
• Confidence indicators
• Resource health status

Blast Radius View¶

The blast radius opens as a side panel from either table, so you never leave the list you were working in:

1. On Resources, expand a resource and click one of its credentials; or on Mappings, click a row
2. View all resources that would be affected
3. Review confidence levels, verify any unverified dependencies, and rotate from the same panel
4. Close the panel to return to the table

The open credential is part of the page URL, so a blast radius can be bookmarked or linked to directly.

TLS endpoints and Key Vault certificates¶

The TLS Endpoints list is on every tier. On PRO, CertifyClouds also links each endpoint that serves a Key Vault certificate to that certificate:

• Assets → Scan → TLS Endpoints gains two columns: Key Vault certificate (the certificate the endpoint uses) and Picks up renewal?
• On the Key Vaults sub-tab, a certificate that endpoints use shows Used by N endpoints. The link opens the certificate's Dependencies tab, which lists those endpoints and whether each picks up a renewal.
• An expiry alert for a Key Vault certificate names the endpoints that use it.

Compliance rule T004 fails while an endpoint serves an old version of its Key Vault certificate.

Verifying Dependencies¶

Before a dependency can be included in automated rotation it must be verified - a live check that the resource still references the credential.

• Verify (per row) re-checks a single dependency
• Verify all re-checks every unverified dependency at once
• Verified dependencies show a Verified badge

Verification is persistent: it holds until the mapping materially changes or the dependency is re-verified. There is no rolling expiry, so verified dependencies stay eligible for unattended automation.

Verification Gate¶

Auto-Rotate and Custom Value rotation stay disabled while any dependency in the blast radius is unverified. Rotation enforces the same rule - only verified dependencies are updated during full-stack rotation.

Broken Dependencies¶

If verification fails (the resource no longer references the credential), the dependency is marked broken. A broken dependency returns to active automatically when a later resource scan finds the reference again - re-verify it to make it rotation-eligible.

Full-Stack Rotation¶

Full-stack rotation updates a credential AND all its dependent resources in one operation.

How It Works¶

1. Generate new credential value
   ↓
2. Update Key Vault secret
   ↓
3. Update Resource 1 (App Service)
   ↓
4. Update Resource 2 (Function App)
   ↓
5. Update Resource N...
   ↓
6. Verify all resources healthy
   ↓
7. Complete (or rollback on failure)

Running Full-Stack Rotation¶

1. Navigate to the secret in Assets
2. Click Rotate button
3. Review blast radius
4. Confirm dependent resources to update
5. Click Rotate Now
6. Monitor progress in real-time

Rollback¶

If any resource update fails:

• Automatic rollback is triggered. The credential and all affected resources are restored to their pre-rotation state
• Failure logged with details for review

Resource Updates¶

App Services / Function Apps¶

Dependencies updates:

• Application settings (@Microsoft.KeyVault references)
• Connection strings
• Slot settings (if applicable)

Container Apps¶

• Environment variables with KV references
• Secrets configuration

Logic Apps¶

• Connection parameters
• Workflow definitions (if applicable)

Azure DevOps¶

• Service Connections referencing App Registration credentials (client ID / secret)
• Variable Groups linked to Key Vault secrets via the ADO-Key Vault integration
• Project Selection: Choose which ADO projects to include in dependency scanning (Settings > Integrations > ADO). If no projects are selected, all accessible projects are scanned.

SQL Servers¶

• Admin password (with caution)

Configuration¶

Dependency mapping is part of the PRO licence. There is no on/off switch and no schedule for it in Settings. You run it from Assets → Dependencies, and both actions need an admin account:

• Resources tab, Run Resource Scan, inventories the Azure resources that could consume a credential.
• Mappings tab, Run Mapping, matches those resources to Key Vault secrets and builds the dependency graph.

Non-admin users see both tabs read-only.

The only thing you configure in Settings is the optional Azure DevOps connection below.

Azure DevOps Integration¶

Connect your ADO organisation for automatic dependency discovery.

Prerequisite: Grant CertifyClouds' managed identity access to your ADO org¶

This is the step most setups miss. Azure DevOps does not accept arbitrary Entra principals by default. Even if the managed identity can authenticate to Microsoft Entra ID, the ADO org admin has to add it explicitly as a user before any API call works.

Option A: Automated (recommended)

If you ran setup-certifyclouds-access.sh during install, re-run it with --ado-org to add the MI as a Stakeholder. The operator needs to be a Project Collection Administrator on the target org.

./setup-certifyclouds-access.sh \
  --principal-id <MI-object-id> \
  --apply --pro \
  --ado-org https://dev.azure.com/your-org

Option B: Manual (via ADO portal)

1. Sign into https://dev.azure.com/your-org as a Project Collection Administrator
2. Organization Settings → Users → Add User
3. Origin: Azure AD, paste the CertifyClouds MI's Object ID
4. Access level: Stakeholder (free, sufficient for read-only discovery)
5. Save

After adding the user, grant project-level read access:

1. Organization Settings → Permissions → Project Collection Readers → Members → Add
2. Search for the MI, add it (or grant Reader on individual projects for narrower scoping)

Connect the integration in CertifyClouds¶

Once the MI is a member of the ADO org:

1. Go to Settings > Integrations > Azure DevOps
2. Enter your organisation URL (e.g., https://dev.azure.com/your-org)
3. Click Test Connection to verify access and discover projects
4. Click Save Configuration
5. Select which projects to include in dependency scanning
6. Click Save Selection

If no projects are selected, all accessible projects will be scanned during dependency discovery.

Write Permissions¶

Full-stack rotation writes the new credential into the resources that consume it, so it needs control-plane write access on those resource types. Use the four least-privilege built-in roles rather than Contributor.

The exact role names, what each one covers, and ready-to-run az role assignment create commands are in Azure Permissions.

API access¶

Dependencies endpoints are listed in API Endpoints; exact request and response shapes are in your deployment's /docs.

Troubleshooting¶

Dependencies not found¶

Cause: Resources not using Key Vault references.

Fix: - Migrate to @Microsoft.KeyVault(...) references - Use Azure tags to improve matching

Low confidence matches¶

Cause: Naming conventions don't match.

Fix: - Add tags to both secrets and resources - Use consistent naming (e.g., api-key in both places)

Rotation failed - resource update error¶

Cause: Insufficient permissions on resource.

Fix: - Grant Contributor role on the resource group - Check resource-specific role requirements

Rollback triggered¶

Cause: One or more resources failed to update.

Check: - View rotation history for failure details - Check Azure Activity Log for errors - Verify resource permissions

Best Practices¶

1. Use Key Vault References: Migrate to @Microsoft.KeyVault(...) for high-confidence mapping
2. Consistent Naming: Use matching names for secrets and settings
3. Tag Resources: Add keyvault-secret tags for explicit mapping
4. Test in Non-Prod: Validate full-stack rotation in staging first
5. Review Blast Radius: Always check impact before rotating
6. Monitor After Rotation: Watch application health post-rotation