Key Vault Secret Request Self-Service

Overview

This flow delivers governed, self-service Just-In-Time (JIT) access to Azure Key Vault secrets using true Azure RBAC. A developer submits a request (secret name + justification + email); the flow validates the secret exists, routes a Microsoft Approvals sign-off, and on approval uses the Azure Resource Manager connector to grant the requester a time-boxed Key Vault Secrets User role assignment scoped to the vault. The requester then reads the secret directly with their own identity - no secret value ever passes through the flow. When the JIT window ends, ARM deletes the same role assignment, genuinely revoking access. Every step is logged to a Teams audit channel.

Why it matters: standing secret access is a security risk and manual grants are slow. Approved, time-boxed RBAC self-service balances developer speed with least-privilege governance, and never centralizes secret values in a flow run.

Ships Off (Stopped). RBAC-grant model (not value-return).

Use Case

A platform / security team wants developers to obtain occasional Key Vault access without standing permissions - every request approved, scoped to the vault, audited, and automatically expired via real RBAC.

Flow Architecture

Environment Variables

Connectors & Connections

Connector	API name	Actions used
Azure Key Vault	shared_keyvault	GetSecretMetadata
Approvals	shared_approvals	StartAndWaitForAnApproval
Office 365 Users	shared_office365users	UserProfile_V2
Azure Resource Manager	shared_arm	Resources_CreateOrUpdateById Resources_DeleteById

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Role choice

Change flowlibs_KeyVaultRoleDefId to grant a different built-in/custom role, or scope to a single secret instead of the whole vault.

Secure value delivery

If returning the value is preferred over RBAC, add a Key Vault GetSecret after the grant and deliver via an encrypted channel (never log it).

Per-secret approvers

Replace the single approver with a lookup (Dataverse or the secret's owner tag).

Step-up auth

Require MFA / conditional access for high-sensitivity secrets before approval.

Audit to Dataverse

Add a CreateRecord to a grant-history table for queryable reporting.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

addHours(utcNow(), variables('varMaxAccessHours'))

contains(variables('varAllowedSecrets'), variables('varRequestedSecret'))

concat('vaults/', variables('varVaultName'), '/providers/Microsoft.Authorization/roleAssignments/', variables('varAssignmentId'))

concat('/subscriptions/', variables('varSubscriptionId'), '/providers/Microsoft.Authorization/roleDefinitions/', variables('varRoleDefId'))

Customize & download