Skip to main content

Deploying Polaris

A Polaris deployment runs in your own cloud account. It has three moving parts:

  • A confidential VM running the Secure Proxy, your unmodified workload, and the Sentinel agent.
  • A separate VM running the Policy Manager, kept outside the workload's trust domain.
  • A key in the cloud's own key-management service, whose release is gated on attestation.

You provision all of this with standard infrastructure-as-code, from a single deployment config. Your application does not change: it listens on plain HTTP inside the boundary, and Polaris handles TLS, attestation, encryption, and enforcement around it. See Preparing Your Workload for what the container needs to look like.

This page covers the choices that are the same on every cloud. Each cloud then has its own page for the specifics:

The choices you make​

Every deployment config comes down to a handful of decisions. The rest of this page explains them; the cloud pages tell you which values each provider accepts.

Cloud and region​

Pick the provider and the region you want to run in. The region has to offer confidential-computing hardware for the TEE you choose, which is why the choice of cloud and the choice of TEE are linked. The Supported Platforms matrix shows which hardware each cloud offers.

TEE hardware​

The TEE is the hardware that encrypts memory and signs the attestation report. Your options depend on the cloud:

  • AMD SEV-SNP. Full confidential-VM protection on AMD EPYC, with a hardware-signed report you can verify against AMD's published keys.
  • Intel TDX. Intel's confidential-VM technology, verifiable against Intel's published root of trust.
  • NVIDIA confidential GPU. On H100-class GPUs, memory is encrypted and the GPU produces its own attestation. CPU and GPU evidence are bound together, so the deployment is only healthy when both attest.

Attestation depth​

You choose how much Polaris verifies. Deeper modes add layers on top of, not instead of, the ones below:

  • Hardware. Proves the workload runs inside a genuine TEE, and nothing more. A single confidential VM, no Policy Manager. Use it when you only need to prove the environment.
  • Workload. Adds the Policy Manager and image-integrity checking, so the exact container you deployed is the one running, signatures and all.
  • Full. Adds runtime and kernel monitoring through the Sentinel agent: process, network, and file-access behavior, plus kernel integrity. This is the mode that catches an environment that booted clean and was compromised while running.

The layers behind these modes are described in Attestation & Trust Model. A fresh full-mode deployment starts in an advisory state and settles once the runtime baseline has learned a healthy, quiet workload. That is expected, not a fault.

Verification path​

Depending on the platform, clients verify attestation one of two ways:

  • Cloud-attested. The cloud provider's confidential-computing service vouches for the VM, and the client checks the provider's signed statement. Fine when the provider is already in your trust model.
  • Direct hardware attestation. The client checks the raw hardware report against AMD's, Intel's, or NVIDIA's published keys, with no cloud service and no Fr0ntierX service in the path. This is the strongest model and the recommended one where the platform supports it.

Which paths are available is a property of the cloud and TEE. The cloud pages say which apply.

Key management​

The Policy Manager gates access to a key in the cloud's own key service: Google Cloud KMS, AWS KMS, Azure Key Vault, or OCI Vault. The key stays in your account and your control. Polaris governs access to it based on the continuously verified health of the environment, and revokes that access the moment appraisal fails.

Sizing​

You set the machine type for the workload VM and for the Policy Manager VM, and how many workload VMs to run. Larger workloads need larger confidential-VM shapes; the Policy Manager is light and runs on a small VM. Each cloud page lists the machine families that carry the right confidential-computing support.

Attestation cadence​

Optionally, you tune how often the workload reports fresh evidence, how long a key grant lasts, and how quickly the Policy Manager pulls access from a VM that goes silent (the dead man's switch). The defaults suit most deployments. Shorten them for a tighter reaction time, at the cost of more frequent verification traffic.

Ways to deploy​

There are two ways to stand up a deployment, both producing the same result:

  • Command line. Point the deploy script at a config file. This is the most flexible path and the one the examples use.
  • Cloud marketplace. On the clouds where Polaris is listed, deploy straight from the provider's marketplace and fill in the options through a form. The marketplace image ships with the Polaris components baked in.

Continue to the page for your cloud:

Once it is up, confirm it with Verifying a Deployment.