API Key Vault Console
A centralized, Azure Key Vault-backed console for storing, rotating, distributing, and auditing API credentials across the full MSP vendor stack. Covers setup, daily use, rotation policy, technician access control, and troubleshooting.
Overview
The API Key Vault Console is a single-page HTML dashboard that manages API credentials for every vendor in the MSP stack. All secrets are stored encrypted in Azure Key Vault — nothing is held in the browser or on disk. The console authenticates to the vault using a Microsoft Entra ID app registration and provides a unified interface for adding, rotating, distributing, and auditing keys across 32 pre-loaded vendor integrations.
Key capabilities
| Capability | Description |
|---|---|
| 🗄 Vault | Store and view all vendor API keys with expiry tracking, key preview, and status indicators per vendor. |
| 🔄 Rotation | Track rotation schedules per vendor, see overdue and upcoming rotations, and rotate keys individually or in bulk. |
| 📤 Distribute | Role-based access toggles per technician. Grant or revoke access to specific vendor keys per role (Admin, L2, L1, NOC). |
| 📋 Audit Log | Tamper-evident log of every action — add, retrieve, rotate, distribute, delete — with timestamp, user, vendor, and notes. CSV export included. |
| ⚙️ Setup Guide | In-console step-by-step guide for wiring up Entra ID and Azure Key Vault. |
| 🖨 Print / PDF | One-click print-optimized report of all vendor key statuses, expiry dates, and rotation schedule. Save as PDF from the print dialog. |
Architecture
Microsoft Entra ID and Azure Key Vault are two separate Azure services that work together. Entra handles identity — it verifies who is allowed to access the vault. Key Vault handles the secrets — it stores them encrypted and only hands them over after a valid Entra token is presented.
The three values entered in the Connect Azure modal correspond directly to this flow:
| Modal Field | What It Is | Where to Find It |
|---|---|---|
| Tenant ID | Your Azure AD / Entra directory ID | Entra ID → Overview → Directory (Tenant) ID |
| Client ID | The app registration identity | App Registrations → your app → Application (client) ID |
| Client Secret | The app's password for Entra | App Registrations → your app → Certificates & Secrets → Value |
| Key Vault Name | Just the vault name, not the full URI | Key Vault → Overview → Vault name |
Setup Guide
Complete these four phases in order. Total time is approximately 15-20 minutes for a net-new deployment.
Phase 1 — Create the Azure Key Vault
msp-api-keyvault (or your naming convention), select your region, and use the Standard pricing tier. Enable Soft Delete with 90-day retention.msp-api-keyvault, not the full URL.Phase 2 — Entra ID App Registration
msp-api-vault-console. Set Supported Account Types to Single tenant. Leave Redirect URI blank — this console uses the client credentials flow, not user-delegated auth.Phase 3 — Grant Key Vault Access via RBAC
For read-only technician identities: assign Key Vault Secrets User — get and list only.
msp-api-vault-console. Select it, then Review + Assign. Allow 1-2 minutes for RBAC propagation before connecting.Phase 4 — Connect the Console
Using the Console
Adding a Key
Click + Add Key in the topbar or sidebar. Select the vendor from the dropdown — all 32 vendors are pre-loaded with their correct API endpoint and key format hint. Paste the API key, set an expiry date, choose a rotation interval, and optionally add a note. Click Save to Vault. The key is stored immediately in Azure Key Vault under the vendor's secret name.
ninja_••••••••••••5f2a) in its local state. The actual value lives exclusively in Azure Key Vault and is retrieved via the authenticated token when needed.Rotating a Key
There are three ways to rotate:
| Method | How | Use Case |
|---|---|---|
| Row-level | Click Rotate button on the vendor row in the Vault tab | Single vendor, ad-hoc rotation |
| Detail panel | Open vendor detail → click 🔄 Rotate Key | When you want to review before rotating |
| Bulk rotation | Click 🔄 Rotate All Due in the Rotation tab or sidebar | Scheduled maintenance window — rotates all keys due within 14 days |
Distributing Keys to Technicians
The Distribute tab shows a card per technician role. Each card lists all vendors with a stored key, with a toggle to grant or revoke access. Access changes are logged to the Audit Log immediately. Current roles are:
| Role | Default Access | Intended For |
|---|---|---|
| Admin | All vendors | Senior engineers, security leads |
| L2 | RMM, PSA, EDR, Network, Backup | Level 2 technicians |
| L1 | RMM, PSA only | Level 1 / helpdesk |
| NOC | RMM, EDR, Email Security | NOC analysts (monitoring only) |
Audit Log
Every action taken in the console — add, retrieve, rotate, distribute, delete — is written to the Audit Log with a timestamp, action type, vendor name, user, and notes field. The log is sorted newest-first and exportable to CSV via the Export Log button. For Azure Monitor integration, see Security Hardening.
Rotation Schedule by Category
Default rotation intervals are pre-set per vendor category based on risk profile and common vendor recommendations. These can be overridden per vendor when adding a key.
| Category | Default Interval | Rationale |
|---|---|---|
| RMM 90d | 90 days | High privilege — full device access. Treat like admin credentials. |
| PSA 90d | 90 days | Ticket and billing data access. Moderate-high risk. |
| Security / EDR 90d | 90 days | Threat response tools. Compromise of these keys is a critical incident. |
| Network 180d | 180 days | Read-heavy operations. Lower risk than EDR but still sensitive. |
| Backup 90d | 90 days | Recovery data access. Ransomware vector if compromised. |
| Identity 180d | 180 days | Graph API / Entra tokens. Usually tied to app registration lifecycle. |
| Comms 180d | 180 days | Lower sensitivity. Voice/SMS API data. |
| Distribution 365d | 365 days | Ordering and procurement — typically stable, lower risk. |
| Hardware 180d | 180 days | Asset lifecycle data. Not a primary attack surface. |
Security Hardening
Enable Key Vault Diagnostic Logs
Send every vault access event to Azure Monitor / Log Analytics for a full external audit trail. This is separate from the console's local audit log and is recommended for CMMC, SOC 2, or HIPAA environments.
Enable Purge Protection
Prevents permanent deletion of secrets during the soft-delete retention window. Required for some compliance frameworks.
Restrict Access via Conditional Access
In Entra ID → Security → Conditional Access, create a policy scoped to the msp-api-vault-console app registration. Add a Named Location condition to restrict access to your office or VPN IP range. This prevents the Client ID + Secret from being usable outside your known network, even if the credentials are stolen.
Rotate the Entra Client Secret on a Schedule
The Client Secret used to authenticate this console is itself a credential that expires and needs rotation. Add it as a vendor entry in the console using vendor name Entra App Secret with a 90-day rotation interval. When it expires, generate a new secret in App Registrations, update it in the console's Connect modal, and log the rotation in the Audit Log.
Troubleshooting
Check the following in order:
1. Tenant ID and Client ID — confirm they are copied from the correct app registration, not a different one. Both should be GUIDs in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
2. Client Secret — if the secret has expired or was regenerated, the old value will fail silently. Create a new secret in App Registrations and paste the new Value.
3. RBAC not propagated — if you just assigned the Key Vault Secrets Officer role, wait 2-3 minutes and retry. Azure RBAC propagation is eventually consistent.
4. Vault name — enter just the name portion, not the full URI. msp-api-keyvault not https://msp-api-keyvault.vault.azure.net/.
This is expected behavior. When Azure Key Vault is not connected, key data is held in JavaScript memory only — it does not persist between sessions. This is by design to avoid storing credentials in browser storage (localStorage, IndexedDB, etc.).
Connect the console to Azure Key Vault and all saves will persist in the vault across sessions.
The test ping fires a lightweight request to the vendor's documented base endpoint. Common causes of failure:
1. Key scope — some vendors issue keys tied to specific permissions or scopes. A key without the required scope may authenticate but return 403 on the test endpoint. Check the vendor portal for scope/permission settings.
2. IP allowlisting — some vendors (SentinelOne, certain ConnectWise configurations) restrict API access by IP. If you are behind a VPN or a new IP, you may need to add it to the vendor's allowlist.
3. Endpoint format — for vendors with tenant-specific subdomains (SentinelOne, ConnectWise Automate, FortiGate), the pre-loaded endpoint contains a placeholder like {tenant} or {server}. Update the endpoint with your actual subdomain in the vendor's detail panel.
This almost always means the vault's Permission Model is set to Vault Access Policies rather than Azure RBAC. RBAC role assignments only apply when the vault is configured for RBAC mode.
To check: Key Vault → Settings → Access Configuration → verify Azure role-based access control is selected. If it shows Vault access policy, you either need to switch the model (which requires Owner rights and affects all existing assignments) or add the app registration directly in the Access Policies blade using the legacy method.
The print stylesheet targets landscape letter size. If rows are still being clipped, try the following in the Chrome print dialog:
1. Set Layout to Landscape.
2. Under More Settings, enable Background graphics so category color pills render correctly.
3. If the table is still too wide, reduce the Scale to 85-90%.
4. As a fallback, export the CSV from the Vault view — it contains all the same data in a format that can be opened in Excel and printed from there.