Key Vault Secret Request Self-Service
Via a Teams/form request, the flow lets approved developers request access to a secret; it runs an approval, grants time-bound RBAC access scoped to the vault, logs the grant, and auto-revokes when the window ends. Provides governed self-service secret access with JIT expiry - the secret value never passes through the flow.
Provided as-is, without warranty of any kind. Review and test each pattern in a non-production environment before deploying it to live automations. See our Terms.
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
When a Developer Requests Secret Access
Request (Button)Inputs: secret name, justification, requester email.
Initialize Trace & Config
Initialize variable (x15)Captures the request and binds the vault, allow-list, approver, Teams ids, subscription, resource group, role-def id, max hours; mints a correlation id and a reusable assignment id (guid) and computes the revoke timestamp.
Allow-List Gate
ConditionProceeds only if the requested secret is on the allow-list (else posts a blocked notice to Teams).
Validate Secret Exists
Key Vault - GetSecretMetadataConfirms the secret exists (metadata only, no value).
Request Approval
Approvals - StartAndWaitForAnApprovalBasic approval to the configured approver.
Resolve Requester Principal
Office 365 Users - UserProfile_V2Resolves the requester email to an Entra object id (on approval).
Grant Time-Bound RBAC
ARM - Resources_CreateOrUpdateByIdPUTs a Key Vault Secrets User role assignment at the vault scope using the minted assignment id.
Log Grant & Wait JIT Window
Teams + WaitPosts an audit grant message, then holds until the revoke timestamp.
Revoke RBAC & Audit
ARM - Resources_DeleteById + TeamsDELETEs the same role assignment (genuine revoke) and posts the auto-revoke notice.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_VaultName | String | flowlibs-demo-kv | Key Vault name / RBAC scope target. |
| flowlibs_MaxAccessHours | String | 4 | JIT access window in hours. |
| flowlibs_AllowedSecrets | String | ["demo-api-key","demo-connection-string","demo-storage-key"] | JSON allow-list of requestable secrets. |
| flowlibs_SecretApproverEmail | String | approver@contoso.com | Approver mailbox. |
| flowlibs_AdminTeamsGroupId | String | <your-team-id> | Teams team/group id for the audit channel. |
| flowlibs_AdminTeamsChannelId | String | <your-channel-id> | Teams channel id for the audit channel. |
| flowlibs_AzureSubscriptionId | String | <your-subscription-id> | Subscription GUID for the RBAC scope. |
| flowlibs_AzureResourceGroup | String | rg-flowlibs-demo | Resource group holding the vault. |
| flowlibs_KeyVaultRoleDefId | String | 4633458b-17de-408a-b874-0445c86b69e6 | Role definition GUID granted (default Key Vault Secrets User). |
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 |
| Microsoft Teams | shared_teams | PostMessageToConversation |
Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.
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.
EXPR.01Revoke timestamp
End of the JIT window.
EXPR.02Allow-list check
Gate on the requested secret.
EXPR.03Role assignment resource (shortResourceId)
Same id used by the PUT grant and DELETE revoke.
EXPR.04Role definition id
The role granted.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.