Cloud Kms Laravel Package

Product Decisions This Supports

• Build vs. buy for key management. The package makes "buy" the default: it wires your Laravel app to a managed, HSM-backed key service instead of you building key storage, rotation, or HSM operations. The build decision shrinks to a thin internal KeyProvider wrapper.
• Encrypt-at-rest strategy. Supports moving from a single APP_KEY to envelope encryption: a KMS-held key-encryption key (KEK) wraps per-record or per-tenant data keys (DEKs). This is the decision point for field-level encryption of PII, payment data, and health data.
• Multi-tenancy and data residency. Per-tenant KEKs enable key isolation by customer, region, or environment, and "crypto-shredding" (destroy the key, render the data unrecoverable) as a defensible GDPR erasure mechanism.
• Compliance roadmap. Directly supports SOC 2, ISO 27001, PCI DSS, and HIPAA control narratives around key custody, separation of duties, rotation, and audit logging. Encryption-in-app with a self-managed key is much harder to evidence to an auditor.
• Enterprise and regulated-tier features. CMEK/BYOK requests, customer-managed key rotation SLAs, and cryptographic audit trails become roadmap items you can commit to rather than research spikes.
• Feature backlog it unblocks. Signed URLs and webhooks via asymmetric keys, token/claim signing, secrets and credential encryption, data-export encryption, and key rotation automation.
• Cloud strategy. This is also a cloud-strategy decision: adopting it deepens GCP dependency for a security-critical path. That should be an explicit, recorded architectural choice, not a side effect of a feature ticket.

When to Consider This Package

Adopt when:

• The application runs on GCP, or GCP KMS is already the compliance-approved root of trust (e.g., BigQuery/GCS data already protected by CMEK).
• You need key custody separated from application servers, with IAM-based separation of duties and Cloud Audit Logs.
• You have a concrete driver: per-tenant keys, crypto-shredding, field-level PII encryption, FIPS 140-2 Level 3 HSM-backed keys, or asymmetric signing/MAC operations.
• You are prepared to wrap it. The client is a generated, low-level API surface; you will want your own Encrypter/KeyProvider interface for testability and future portability.
• Your team has GCP IAM and service-account/Workload Identity maturity.

Look elsewhere when:

• AWS or Azure is the primary cloud — use the native KMS/Key Vault SDKs rather than bridging clouds for latency, cost, and IAM complexity.
• You require cloud-agnosticism. Use HashiCorp Vault Transit or a multi-driver abstraction; this package should be one driver behind it, not the abstraction itself.
• Encryption needs are basic: Laravel's Crypt facade and encrypted casts are sufficient when there is no external key-custody requirement.
• You are on-prem or air-gapped — use Vault or a PKCS#11 HSM.
• You need a supported, community-blessed Laravel package. Note the adoption signals honestly: 12 stars and 0 dependents. This is a subtree split of the google-cloud-php monorepo, so stars understate real usage and Google maintains it, but there is effectively no community layer — no tutorials, no third-party battle-testing, no Stack Overflow corpus. Budget for owning the wrapper, integration tests, and upgrade verification yourself.
• Treat the release metadata as unverified: the "last release 2026-10-16" date in this dataset is in the future and should be re-checked against Packagist before any roadmap commitment.

How to Pitch It (Stakeholders)

For executives: "We can move sensitive customer data from a single application key to Google-managed, HSM-backed encryption keys without building or operating key infrastructure. It is pay-per-use, requires no new headcount, and produces the audit evidence our SOC 2 / PCI / HIPAA conversations ask for. It also unlocks enterprise deals that require customer-managed keys. The trade-off is real vendor concentration on GCP for a security-critical component, and the library itself is thin — we own a small internal wrapper, roughly a few days of engineering, not a platform build."

For engineering: "Official Google client, Apache-2.0, standard Application Default Credentials, generated from the same protobufs as every other GCP SDK. Integration is a Composer require plus a singleton binding; credentials come from Workload Identity in production, not key files. We will not call it directly from controllers — we put it behind a KeyProvider contract with two implementations: Cloud KMS in production, and a local libsodium driver for tests, since Cloud KMS has no emulator. Expect envelope encryption (KMS encrypts DEKs, DEKs encrypt rows), cached DEKs to keep per-10k-operation costs and latency down, and a rotation job. The main engineering risk is not the API — it is that the community surface is near zero, so upgrades and edge cases are ours to validate."

One-line ask: Approve a spike to wrap Cloud KMS behind an internal key-provider interface, with a go/no-go gated on compliance sign-off for GCP as the root of trust.