Key Vault Break-Glass Access Workflow
For emergencies, the flow provides a heavily-audited break-glass path: a requester invokes it, two distinct approvers must sign off (sequential dual control), a fixed privileged secret is retrieved for a short window, every step is alerted to security, and a force-revoke/rotation alert is raised after. Enables controlled emergency secret access.
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 provides a heavily-audited emergency path to a privileged Azure Key Vault secret. A requester invokes the flow with a justification and incident reference; two distinct approvers must each sign off (sequential dual control); only then is the privileged secret retrieved and made available for a configurable, time-boxed window; every step is alerted to a security Teams channel; and when the window closes the flow raises a force-revoke/rotation alert. A single correlation id minted in the first action is stamped on every approval and alert.
Why it matters: emergencies need fast access to privileged credentials, but unchecked break-glass access is dangerous. Dual approval, a tight access window, secret-value secrecy, and a full Teams audit trail make emergency access controlled and reviewable.
Ships Off (Stopped). The secret is fixed by an env var; its value is never written to Teams.
Use Case
IT Admins and security teams occasionally need a rare, controlled way to reach a privileged secret (e.g. a break-glass admin credential) during a live incident. This flow gives them a single governed entry point: the secret is fixed by an env var, two approvers must agree, and the security channel sees the request, grant, and expiry in real time.
Flow Architecture
Manually Trigger (Break-Glass Request)
Request (Button)Requester supplies a justification and an incident/ticket reference.
Initialize Trace & Config
Initialize variable (x10)Mints a correlation id in the first action and binds the vault, break-glass secret, both approvers, security Teams ids, and the access window.
Alert: Request Received
Teams - PostMessageToConversationAudit at t=0 - alerts security a break-glass request opened, before any approval.
Approval 1 of 2
Approvals - StartAndWaitForAnApprovalFirst approver must approve (dual control); rejection stops the flow.
Approval 2 of 2
Approvals - StartAndWaitForAnApprovalSecond, distinct approver must approve; only requested if the first approved.
Grant: Get Secret + Audit Metadata
Key Vault - GetSecret / GetSecretMetadataRetrieves the privileged value to the run context (never posted) and records the exact version accessed.
Hold Window then Revoke Alert
Wait + TeamsPosts the grant audit, holds the time-boxed window, then posts the revoke/rotation alert.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_KeyVaultName | String | kv-flowlibs-demo | Vault name shown in alerts (the connection itself is bound to the vault). |
| flowlibs_BreakGlassSecretName | String | break-glass-admin-credential | The single designated privileged secret retrieved on approval. |
| flowlibs_Approver1Email | String | approver1@contoso.com | First approver (dual control 1 of 2). |
| flowlibs_Approver2Email | String | approver2@contoso.com | Second, distinct approver (dual control 2 of 2). |
| flowlibs_TeamsGroupId | String | <your-team-id> | Security Team (group) id for audit alerts. |
| flowlibs_TeamsChannelId | String | <your-channel-id> | Security channel id for audit alerts. |
| flowlibs_AccessWindowMinutes | String | 15 | Minutes the access window stays open before the revoke alert. |
Connectors & Connections
| Connector | API name | Actions used |
|---|---|---|
| Azure Key Vault | shared_keyvault | GetSecret GetSecretMetadata |
| Approvals | shared_approvals | StartAndWaitForAnApproval |
| 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.
- Access window
- Change flowlibs_AccessWindowMinutes (drives the Wait duration).
- Approvers
- Set the two approver emails to distinct security leads. To require everyone in a group, switch each approval to BasicAwaitAll with a semicolon-separated assignedTo.
- Which secret
- Change flowlibs_BreakGlassSecretName; requesters cannot override it, which is intentional.
- Real rotation
- To actually rotate/disable the secret after the window, add an Azure Resource Manager (or HTTP-to-management-plane) action after the revoke alert.
- Reason quality
- Keep the Justification field mandatory and add a post-incident review task (e.g. Planner) for governance.
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.01Correlation id (first action)
Stamped on every approval and alert.
EXPR.02First approval check
Gate on dual control 1 of 2.
EXPR.03Second approval check
Gate on dual control 2 of 2.
EXPR.04Secret version for audit
Records the exact secret version accessed, without the value.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.