How to find what services are being used by keyvault secrets

Question

I would like to know is there a way we can find what services are consuming secrets from key vault secrets/keys/certs , few are known using app insights or log analytics workspace i am querying cloud instance role and also from the kubernetes cluster using secretproviderclass i am able to find few, which were consumed by those secrets like what services are being consumed, there are secrets and certs related to data like sql server passwords , on-prem related passwords , how do we findout what is consumed by these.

Answer 1

AFAIK, there is no single native “reverse dependency” view in Azure that tells you exactly which services consume a specific Key Vault secret, key, or certificate, so you have to triangulate usage from identity access, runtime calls, configuration references, and deployment definitions. The most reliable signal in this case would be Key Vault data-plane access logs because every secret/key/cert retrieval generates an audit event showing the caller identity, IP, and operation; once diagnostic logging is enabled to Log Analytics you can query which principals actually retrieved a specific object and then map those principals back to services like App Services, Functions, AKS workloads, VMs, pipelines, or on-prem integrations.

Example Log Analytics queries if diagnostic logs are enabled:

AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName contains "SecretGet" or OperationName contains "KeyGet" or OperationName contains "CertificateGet"
| where requestUri_s contains "your-secret-name"
| project TimeGenerated, identity_claim_appid_g, identity_claim_oid_g, CallerIPAddress, OperationName, ResultType
| order by TimeGenerated desc

KeyVaultDataPlaneLogs
| where OperationName in ("SecretGet","KeyGet","CertificateGet")
| where ObjectName == "your-secret-name"
| project TimeGenerated, AADObjectId, Identity, CallerIPAddress, ResultSignature
| order by TimeGenerated desc

After you identify the managed identity or service principal accessing the secret you correlate it with the resource using Entra ID or Azure Resource Graph. Many services use managed identities so you resolve the object id:

az ad sp show 

or

Resources
| where identity.principalId == "<object-id>"
| project name, type, resourceGroup, subscriptionId

You also need to check configuration-level references because some services reference Key Vault indirectly without obvious runtime logs until executed. App Service and Functions may use Key Vault references in app settings like @Microsoft.KeyVault(SecretUri=...) which you can discover with Resource Graph:

Resources
| where type in ("microsoft.web/sites/config","microsoft.web/sites")
| where properties contains "vault.azure.net"
| project name, type, resourceGroup, properties

AKS usage beyond SecretProviderClass can be found by scanning pod specs, Helm charts, and CSI driver mounts because sometimes secrets are injected at deployment time rather than dynamically fetched. You can search manifests or live clusters:

kubectl 

Infrastructure as code is another major source because pipelines, ARM/Bicep, Terraform, and DevOps variable groups may pull secrets during deployment rather than runtime. Search repositories for vault URIs or secret names and inspect pipeline service connections or variable groups that reference Key Vault.

For certificates and keys used by SQL connections, on-prem services, or legacy apps, look at network caller IPs in Key Vault logs and correlate them with private endpoints, hybrid workers, or gateway servers. If private endpoint is used you may need NSG flow logs or firewall logs to map the calling host.

If diagnostic logging was not enabled historically there is no retroactive way to know consumption; in that case your best approximation is to enumerate access policies or RBAC assignments and then map identities to resources:

az role assignment list 

and

az keyvault show 

Then validate which identities are still active or deployed.

For long-term approach, enable KeyVaultDataPlaneLogs, enforce managed identities only, tag identities with owning service metadata, and create continuous queries that build a dependency inventory table showing secret name, calling identity, mapped resource, and last access time so you always know which services are actively consuming each credential.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin