Secrets, Customer-Managed Keys and Copilot at a Multi-Tenant SaaS Provider
A SaaS provider runs a multi-tenant platform on AKS: 120 microservices, 35 clusters across three regions, Cosmos DB and Azure SQL holding tenant data, and a Key Vault per region. An external penetration test found that 61 percent of application secrets still live in Kubernetes Secrets or pipeline variables, and that container images reach production without a blocking scan. Separately, the company is deploying Microsoft 365 Copilot to 3,000 staff while its SharePoint estate has never had sensitivity labels applied. The largest enterprise customer has just requested a contractual guarantee that their data is encrypted with keys the customer controls, in a single region. Product teams own their own pipelines and resist gates that slow delivery; median deploy frequency is 40 per day.
1. Design the remediation for the secrets finding in a way that product teams will actually adopt at 40 deploys per day.
Read the worked answer
Eliminate secrets rather than govern them better.
- Workload identity for AKS: federated credentials between the cluster's service account and Entra ID so pods receive short-lived tokens. The Key Vault CSI driver remains only for third-party components that demand a literal secret at runtime, and those cases should be enumerated and justified.
- Federated credentials for pipelines: GitHub Actions or Azure DevOps workload identity federation removes the stored service principal secret, which is typically the largest single class of pipeline-variable finding.
- Gates that cost seconds, not days: secret scanning on the pull-request diff rather than the whole repository; admission control (Gatekeeper or Azure Policy) denying pods that mount disallowed Secret classes or images from unapproved registries. Image scanning must block promotion to production, not merely report afterwards - that is the difference between a scanner and a control.
- Make the paved road faster than the exception: a service template that wires workload identity, Key Vault access and the scanning step in one line, so teams gain velocity by complying.
- Residual secrets: automate rotation, cap lifetimes under 90 days, and monitor expiry centrally. With federated credentials most of this burden disappears entirely.
Track success as percentage of workloads with zero long-lived credentials, not as count of secrets moved into Key Vault.
2. The enterprise customer wants customer-managed keys and a single region. What can you commit to, and what must you push back on?
Read the worked answer
Separate what is technically available from what the customer is actually asking for.
- Achievable now: Azure SQL TDE with a customer-managed key held in Key Vault or Managed HSM, with key and database in the same region for the key to be usable. This is a normal, supportable commitment.
- Contradiction to surface: Cosmos DB supports customer-managed keys, but a strict single-region guarantee conflicts with the multi-region replication that provides the availability the customer is also paying for. Either pin that tenant to a single-region account and document the availability trade-off, or negotiate a region-pinned storage commitment with a written replication exclusion owned by legal.
- Clarify the key custody spectrum: customer-managed key in a vault you operate, versus Managed HSM with key-release policy the customer can revoke, versus the customer operating the HSM in their own subscription. Most customers asking for this want revocation ability, not operational custody. If they genuinely want to run the HSM, that is a dedicated-tenant architecture and a different price point - do not sign it as a toggle.
- Contract language: specify algorithm, key rotation ownership, behaviour on key revocation (what breaks, how fast) and recovery SLAs. Encryption guarantees that omit revocation behaviour are the ones that generate incidents later.
3. How do you sequence the Copilot rollout against the unlabelled SharePoint estate, and what would you insist on before broad enablement?
Read the worked answer
Copilot does not create the oversharing risk; it industrialises it. An assistant that reads everything a user can read turns a dormant bad permission into an active data leak.
- Inventory and remediate before enablement. Use SharePoint Advanced Management and Microsoft Purview to find sites shared with 'Everyone except external users', broad sharing links, and stale permissions held by departed staff. Publish the count of files reachable by all employees as the readiness gate - not licence assignment counts.
- Labels before licences for the sensitive containers. Apply sensitivity labels with encryption to finance, HR and M&A content, with a default label on document libraries. Unlabelled content carries no protection into the index, and labels travel with files, so this is durable rather than a point-in-time fix.
- Guardrails: default sharing links to specific people, restricted access control on the highest-risk sites, regular access reviews of site membership, and blocking Copilot for specific sites where oversharing cannot yet be remediated.
- Pilot population first. Roll out to a few hundred users in low-risk functions, measure query and oversharing telemetry, then expand.
- DLP aligned to the label taxonomy so the same classification drives both the assistant scope and exfiltration control.
Insist on one thing above all: no broad enablement while any site holding regulated data remains accessible to all employees.