Skip to main content

How Polaris Works

This page walks through the life of a Polaris deployment: what happens when a confidential workload boots, how a client decides to trust it, and what keeps that trust honest afterwards. It describes the mechanics at the level you need to reason about the security model; the exact protocols and formats live in the implementation.

1. The workload boots inside a TEE​

You give Polaris an ordinary container with your unmodified workload. Polaris deploys it into a confidential virtual machine, a VM whose memory is encrypted by the CPU with keys that never leave the silicon. On AMD hardware this is SEV-SNP, on Intel it is TDX, and on supported GPUs NVIDIA's confidential computing mode extends the boundary to GPU memory as well.

Inside that VM, the Polaris Secure Proxy starts in front of your workload. All external traffic passes through it, your application listens on plain HTTP inside the boundary and needs no code changes.

Two things happen at boot that matter for everything else:

  • The proxy generates its remotely attested TLS key inside the TEE. On platforms with an isolated security module, the private key is created in a hardware-protected vTPM at a privilege level even the guest operating system cannot read.
  • The hardware produces an attestation report: a data structure, signed by a key fused into the processor at manufacturing, that captures the identity and launch measurement of the environment.

2. Attestation is bound to the connection​

A signed hardware report on its own only proves that some trusted environment exists somewhere. The classic attack is relay: a malicious server forwards a genuine report from a real TEE while terminating your TLS connection itself.

Polaris prevents this by binding the attestation to the TLS session, an approach commonly called RA-TLS. A fingerprint of the proxy's TLS public key is embedded into the hardware-signed report itself. When a client verifies the report, it also checks that the key securing its current connection is the same key the hardware vouched for. A relayed report fails that check, because the relay cannot terminate TLS with a key it does not have, and it cannot get that key into a hardware-signed report without actually being the attested environment.

3. The client verifies before trusting​

Before sending anything sensitive, a client (typically using the Polaris SDK) performs verification:

  1. Fetch the attestation evidence from the proxy.
  2. Verify the signature chain up to the silicon vendor's published root keys: AMD, Intel, or NVIDIA depending on the platform.
  3. Check the launch measurement and platform properties against expected values, so the environment is not just a TEE but your TEE running your stack.
  4. Check the TLS binding described above.
  5. Pin the connection.

Depending on the platform, verification either goes through the cloud provider's attestation service or, on platforms that support it, checks the raw hardware report directly against the chip vendor's keys, with no cloud service in the trust path at all. In that mode the only parties you trust are the silicon manufacturer and yourself.

4. Data stays encrypted end to end​

Once the environment is verified, data protection is layered:

  • In transit, everything runs over TLS 1.3 terminated inside the TEE, with post-quantum hybrid key exchange supported. Optionally, the Polaris SDK adds a second envelope: request and response bodies are encrypted client-side with keys negotiated against the attested environment, so even TLS-terminating middleboxes on your own side never see plaintext.
  • In use, plaintext exists only in TEE-encrypted memory.
  • At rest, data is encrypted before it touches any disk, database, or object store. The decryption keys live in a cloud KMS, and access to them is controlled by attestation, which is the next point.

5. Trust is continuously enforced​

A verified boot is a snapshot; environments drift, get patched, or get attacked. Polaris treats attestation as an ongoing process run by an independent component, the Policy Manager:

  • The proxy periodically sends fresh evidence: hardware attestation, workload image identity, and runtime signals collected by the Sentinel agent (behavioral events and kernel integrity observed from inside the environment).
  • The Policy Manager appraises this evidence in layers, from platform to workload image to runtime behavior, against a baseline established at deployment.
  • Every appraisal has teeth: while the environment is healthy, the Policy Manager maintains the workload's access to its KMS keys. If appraisal fails, that access is revoked automatically. A tampered environment keeps running, but it can no longer decrypt the data it exists to protect, and the enforcement gate in the proxy stops serving traffic.
  • Appraisal results are exposed over signed APIs and recorded in a transparency log, so the history of an environment's health is itself auditable.

Freshness is enforced throughout: evidence is bound to challenges so that yesterday's healthy report cannot be replayed to cover for today's compromise.

The short version​

  1. Your unmodified container runs inside hardware-encrypted memory.
  2. The hardware signs proof of what is running; the proof is welded to the TLS connection.
  3. Clients check the math against the chip maker's published keys before trusting anything.
  4. Data is encrypted in transit, in use, and at rest, with keys gated on attestation.
  5. Verification never stops, and a failing environment loses its keys.

For how these responsibilities are split across components, continue to Architecture.