Azure Key Vault Client Laravel Package

Technical Evaluation

Architecture fit. keboola/azure-key-vault-client is a framework-agnostic PHP wrapper for the Azure Key Vault REST API, not a Laravel package. It offers no service provider, facade, config stub, or cache layer, so it occupies the "raw SDK" layer of our stack rather than the "Laravel integration" layer. That is acceptable if we treat it as a transport primitive and build our own thin Laravel binding around it. It is a poor fit if we expect drop-in secret resolution in config/ out of the box. The value proposition is narrow but real: Laravel has no first-class Azure Key Vault story (unlike AWS Secrets Manager or HashiCorp Vault, which have mature community packages), and most teams end up hand-rolling Guzzle calls against the Key Vault API. This package removes that boilerplate.

Integration feasibility. Composer-installable, MIT-licensed, PSR-4 — standard integration. The realistic shape is: bind the client as a singleton in a KeyVaultServiceProvider, wrap it in a SecretRepository with a read-through cache (Redis or Laravel's cache), and expose a config()-compatible resolver for the handful of secrets we must load at boot. The hard part is not the code; it is the identity bootstrap. The client needs tenant ID, client ID, and client secret (or managed identity) to authenticate — which means the credential itself must live in .env, App Service settings, or a managed identity assignment. That chicken-and-egg is the dominant feasibility question, not the package API.

Technical risk.

• Adoption signal is weak. One star, zero dependents, single-vendor origin (Keboola, a data-platform company). This reads as an internally extracted utility rather than a community-supported library. Bus factor is effectively one organization.
• Dependency drift. Verify whether it wraps the official Azure\* SDK or hand-rolls Guzzle. If the latter, it will lag Azure API versions and may conflict with Laravel's Guzzle 7 constraint.
• No Laravel contract. Every Laravel-native concern — config caching interaction, env() timing, queue/worker bootstrapping — is ours to solve.
• Secrets in bootstrap/cache. php artisan config:cache will happily serialize resolved secrets to disk in plaintext if we wire this naively. That is a security regression versus managed identity at the platform layer.
• Throttling. Key Vault enforces per-vault transaction limits; an uncached per-request fetch pattern will hit 429s under load.

Key questions.

1. Does it support Managed Identity / Workload Identity, or only service-principal client-secret auth?
2. Does it cache AAD tokens internally, or re-authenticate per call?
3. Which PHP and Laravel versions are supported, and what is the transitive dependency tree (Guzzle, azure-sdk-for-php)?
4. Does it support secret versioning, disabled-secret handling, and certificate retrieval, or only getSecret?
5. What is the retry/backoff and error-surface behavior on 401/403/429/5xx?
6. Is Keboola's release cadence (last release 2026-04-02) backed by public commit activity and issue triage?
7. Does it support Key Vault references / App Service integration, or is it strictly SDK-side?

Integration Approach

Stack fit. Laravel 10–12 on PHP 8.1+, deployed to Azure App Service, Container Apps, or AKS. The package fits cleanly at the infrastructure boundary: it is the thing our SecretRepository calls, nothing more. Do not let controllers, jobs, or models touch it directly — keep the Key Vault surface behind one interface so it can be swapped or stubbed in tests.

Migration path. Phased, not big-bang.

1. Lift secrets out of .env and hardcoded config into Key Vault, keeping .env as the source of truth during a shadow period.
2. Introduce SecretRepository with a read-through cache; read from Key Vault, fall back to env() on failure, log both paths.
3. Cut specific secret classes over one at a time (third-party API keys first, database credentials last).
4. Retire .env secret entries once cache hit rates and error budgets are clean for a full rotation cycle.

Compatibility. Verify Guzzle major-version alignment with Laravel's HTTP client stack before committing — a Guzzle 6 pin would be a hard blocker. Confirm the package's PHP constraint against our CI matrix. Confirm AAD endpoint compatibility with whichever identity mechanism (service principal vs. managed identity vs. workload identity federation) our platform team standardizes on.

Sequencing.

• Sprint 0: PoC in a non-prod subscription — authenticate, fetch one secret, measure cold latency and token reuse behavior.
• Sprint 1: KeyVaultServiceProvider + SecretRepository + cache + feature flag + tests against a mocked Key Vault.
• Sprint 2: CI/CD identity provisioning (managed identity or federated credential), Key Vault firewall/private endpoint, RBAC role assignment (Key Vault Secrets User).
• Sprint 3: staged production rollout by secret class with kill-switch back to .env.

Operational Impact

Maintenance. Low ongoing code maintenance — the API surface is small and the wrapper is thin. The real maintenance burden is dependency maintenance: Azure SDK and Guzzle major bumps will need us to track upstream. Given 1 star and 0 dependents, assume we are effectively the maintainer of last resort. Budget a fork-and-own contingency; the codebase is small enough that a fork is days, not weeks.

Support. No vendor SLA. Keboola support is GitHub-issue-based with no published triage commitment. Community coverage (Stack Overflow, blog posts) will be near zero, so internal documentation and a runbook are non-negotiable. Escalation path is "read the Azure REST docs ourselves."

Scaling. The package itself is stateless and scales horizontally without issue. Key Vault is the bottleneck: per-vault transaction rate limits and 50–200ms round-trip latency mean we must cache aggressively. Design target: one Key Vault read per secret per cache TTL per environment, not per request or per worker boot. Watch queue workers and scheduled jobs — they bootstrap frequently and will multiply call volume if not covered by the shared cache.

Failure modes.

• Auth expiry / credential rotation — 401 storms; mitigated by token caching and alerting on auth failures.
• Throttling (429) — bursty deploys or cache misses; mitigated by jittered retry and a longer TTL.
• Network isolation — Key Vault firewall, private endpoint misconfiguration, or DNS resolution failure inside the VNet; this is the most common production surprise.
• Secret rotation breaking live consumers — cache staleness versus in-flight credential use; needs a rotation runbook and versioned secret references.
• Control-plane outage — Key Vault regional incident takes down bootstrapping; mitigated by a documented break-glass path to platform-injected settings.
• Cache poisoning / plaintext leakage — if secrets land in bootstrap/cache or logs; enforce ShouldBeStrict-style guards and redact in exception handlers.

Ramp-up. The package API is learnable in an afternoon by a mid-level Laravel developer. The genuine ramp-up cost is Azure IAM literacy — RBAC versus access policies, managed identity assignment, private endpoints, and secret rotation semantics. Plan one to two days of PoC plus one sprint to productionize, with platform/ops engineering engaged from Sprint 1 rather than Sprint 3. Overall: technically low-risk to integrate, organizationally moderate-risk to operate, and strategically worth doing only if Azure Key Vault is already our standards-blessed secrets store.