Confidential Computing for Sensitive Analytics on Azure

In a nutshell

Imagine a sealed glovebox in a lab — the kind used for handling a hazardous or contaminated sample. The material goes inside, you work on it through the box’s built-in gloves, and the whole thing is tamper-evident: you can never touch the sample with your bare hands, and neither can anyone standing in the room watching you. Even the lab that owns the glovebox cannot reach in while it is sealed. And before you trust it with something precious, you inspect the seal and confirm it is the exact box, holding the exact tools, that you agreed to.

Confidential computing is a glovebox for data. The sensitive work — joining two datasets, running a model over private records — still happens on decrypted data, because computers cannot compute on ciphertext at any useful speed. But it happens inside a hardware-sealed region of the CPU whose memory is encrypted with a key the chip never hands out. The cloud operator, the hypervisor beneath your VM, a host administrator with root, a memory-scraping attacker — none of them can read into the box while your data is inside it. And there is a tamper-proof seal you can check from the outside, called attestation, that cryptographically proves the box is genuine silicon running exactly the code you approved, before any secret is placed inside.

Why should a beginner care? For decades we encrypted data in only two of its three states. At rest (sitting on a disk) and in transit (moving across a network), encryption is routine and boring. But the third state — in use, the instant the data is actually being processed — was always a blind spot: to compute on data you must decrypt it into memory, and plaintext in RAM is readable by anyone privileged enough to look. Confidential computing closes that last gap. It changes the sentence a security officer has to sign from “we trust the company and the people running the machine” to “we trust a CPU vendor’s silicon and a binary whose fingerprint we verified” — a boundary a CISO and a regulator can actually reason about.

Level: Expert · Time: ~39 min

Prerequisites. You should be comfortable with what this course builds toward: Azure VMs and VM SKU families, Azure Key Vault and the difference between a vault and a single-tenant Managed HSM, Microsoft Entra ID managed/workload identities and RBAC, TLS and encryption-at-rest basics, and enough Kubernetes to read an AKS node-pool definition. The clean-room scenario earlier in this article is helpful background, but the concepts below stand on their own.

After this lesson you will be able to:

• Explain the three states of data and pinpoint exactly which gap confidential computing closes — and which it does not.
• Choose the right trusted execution environment for a workload: whole-VM (AMD SEV-SNP or Intel TDX) versus the application-enclave model (Intel SGX).
• Trace an attestation token end to end, from hardware evidence to the JWT claims a Secure Key Release policy checks.
• Reason about confidential containers (ACI and AKS/Kata) and confidential GPUs (NVIDIA H100) for confidential AI.
• Decide, for a given threat model, whether the premium is justified at all — the most valuable skill of the set.

A national pharmacy retailer and a large health insurer want to answer one commercially explosive question together: which of the insurer’s members are abandoning a newly prescribed chronic-disease medication in the first 90 days, so the two can fund a targeted adherence programme that keeps those patients on therapy. The retailer holds dispensing and refill records. The insurer holds claims, diagnoses, and member contact details. Joined, the two datasets are gold — and joining them the obvious way is illegal. This is PHI under HIPAA on the insurer side and prescription records under state pharmacy law on the retailer’s, and neither legal team will let a single raw record of the other party’s data land in their counterpart’s environment, even briefly, even encrypted at rest, because “at rest” is not the exposure they fear — they fear a privileged engineer, a compromised host, or a subpoena reaching into memory while the join runs. Each side has a standing rule: we do not hand the other party our members’ data, full stop. And yet the analysis needs both datasets in plaintext, in the same process, at the same instant, to compute the overlap.

This is the canonical clean room problem, and it is exactly what Azure confidential computing exists to solve. The trick is to build a neutral compute environment that neither party operates and that both parties can cryptographically prove is exactly the code they agreed to — running inside a hardware-encrypted boundary that even Microsoft, the cloud operator, cannot read into. Inside that boundary the two datasets are decrypted, joined, the cohort is computed, and only an aggregate result — counts, a de-identified target list under an agreed minimum cohort size — ever comes back out. The raw rows are decrypted only inside silicon that the host OS, the hypervisor, and any human with root cannot inspect. This article is the reference architecture for building that clean room properly on Azure.

Why the obvious approaches fail

Every team that hits this problem proposes the same three shortcuts first, and naming why each fails is the fastest way to get to the real design.

“Just encrypt the data and run the join.” Encryption at rest and in transit is table stakes and solves nothing here. To join two datasets you must decrypt them into memory, and the moment plaintext sits in RAM on an ordinary VM it is readable by the host hypervisor, by Microsoft’s operators in principle, by a memory-scraping attacker who escapes the guest, and by any administrator with a debugger. The legal objection is specifically about plaintext-in-use, which classical encryption never addresses.

“One party hands the other a hashed/tokenised file.” Hashing identifiers for a private set intersection helps at the margins but breaks on real healthcare data: names and dates of birth are low-entropy and trivially brute-forced from a hash, the two sides normalise fields differently, and the moment you need any attribute beyond the join key (the dispensing date, the diagnosis) you are back to sharing real data. It also produces a brittle, single-purpose pipeline that cannot answer the next question.

“Use a trusted third party.” A consultancy that ingests both datasets is the breach the lawyers are describing — you have just moved the plaintext into a fourth party with worse controls. The whole point is to remove the need to trust any operator, including the cloud and including each other.

Confidential computing threads the needle by shrinking the trusted computing base down to the CPU package and the specific, attested code you both signed off on. Trust moves from “we trust the people and the company running the machine” to “we trust AMD’s silicon and a binary whose measurement we both verified.” That is a boundary a CISO and a regulator can reason about.

Architecture overview

The design has three planes that are deliberately kept distinct: a trust/attestation plane that proves the environment before any key is released, a data plane where the encrypted datasets flow in and only aggregates flow out, and a control plane that builds, governs, and operates the whole thing without ever holding the data. The single most important property of the topology is this: the decryption keys are released to the workload only after Microsoft Azure Attestation has cryptographically verified that the code running inside the SEV-SNP boundary is exactly the agreed binary on an genuine confidential platform. No attestation, no key, no plaintext. Everything else serves that one gate.

The hardware foundation is AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging). The clean-room workload runs either on Azure confidential VMs (the DCasv5/ECasv5 families) for a single batch join, or on a confidential AKS node pool built from those same SEV-SNP VMs when the analysis needs to scale out or run as a service. SEV-SNP encrypts the VM’s memory with a key held in the CPU’s secure processor that the hypervisor never sees, and — the part that matters most for clean rooms — it adds integrity protection so a malicious host cannot corrupt, replay, or remap guest memory without detection. The host can schedule the VM; it cannot read into it.

Following the data and control flow, end to end:

1. Governed build. The clean-room application — a small, auditable program that reads two encrypted inputs, performs the agreed join and aggregation, and emits only the approved output — is built by a GitHub Actions pipeline (or Jenkins, in shops standardised on it) into a container image. Argo CD then syncs that image to the confidential AKS cluster via GitOps, so what runs in the clean room is exactly what is in the signed, reviewed Git commit — there is no kubectl apply by a human. The pipeline records the image’s measurement; both parties review and approve the exact build that will touch their data.

2. Provision the boundary. Terraform stands up the confidential VM / AKS node pool with securityType = ConfidentialVM, a vTPM, and Secure Boot enabled; Ansible handles any in-guest hardening that is not baked into the image. The infrastructure is itself code-reviewed and policy-checked before it exists.

3. Each party encrypts and uploads. The pharmacy and the insurer each independently encrypt their dataset with a data-encryption key and place the ciphertext in storage the clean room can reach. Crucially, the key that unwraps each dataset lives in that party’s own Azure Key Vault Managed HSM — a single-tenant, FIPS 140-3 Level 3 hardware module — under a secure key release (SKR) policy that the party controls. Neither raw key ever leaves the HSM except into an attested enclave.

4. The workload boots and requests attestation. When the clean-room container starts inside the SEV-SNP VM, it asks the platform for a hardware attestation report — a signed quote from the AMD secure processor and the vTPM describing the firmware, the boot state, and a measurement of the workload. It sends that report to Microsoft Azure Attestation (MAA).

5. MAA verifies and issues a token. MAA validates the AMD signature chain (proving this is genuine SEV-SNP silicon, not an emulator), checks the report against a policy both parties agreed to, and returns a signed attestation token (JWT) asserting “this is the approved code on a real confidential platform.” This token is the linchpin of the whole system.

6. Secure key release. The workload presents the MAA token to each party’s Managed HSM. The HSM’s SKR policy says, in effect, release this wrapping key only to a holder of a valid MAA token whose claims match this exact measurement and this issuer. If — and only if — the token matches, the HSM releases the key, wrapped to the enclave. The workload now holds both parties’ keys, inside encrypted memory only.

7. Decrypt, join, aggregate — all in the encrypted boundary. The two datasets are decrypted inside SEV-SNP-protected RAM, joined on the agreed identifiers, the 90-day-abandonment cohort is computed, a minimum-cohort-size (k-anonymity) threshold is enforced so no small group is re-identifiable, and only the aggregate result is produced. The plaintext never exists outside the silicon boundary.

8. Emit the approved output only. The result — counts, and a de-identified target list above the agreed k — is written out, signed with a provenance record, and handed to a downstream system (for example a ServiceNow workflow that kicks off the outreach programme). The raw inputs are discarded with the VM.

Component breakdown

A few choices carry the design and deserve the why.

Why SEV-SNP integrity, not just memory encryption. Earlier confidential-VM technology encrypted memory but did not fully protect against a malicious hypervisor replaying or remapping pages. For a clean room where the host is, by assumption, outside your trust boundary, encryption alone is insufficient — you need the SNP integrity guarantees that detect host tampering. That is precisely why the architecture pins SEV-SNP specifically and verifies it through attestation rather than trusting the platform label.

Why secure key release is the heart of it. Anyone can stand up a confidential VM; that proves nothing by itself. The security comes from binding the release of each party’s data key to a fresh attestation of the exact code. The Managed HSM’s SKR policy is the enforcement point: it will not export the wrapping key to anything that cannot present a valid MAA token whose measurement matches the approved binary. Change one line of the clean-room code and its measurement changes, the token no longer matches, and the HSM refuses the key — the data simply cannot be decrypted by tampered code. This is the property that lets each legal team say “our key never leaves our HSM except into code we approved.”

Why two separate Managed HSMs. Each party keeps custody of its own key in its own single-tenant HSM with its own quorum of admins. There is no shared key and no shared HSM. Either party can revoke at any time by changing its SKR policy, instantly and unilaterally killing the clean room’s ability to read that party’s data. Mutual, independent revocation is what makes the arrangement politically and legally acceptable.

Implementation guidance

Provision the boundary as code, and make confidentiality a hard flag. Terraform is the source of truth; the confidential properties are non-negotiable settings, not defaults you hope are on. A minimal confidential-VM shape communicates the intent:

resource "azurerm_linux_virtual_machine" "cleanroom" {
  name                = "cvm-cleanroom-prod"
  size                = "Standard_DC4as_v5"   # AMD SEV-SNP family
  # ...network, image...

  vtpm_enabled        = true
  secure_boot_enabled = true

  security_encryption {
    security_type = "DiskWithVMGuestState"    # confidential OS disk + guest state
  }
}

For the scale-out path, the AKS confidential node pool carries the equivalent flags so every pod that touches data lands on SEV-SNP silicon:

resource "azurerm_kubernetes_cluster_node_pool" "conf" {
  name                  = "conf"
  vm_size               = "Standard_DC4as_v5"
  # confidential VM node pool — pods here run inside SEV-SNP
  node_labels = { "kloudvin.io/confidential" = "true" }
  node_taints = ["confidential=true:NoSchedule"]   # only attested workloads land here
}

The taint matters: it guarantees the join workload cannot accidentally be scheduled onto a non-confidential node where its memory would be readable.

Write the secure key release policy carefully — it is your real perimeter. The SKR policy on each Managed HSM key is what the whole guarantee rests on. It binds release to the MAA issuer and to specific claims from the attestation token. Conceptually:

release if:
  token.iss            == "https://cleanroom-maa.<region>.attest.azure.net"
  token["x-ms-isolation-tee"]["x-ms-attestation-type"] == "sevsnpvm"
  token["x-ms-isolation-tee"]["x-ms-compliance-status"] == "azure-compliant-cvm"
  token.measurement    == <approved-image-digest>   # the binary both parties signed

Pin the issuer to your MAA instance, require the SEV-SNP isolation type, and bind to the approved measurement so a different binary cannot pull the key. Treat the MAA policy itself as a jointly reviewed artifact in Git — both parties approve the attestation policy and the SKR policy together, and changes route through ServiceNow dual approval.

Kill standing keys; attest everything. No API keys to storage or HSM — the workload authenticates with Entra Workload Identity on AKS, and human operators reach the consoles via Okta federated to Entra ID with conditional access, so the people who operate the platform are strongly authenticated yet, by design, can never see plaintext. The few non-HSM secrets the build and ops tooling need (registry tokens, third-party API creds) live in HashiCorp Vault with short dynamic leases — and Vault deliberately never holds the dataset-wrapping keys, which belong only in the Managed HSMs.

Make the running code provably the reviewed code. The clean-room image is built by GitHub Actions (OIDC to Azure, no stored secrets) or Jenkins, its digest is recorded, and Argo CD deploys by digest via GitOps so there is no out-of-band path to run unreviewed code. Wiz Code scans the Terraform and manifests before merge; Wiz continuously verifies in production that every node in the pool is still in confidential mode and alerts the instant one is not.

Enterprise considerations

Security and the trust boundary. State the trusted computing base explicitly, because that clarity is the entire value proposition: you trust the AMD CPU package, the attested firmware/boot chain, and the specific measured binary — and nothing else, not the hypervisor, not the host OS, not Microsoft’s operators, not the other party’s administrators, not your own cluster admins. Layer defence in depth on top: CrowdStrike Falcon sensors on the host fleet and control plane feed both organisations’ SOCs; Wiz provides continuous CSPM and catches configuration drift such as a node silently falling out of confidential mode or a public-exposure change; a failed or unexpected attestation auto-raises a ServiceNow incident so security has a ticket, not just a log line. Akamai fronts the operator consoles and the result-retrieval API with TLS, WAF, and bot mitigation. And critically, observability is constrained: Dynatrace or Datadog instrument health, throughput, and the all-important attestation success rate, but the agents emit metadata only — never a record-level field — so the telemetry pipeline can never become the leak the architecture was built to prevent.

Cost. Confidential SKUs carry a premium and the design adds moving parts, so engineer for it.

The honest framing: confidential VMs cost noticeably more than equivalent general-purpose VMs, and Managed HSM has a real monthly floor. The premium buys a legal capability — a collaboration that otherwise simply cannot happen — so the comparison is not “cheaper than a normal VM” but “cheaper than the deal not existing.”

Scalability. A single SEV-SNP VM has a fixed memory ceiling, which bounds how large a join you can hold in encrypted RAM. Two paths scale past it: move to the confidential AKS node pool and partition the join (shard by a hash of the identifier so each pod joins a slice inside its own attested boundary), or pre-aggregate so the in-enclave step works on summaries rather than raw rows. Attestation adds a few seconds to cold start — fine for batch, and amortised for a long-running service. The realistic ceiling is confidential-SKU regional capacity, so a large recurring programme plans region and quota early.

Failure modes, named before they page you.

• Attestation fails after a platform update. Azure host firmware updates can change the attestation report; an over-tight MAA policy then rejects a legitimately healthy platform and the HSM withholds the key, so the job cannot start. Mitigation: track the attestation success-rate metric, version the MAA policy, and test policy changes against current platform reports before rolling them.
• SKR policy / measurement drift. A rebuilt image changes its measurement; if the SKR policy was not updated in lockstep, key release fails and the join silently cannot decrypt. Mitigation: treat image digest and SKR policy as a single versioned, jointly-approved unit promoted together through the pipeline.
• Accidental scheduling onto a non-confidential node. Without the taint/label discipline, a pod handling plaintext could land on ordinary silicon. Mitigation: the NoSchedule taint and a Wiz check that fails the deploy if any data-touching workload is not confined to the confidential pool.
• Result leakage through small cohorts. A join that returns a cohort of three is effectively re-identifying. Mitigation: enforce the minimum-cohort-size threshold inside the enclave and suppress or generalise anything below it before output.
• HSM unavailability. If a party’s Managed HSM is unreachable, no key is released and the job halts — by design. Mitigation: this is fail-closed and correct; plan availability and a documented re-run, never a bypass.

Reliability and DR. Decide the numbers per plane, and accept that the clean room is fail-closed: if attestation or key release cannot complete, the analysis does not run, which is the safe direction. The encrypted inputs live in geo-redundant storage and are the durable source of truth — a job is simply re-run from them, so the conversational RTO/RPO conversation is replaced by “can we re-execute the join in the paired region.” Managed HSM supports backup/restore and multi-availability-zone resilience; replicate the HSM and its SKR policy to a paired region, and keep the MAA policy and Terraform in Git so the entire boundary is reproducible. A pragmatic target: re-run a failed job within hours in-region, and reconstruct the whole clean room in a paired region from code and geo-redundant ciphertext within a day — there is no live state to lose, only the (re-runnable) computation.

Governance and auditability. This is where confidential computing shines for regulators. Every run produces an attestation evidence record — the MAA token, the image measurement, the SKR decision — that proves which exact code touched the data and under what policy, retained as the audit trail. Pin image versions by digest, never a floating tag; keep the clean-room code, the MAA attestation policy, and the SKR policies all in version control under joint review; and route every new analysis through a ServiceNow dual-party change approval so both legal teams sign each specific question before a single record is decrypted. Wiz independently verifies the controls are actually holding in production.

Comparison: how the privacy techniques line up

Confidential computing is one of several privacy-enhancing technologies, and the honest engineering choice depends on the workload. The clean room above can even compose these — for instance, running a secure-multiparty protocol inside an attested enclave for defence in depth.

The pattern in this article picks confidential computing for the compute and borrows differential-privacy-style suppression (the minimum-cohort threshold) for the output — hardware protects the join while the k-anonymity gate protects the answer.

Explicit tradeoffs

Accept these or do not build it. You are moving your trust to AMD’s silicon and firmware and to Microsoft’s attestation service — a different, smaller, but real trust assumption than “trust the operator,” and one your security team must consciously endorse. The confidential SKUs cost more and the moving parts multiply: attestation policies that can reject healthy platforms after an update, SKR policies that must track image measurements exactly, GitOps discipline so no unreviewed code can run, and taints so no plaintext touches ordinary nodes. The system is deliberately fail-closed, which means a misconfigured policy or an unreachable HSM stops the analysis cold rather than degrading — correct, but operationally demanding. Debugging is genuinely harder: you cannot attach a memory debugger to a workload whose entire value is that no one can read its memory, so you lean on metadata-only telemetry and the attestation-success metric instead of a heap dump.

When something simpler wins. If only one party’s data is involved and the threat you care about is at-rest or in-transit, ordinary Key Vault encryption and Private Endpoints are enough — you do not need confidential computing. If the question is a single, fixed function like “how many identifiers overlap,” a purpose-built private set intersection via secure multi-party computation may be lighter than standing up enclaves. If you only need to publish aggregate statistics and never join raw rows, differential privacy on each party’s own outputs sidesteps the joint-compute problem entirely. And if there is no genuine mutual distrust — same legal entity, same trust domain — a normal governed analytics platform is far cheaper. Confidential computing earns its complexity precisely when two parties who will not share raw data must nonetheless compute over it together, with a result both can trust and a regulator can audit.

The shape of the win

For the pharmacy and the insurer, the payoff is not “a secure VM.” It is that two organisations who were legally forbidden from sharing a single member record can now, together, identify exactly the patients abandoning their therapy in the first 90 days — fund an intervention that keeps those people on treatment — and do it with a cryptographic audit trail proving that neither party ever saw the other’s data in the clear and that the only code that touched it was the binary both legal teams signed. The attestation token is the document that makes the deal legal; the Managed HSM’s refusal to release a key to unapproved code is the control that makes it safe; and the minimum-cohort gate is what makes the output safe to act on. Everything upstream — the SEV-SNP boundary, the MAA policy, the dual HSMs, the GitOps build, the Wiz posture checks, the metadata-only Dynatrace telemetry — exists so a CISO, a compliance officer, and two competing legal teams each say yes to a collaboration that, done any other way, would never have left the meeting room.

Going deeper

The three states of data — and the one everyone forgets

Every byte you are responsible for is always in exactly one of three states, and each has had its own protection story:

The first two are solved problems. The third was the permanent gap: a CPU cannot add two encrypted numbers, so to do anything with data you decrypt it into RAM — and on an ordinary VM that RAM is visible to the hypervisor beneath you and to whoever operates the physical host. Confidential computing is the set of hardware features that finally encrypts data in use, so plaintext exists only inside a boundary the operator cannot enter. Hold onto this framing: every technology below is just a different way of building that in-use box.

Two shapes of trusted execution environment

A trusted execution environment (TEE) is a hardware-isolated region whose memory is encrypted and integrity-protected by the CPU. Azure gives you two fundamentally different shapes of TEE, and picking the wrong one is the single most common early design error.

Whole-VM TEEs — lift and shift. Here the entire virtual machine is the boundary. You take an existing Linux or Windows workload and run it unchanged while the silicon encrypts all of guest memory.

• AMD SEV-SNP (Secure Encrypted Virtualization – Secure Nested Paging) backs the DCasv5 / ECasv5 confidential-VM families this article uses. SNP’s contribution over plain SEV is integrity — it stops a malicious hypervisor from remapping, replaying, or corrupting guest pages, which is precisely the guarantee a clean room needs.
• Intel TDX (Trust Domain Extensions) is the equivalent from Intel, exposed through the DCesv5 / ECesv5 confidential-VM families. It wraps the guest in an isolated “trust domain” sealed off from the host and the VMM. Functionally it plays the same role as SEV-SNP; which one you get depends on the SKU family you pick, and attestation reports the type so your policy can require a specific one.

Whole-VM TEEs mean no code changes and a large encrypted memory space, at the price of a larger trusted computing base — your entire OS and every library in the guest is inside the boundary and must be trusted.

Application enclaves — smallest possible TCB. Intel SGX (Software Guard Extensions), on the DCsv3 / DCdsv3 series, takes the opposite approach. Instead of trusting a whole VM, you carve your application into an untrusted host part and a tiny trusted enclave holding only the secret-handling code. Only the enclave’s pages live in the encrypted Enclave Page Cache (EPC); the OS, the hypervisor, even the rest of your own process sit outside the boundary and cannot read in.

• The upside is a minimal TCB — you trust a few thousand lines, not a whole distro — which is why SGX suits key-management and small, high-value routines.
• The cost is real: you must partition the app (with the Open Enclave SDK, or a library OS such as Gramine or Occlum that runs an unmodified binary inside an enclave), historical EPC size limits constrain how much you can hold at once, and enclave transitions add overhead.

The rule of thumb: CVM (SEV-SNP / TDX) for “protect this existing workload”; SGX for “protect this one small secret computation with the tightest possible trust boundary.” The clean room in this article chose a CVM on SEV-SNP because a data join is a whole ordinary program, not a hand-partitioned enclave.

Attestation is the whole game: the MAA token flow

A confidential VM by itself proves nothing — anyone can boot one, and a VM with the confidential flag quietly turned off looks identical to your application. The security comes entirely from remote attestation: forcing the environment to prove, cryptographically and freshly, that it is genuine TEE silicon running the exact code you approved, before you trust it with a key. Microsoft Azure Attestation (MAA) is the service that adjudicates that proof and issues a portable token. The flow, step by step:

1. Evidence. The workload asks the platform for a hardware quote / attestation report — signed by the AMD or Intel secure processor, and on a CVM quoting the vTPM. It carries firmware and boot measurements plus a report-data field the workload fills with, for example, the hash of an ephemeral public key.
2. Submit to MAA. The workload sends that evidence to its MAA provider endpoint (https://<name>.<region>.attest.azure.net).
3. Verify. MAA validates the signature chain back to the vendor root (proving the quote came from real silicon, not an emulator) and evaluates it against an attestation policy you authored — a set of claim rules both parties agreed to.
4. Token. MAA returns a signed JWT whose claims assert the result: x-ms-attestation-type (sevsnpvm / tdxvm / sgx), x-ms-compliance-status (azure-compliant-cvm), an x-ms-isolation-tee object with the TEE-specific measurements, and your report-data binding.
5. Rely. A relying party — a Key Vault, an app, the other clean-room participant — validates that JWT against MAA’s signing certificates (published at the provider’s JWKS / OpenID-metadata endpoint), pins the issuer, and checks the claims itself. Only then does it act.

Two properties make this trustworthy: the token is fresh (bound to a nonce / report-data so it cannot be replayed) and it is portable (a standard JWT, so any service that can validate a signature can be a relying party). Pin the issuer to your MAA instance and treat the attestation policy as a jointly reviewed Git artifact — because whoever controls the policy controls what counts as “trusted.”

Confidential containers: ACI, AKS / Kata, and the CCE policy

Confidential VMs protect a VM; confidential containers bring the same in-use protection to a container without making you think in VMs.

• Confidential containers on ACI (Azure Container Instances) run a container group inside a SEV-SNP boundary. What you must attest is no longer “an OS image” but “these exact containers,” so the platform derives a CCE policy (Confidential Computing Enforcement) — a Rego document, generated by the az confcom tooling, that enumerates the allowed images (by digest), commands, mounts, and environment. Its hash is bound into the attestation report’s host-data field, so the policy you approved is provably the policy that ran. Tamper with the container spec and the measurement changes.
• Confidential containers on AKS build on Kata Containers: each pod runs inside its own lightweight utility VM on SEV-SNP silicon, so pods are isolated from the host and from each other by hardware, not merely by namespaces and cgroups. You target them with a confidential runtimeClassName plus node selectors and tolerations, and a CCE-style policy governs what may run.

This is a finer-grained tool than the “confidential AKS node pool” the article provisions: the node pool puts ordinary pods on confidential hardware; Kata confidential containers give each pod its own attested VM boundary and a per-workload policy. (Confidential-SKU and confidential-container availability varies by region — confirm both before committing an architecture to a region.) A representative pod that must land only on the confidential runtime:

apiVersion: v1
kind: Pod
metadata:
  name: cleanroom-join
spec:
  runtimeClassName: kata-cc          # per-pod utility VM on SEV-SNP
  nodeSelector:
    kloudvin.io/confidential: "true"
  tolerations:
    - key: confidential
      operator: Equal
      value: "true"
      effect: NoSchedule
  containers:
    - name: join
      image: registry.example.com/cleanroom-join@sha256:PLACEHOLDER_DIGEST

Confidential GPUs: pulling the H100 into the boundary

Confidential AI over genuinely sensitive data — training or inference on private records — needs the accelerator inside the boundary too, or you have simply moved the plaintext one PCIe hop away into GPU memory the host can read. Azure’s NCC H100 v5 series (NCCadsH100v5) pairs an AMD SEV-SNP CPU TEE with an NVIDIA H100 running in confidential-computing mode. Two things change versus a CPU-only CVM:

• The GPU attests too. The H100 produces its own signed attestation of its firmware and confidential state, verified through NVIDIA’s attestation path, so your relying party trusts both the CPU quote and the GPU quote before releasing model weights or data keys.
• CPU↔GPU traffic is encrypted. Data crossing the PCIe bus moves through encrypted bounce buffers, so it is never exposed in the clear to the host, even in flight between the two TEEs.

The use case is the clean room’s close cousin: run a model over combined sensitive data — or protect valuable model weights from the very infrastructure they run on — with an attestation trail proving the operator saw neither.

Secure Key Release: turning “attested” into “authorized”

Attestation produces a token; Secure Key Release (SKR) is what turns that token into access. In Azure Key Vault Premium or Managed HSM you create a key as exportable with an attached release policy — a JSON rule set naming a trusted MAA authority and the exact claims a token must carry. The TEE calls the vault’s release operation, presents its fresh MAA JWT, and the vault exports the key only if the token satisfies the policy — and even then returns the key wrapped to a public key from the attestation report, so the plaintext key materialises only inside the enclave. Conceptually the policy is:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://cleanroom-maa.<region>.attest.azure.net",
      "allOf": [
        { "claim": "x-ms-isolation-tee.x-ms-attestation-type",   "equals": "sevsnpvm" },
        { "claim": "x-ms-isolation-tee.x-ms-compliance-status",  "equals": "azure-compliant-cvm" }
      ]
    }
  ]
}

This is the mechanism behind the article’s central guarantee: change one line of the workload and its measurement changes, the claims no longer match, and the HSM simply refuses to release the key — tampered code cannot decrypt the data. Managed HSM (single-tenant, FIPS 140-3 Level 3, quorum-administered) is the right custodian when, as here, each party must hold and revoke its own key independently.

vTPM, measured boot, and confidential disk encryption

Underneath a confidential VM sit three features worth naming, because together they extend the boundary from the CPU out to the boot state and the disk:

• A virtual TPM (vTPM) bound to the TEE gives the guest a hardware root of trust for storing boot measurements (PCRs) and keys — and it is what the attestation quote can reference.
• Measured boot records each stage of the boot chain into those PCRs, so attestation can prove the VM booted an approved, unmodified image. This is the confidential extension of Trusted Launch (Secure Boot + vTPM).
• Confidential OS-disk encryption — the DiskWithVMGuestState security type the article’s Terraform sets — encrypts the OS disk and the VM guest state with a key protected by the TEE / vTPM, so even the disk, not just live RAM, is sealed to the confidential boundary and cannot be mounted and read elsewhere. The alternative VMGuestStateOnly protects only the guest state and leaves the OS disk conventionally encrypted; choose deliberately.

When the threat model justifies the cost

Confidential computing is not a default; it is a specific answer to a specific threat. Reach for it when your threat model genuinely contains one of the situations on the left, and stay with a cheaper control when only the situations on the right apply.

The honest test: if you cannot name a privileged insider or a co-party you are removing from the trusted set, you probably do not need it yet. Confidential computing earns its premium precisely when trust in the operator is the very thing you are trying to eliminate.

Practice challenges

Work these top to bottom — they escalate from “can you read the map” to “can you design the boundary.” Each has a solution; try first, then open it.

1. Name the gap (beginner). Data lives in three states, and encryption-at-rest plus TLS already protect two of them. Which state does confidential computing protect, and give one concrete threat that only it addresses.

<details><summary>Solution</summary>

It protects data in use — plaintext while it is loaded in memory and being processed. A threat only it addresses: a privileged host administrator or a compromised hypervisor reading the join’s plaintext straight out of RAM while the computation runs. At-rest and in-transit encryption do nothing against an attacker who can read live host memory.

Why: The whole value proposition is that third state. If you cannot articulate that at-rest / in-transit are already solved and in-use is the gap, every downstream decision (attestation, SKR) looks like over-engineering. </details>

2. Pick the TEE shape (beginner–intermediate). You have two workloads: (a) a two-million-line legacy Java analytics app you must protect without touching its code, and (b) a 300-line routine that unwraps and uses a signing key. Which TEE model fits each — whole-VM (SEV-SNP / TDX) or an SGX enclave — and why?

<details><summary>Solution</summary>

(a) → a confidential VM (SEV-SNP or TDX): lift-and-shift, no code changes, large encrypted memory, accepting a bigger TCB (the whole OS). (b) → an SGX enclave: partition the tiny secret-handling routine into an enclave for the smallest possible TCB, accepting that you must build against an enclave SDK or library OS.

Why: The axis is code changes and TCB size versus blast radius. Choosing SGX for the legacy monolith means re-architecting two million lines; choosing a whole CVM for a key routine needlessly trusts an entire OS with your crown-jewel key. </details>

3. Read the token (intermediate). An MAA JWT arrives with x-ms-attestation-type = "sevsnpvm" and x-ms-compliance-status = "azure-compliant-cvm", but its iss (issuer) is https://someone-elses-maa.eastus.attest.azure.net. Your SKR policy pins your own MAA instance. Does the HSM release the key? Should it?

<details><summary>Solution</summary>

No — and correctly not. The TEE-type and compliance claims look healthy, but the issuer does not match the authority your release policy pins. A token from an MAA instance you do not control could have been issued under a policy you never reviewed, so honouring it would defeat the guarantee.

Why: Attestation is only as trustworthy as whose attestation you accept. Pinning the issuer / authority is the step beginners skip; without it, anyone who can obtain any valid-looking MAA token could pull your key. </details>

4. Fix the boundary (intermediate–advanced). A teammate’s Terraform for the confidential node passes terraform plan but protects nothing in review. What is wrong?

resource "azurerm_linux_virtual_machine" "cleanroom" {
  name         = "cvm-cleanroom-prod"
  size         = "Standard_D4as_v5"   # general-purpose family
  vtpm_enabled = false
  # no security_encryption block
}

<details><summary>Solution</summary>

Three faults: the SKU is a general-purpose D4as_v5, not a confidential DC4as_v5 (no SEV-SNP at all); vtpm_enabled is false so there is no measured-boot root of trust to attest; and there is no security_encryption block setting security_type = "DiskWithVMGuestState". Corrected: use a Standard_DC4as_v5 size, set vtpm_enabled = true and secure_boot_enabled = true, and add security_encryption { security_type = "DiskWithVMGuestState" }.

Why: Confidentiality must be an explicit, reviewed flag, never a hoped-for default. A plausible-looking VM with the confidential SKU swapped out gives zero in-use protection while looking fine in a diagram. </details>

5. Bind the key to the code (advanced). Explain, in terms of measurements, why a rebuilt clean-room image can suddenly fail to decrypt its inputs even though nothing about the infrastructure changed — and the operational discipline that prevents it.

<details><summary>Solution</summary>

The SKR release policy binds key release to the workload’s measurement (image digest). A rebuild — even a no-op dependency bump — produces a new digest, so the token’s measurement claim no longer matches the value the release policy expects, and the HSM refuses the key: the job starts but cannot decrypt (fail-closed). Discipline: treat the image digest and the SKR / MAA policy as a single versioned, jointly-approved unit promoted together, pin by digest (never a floating tag), and test the new policy against a real attestation report before promoting it.

Why: “Measurement drift” is the classic confidential-computing outage. Grasping that the security property (tampered code can’t get the key) and the outage (rebuilt code can’t get the key) are the same mechanism is the core mental model. </details>

6. Extend to confidential AI (expert). The two parties now want to train a model on the combined data using GPUs instead of a CPU join. What changes in the attestation and the data flow, and what new failure mode appears?

<details><summary>Solution</summary>

Move to a confidential-GPU SKU (NCC H100 v5). Now two TEEs must attest: the AMD SEV-SNP CPU quote and the NVIDIA H100’s own confidential-mode attestation — the relying party and the SKR policy must require both before releasing data keys or model weights. Data crossing the PCIe bus moves through encrypted bounce buffers, staying sealed CPU↔GPU. New failure mode: a GPU that boots in non-confidential mode (or a driver / firmware version outside the attested set) can pass the CPU attestation yet fail the GPU attestation — so the policy must gate on the GPU claim too, or plaintext could reach an unprotected accelerator.

Why: Confidential AI is not “CVM plus a GPU”; the accelerator is a second boundary with its own root of trust. Missing the GPU attestation is the subtle hole that re-opens exactly the exposure the architecture was built to close. </details>

Common beginner mistakes

“It’s encrypted, so it’s safe.” The reflex is to point at encryption-at-rest and TLS and call it done. Those cover two states; the entire reason confidential computing exists is the in-use state they leave wide open. Right model: name which of the three states each control protects, and notice that a privileged host reading live RAM is defeated by none of the classic controls.

“I launched a confidential VM, so my data is protected.” A CVM with no attestation proves nothing — it is indistinguishable from a normal VM to anything relying on it, and a misconfigured deploy can silently drop out of confidential mode. Right model: the security is not the VM, it is the attestation + Secure Key Release gate. If no key release is bound to a fresh, verified attestation, you have bought an expensive ordinary VM.

Trusting the platform label instead of verifying. “The portal says it’s confidential” is a claim, not a proof. Right model: require an MAA token, validate its signature against the provider’s published keys, pin the issuer, and check the type / compliance / measurement claims yourself. Trust the math, not the label.

Baking the secret into the image. Putting a data key or connection string in the container image or an environment variable means anyone who can pull the image has the secret — and the measurement now certifies nothing useful about safety. Right model: ship no long-lived secret in the image; the key arrives only after attestation via SKR, wrapped to the enclave.

Confusing SGX with a confidential VM. Beginners try to “lift and shift” onto SGX and are baffled that their app will not run, or wrap a tiny key routine in a whole CVM and needlessly trust an entire OS. Right model: CVM (SEV-SNP / TDX) = run existing code unchanged, larger TCB; SGX = partition a small trusted enclave, smallest TCB. Match the tool to the workload.

Forgetting the taint, so plaintext lands anywhere. Without node taint / label discipline, the pod that handles decrypted data can be scheduled onto an ordinary node where its memory is readable. Right model: taint the confidential pool NoSchedule, label the workload to tolerate only it, and let a posture scanner fail the deploy if any data-touching pod escapes the boundary.

Over-tight, unversioned policies that fail closed at 3 a.m. An MAA or SKR policy pinned too rigidly rejects a legitimately-healthy platform after an Azure firmware update, and the HSM withholds the key. Right model: the system is fail-closed by design — so version the policies, watch the attestation-success-rate metric, and test policy changes against current platform reports before rolling them.

Leaking through telemetry and debugging. Shipping record-level fields to logs, traces, or a heap dump re-opens the exposure the enclave closed — and you cannot attach a memory debugger to the one workload whose entire value is that no one can read its memory. Right model: emit metadata only, lean on the attestation-success metric instead of a debugger, and treat the observability pipeline as in-scope for the same review as the code.

Glossary

• Confidential computing — Protecting data in use by processing it inside a hardware-encrypted, integrity-protected region of the CPU that the operator, host OS, and hypervisor cannot read into.
• Three states of data — At rest (in storage), in transit (on the network), and in use (in memory being processed). Confidential computing addresses the last.
• Trusted execution environment (TEE) — A CPU-enforced region with encrypted, integrity-protected memory isolated from everything outside it, including privileged software.
• AMD SEV-SNP — Secure Encrypted Virtualization–Secure Nested Paging: whole-VM memory encryption plus integrity (anti-remap / anti-replay), backing Azure’s DCasv5 / ECasv5 confidential VMs.
• Intel TDX — Trust Domain Extensions: Intel’s whole-VM TEE (Azure DCesv5 / ECesv5), isolating a guest “trust domain” from the host and VMM.
• Intel SGX — Software Guard Extensions: an application-enclave TEE (Azure DCsv3 / DCdsv3) protecting a small partitioned region rather than a whole VM.
• Enclave — The trusted, encrypted portion of an application under SGX; only its pages are protected, giving the smallest trusted computing base.
• EPC (Enclave Page Cache) — The protected physical memory SGX enclaves execute in; historically size-limited.
• Confidential VM (CVM) — A whole VM running inside a TEE (SEV-SNP or TDX), letting existing workloads run unchanged with in-use protection.
• Trusted computing base (TCB) — The set of hardware and software you must trust for security to hold. Confidential computing shrinks it toward “the CPU and the measured code.”
• Attestation / remote attestation — Cryptographically proving an environment is genuine TEE silicon running approved code, before it is trusted with secrets.
• Microsoft Azure Attestation (MAA) — Azure’s service that verifies TEE evidence against a policy and issues a signed attestation token.
• Attestation token (JWT) — The signed JSON Web Token MAA returns, carrying claims (TEE type, compliance status, measurements) that relying parties validate and pin.
• Measurement — A cryptographic hash of firmware, boot state, or the workload image; the fingerprint attestation checks and SKR binds to.
• Secure Key Release (SKR) — A Key Vault Premium / Managed HSM feature that releases an exportable key only to a TEE presenting an attestation token satisfying a release policy, wrapped to the enclave.
• Release policy — The JSON rule set on an SKR key naming the trusted attestation authority and the exact claims a token must carry.
• Managed HSM — A single-tenant, FIPS 140-3 Level 3, quorum-administered hardware key store supporting SKR; each party can custody and revoke its own key.
• vTPM — A virtual Trusted Platform Module bound to the TEE, storing boot measurements (PCRs) and acting as a root of trust for attestation.
• Measured boot — Recording each boot stage into the vTPM so attestation can prove the VM booted an approved, unmodified image.
• Trusted Launch — The Azure baseline of Secure Boot + vTPM; confidential VMs extend it with guest-state and disk protection.
• Confidential OS disk encryption — Encrypting the OS disk and guest state with a key sealed to the TEE (DiskWithVMGuestState), binding the disk itself to the confidential boundary.
• Confidential containers — Containers run inside a TEE — on ACI as a SEV-SNP container group, or on AKS via Kata Containers giving each pod its own attested utility VM.
• Kata Containers — A runtime that wraps each pod in a lightweight VM; on SEV-SNP it provides hardware isolation per pod for confidential containers.
• CCE policy (Confidential Computing Enforcement) — A Rego policy (generated by az confcom) enumerating the exact allowed images / commands / mounts, whose hash is bound into the attestation report.
• Confidential GPU — A GPU (Azure NCC H100 v5 / NVIDIA H100) running in confidential mode with its own attestation and encrypted CPU↔GPU transfer, for confidential AI.
• Bounce buffer — The encrypted staging area through which data crosses the PCIe bus between CPU and GPU TEEs without exposure to the host.
• Clean room — A neutral, attested compute environment where multiple distrustful parties join data and receive only an approved aggregate, never each other’s raw records.
• k-anonymity / minimum cohort size — An output control that suppresses results for groups too small to be safe, so an aggregate cannot re-identify individuals.
• Homomorphic encryption — Computing directly on ciphertext with no plaintext ever, at large performance cost; a cryptographic alternative to hardware TEEs.
• Secure multi-party computation (SMPC) — A protocol letting parties jointly compute a function without any party seeing the others’ inputs, using cryptography rather than trusted hardware.
• Differential privacy — Adding calibrated noise to outputs so individuals cannot be re-identified from published aggregates; complements in-use protection.
• Fail-closed — A design where, if attestation or key release cannot complete, the workload stops rather than proceeding insecurely.