Demonstrate tenant-specific cryptographic controls and operational lifecycle for Cosmos DB data.
The metadata below is derived from tracked source, manifests, and infrastructure files. It describes what this repository includes; live-service integration remains bounded by the documented deployment and validation limitations.
| Category | Included |
|---|---|
| Platforms | Microsoft Azure; GitHub Actions |
| Services and stack | Cosmos DB; Key Vault; Managed Identities; Private Link; Azure Monitor |
| Languages and formats | Python; Bicep; Bicep parameters; Bash; JSON; YAML |
| Delivery and IaC | Bicep + .bicepparam; GitHub Actions CI; YAML configuration; Python validation/tests |
A tenant onboarding request plans a dedicated key, identity, Cosmos encryption boundary, private access, and auditable approval without accepting embedded key material.
A production implementation can still fail even when every resource deploys successfully. The material risk is cross-tenant impact from rushed onboarding, shared capacity, routing, or identity decisions that are difficult to unwind. The design therefore treats Cosmos DB, Key Vault, Managed Identities, and the surrounding identity and evidence controls as one reviewable system rather than unrelated configuration tasks.
A SaaS provider must demonstrate cryptographic separation for premium tenants. The pattern gives each tenant an independently governed customer-managed key and reduces the blast radius of a shared data-platform compromise.
A SaaS provider rotates customer-managed keys while preserving tenant isolation and private access. Each data boundary is bound to the intended identity and key, and rotation plus cross-tenant denial are rehearsed with synthetic tenants.
The team first exercises the repository's synthetic approved and denied fixtures. An approved request must produce the same idempotent plan on replay; a stale, unscoped, public, or unapproved request must fail before an Azure adapter is allowed to run.
Stakeholders receive a decision package they can attach to a change record: requested scope, controls evaluated, the reason for approval or denial, and the explicit handoff to live integration. The example supports design review and incident rehearsal without pretending that a local test changed Azure.
A provisioning workflow creates tenant-scoped Key Vault keys and access policy/RBAC, associates approved Cosmos isolation units with CMKs, records key versions, and automates rotation, disablement, recovery, monitoring, and offboarding.
Primary services: Cosmos DB, Key Vault, Managed Identities, Private Link, Azure Monitor.
This repository implements the first production-oriented vertical slice: a fail-closed, adapter-neutral control plane that validates tenant scope, freshness, approvals, secretless identity, private access, and the exact project action before producing a deterministic execution plan. Azure adapters consume that plan; they are deliberately outside the local simulator so local tests cannot claim a live cloud change occurred.
The upper boundary names the principal services and technologies used by this repository. The lower boundary shows the implemented control flow: desired state is validated, provider action remains an explicit integration gate, and sanitized evidence is retained for review and deterministic replay.
Recommended view: Tenant key and encryption lifecycle. A lifecycle view is the strongest complement because it makes state transitions, approval points, expiry or recovery, and operational ownership explicit.
The view follows Create tenant-owned key → Bind managed identity → Encrypt tenant database → Rotate and verify access. Use it during design reviews, operational walkthroughs, and failure-mode discussions; use the logical architecture above when the question is which technologies integrate.
Requirements: Python 3.11+ and Git. No Azure credentials are required.
./scripts/validate.sh
python3 src/control_plane.py --request examples/approved-request.jsonThe command emits canonical JSON with a stable idempotency key. The denied fixture exits with status 2 and explains the failed invariants.
- Managed identity or workload identity only; embedded credentials are denied.
- Public network access and stale evidence are denied.
- Production and break-glass targets require explicit approval.
- The IaC entry point is opt-in and defaults to deploying nothing.
- Evidence output contains identifiers and decisions, never credential values.
Local validation covers 13 tests, deterministic replay, JSON parsing, Python
compilation, ignore hygiene, and Bicep compilation when a compiler is present.
It does not prove Azure deployment, service licensing, quota, data-plane
permissions, provider/API availability, cloud failover, load, cost, or teardown.
See docs/test-matrix.md and docs/runbook.md before any integration trial.
See CONTRIBUTING.md, SECURITY.md, SUPPORT.md, and LICENSE. The reference
is intentionally conservative and uses synthetic identifiers only.
- Architecture
- Threat model
- Operations runbook
- Test matrix
- Cost model
- Security policy
- Contributing guide
- Support policy
- Changelog
- License
Resource behavior and deploy-time values are intentionally separated:
- Bicep template — Azure resources, modules, and security controls.
- Bicep parameters — environment-specific names, regions, identities, and feature inputs.
Start with the parameter file's safe values, replace synthetic identifiers, and run an Azure what-if before deployment.
Azure product icons come from Microsoft's official Azure Architecture Icons. Open-source marks are sourced from Simple Icons when shown; each mark identifies its respective technology.