Deployed resources¶
This document outlines the resources provisioned in your Azure subscription when you deploy OPAQUE through the Azure Marketplace offering. It provides a high-level overview of the deployment process, the resources created, and how they integrate with OPAQUE’s control plane.
Deployment overview¶
When you initiate deployment from Azure Marketplace, a provisioning virtual machine is created to automate setup. The VM first retrieves deployment-specific secrets from OPAQUE’s key vault to access OPAQUE’s private artifact registry, and then pulls the necessary deployment artifacts—including Terraform modules, Helm charts, and related templates—to orchestrate the creation of all required infrastructure and application components. These components support secure, scalable agentic AI and analytics workflows.
To support runtime operations and state persistence, the deployment also provisions two Azure Blob Storage resources, one for agentic AI and one for analytics workflows. Each is configured for private access through your virtual network.
Depending on your preference, OPAQUE can be deployed in one of two configurations:
- Standard AKS deployment, which uses Azure Kubernetes Service (AKS) clusters with confidential compute capabilities.
- Workload-attested OPAQUE trusted computing base (O-TCB), which runs all sensitive workloads within a hardware-attested environment for verifiable runtime assurance.
In both cases, core compute resources are deployed inside the trusted boundary of your Azure subscription.
The following diagrams provide an overview of the two configurations. Each configuration includes a client plane, a data plane, and secure integration with OPAQUE's control plane.
In this configuration, OPAQUE deploys two managed AKS clusters within your Azure subscription:
- A client cluster, which hosts the user-facing interface, REST API, and encryption/decryption services.
- A data plane cluster, which executes agentic AI and analytics workflows in a confidential compute environment.
Both clusters run on AMD SEV-SNP–enabled node pools, ensuring memory encryption and hardware-backed runtime integrity.
Networking, secrets management, and certificate configuration are automated through Terraform and Helm.
All traffic is secured through OPAQUE's attested TLS (aTLS) mesh, which verifies the identity and integrity of every service before communication is established.
Info
By default, OPAQUE deploys AKS using public clusters, where the Kubernetes API server (control plane) is reachable over the internet using Azure-managed endpoints secured with TLS. If you select private AKS during deployment, the API server is accessible only from within your virtual network, adding an extra layer of isolation. Regardless of this choice, the client and data plane clusters always communicate securely over paired VNets through OPAQUE's aTLS mesh.
This configuration supports autoscaling (if set during deployment) and is typically chosen for workloads with dynamic compute requirements.
This configuration provisions an attested compute environment designed for maximum runtime assurance.
- The client cluster runs on AMD SEV-SNP–enabled nodes, hosting the user interface, REST API, and encryption/decryption services.
- The data plane cluster (the core of the O-TCB) on AMD SEV-SNP–enabled nodes by default, or on NVIDIA H100 confidential GPU CVMs if confidential GPU support is enabled. In either case, workloads run within a hardware-anchored, attested environment that ensures verifiable isolation and runtime integrity.
Within this trusted boundary, the workload manager and workload processor enforce confidentiality, integrity, and policy compliance at runtime. These components operate in attested environments that protect both data and workloads from unauthorized access—even from privileged cloud infrastructure.
During provisioning, the deployment VM retrieves the O-TCB base image from OPAQUE’s image gallery hosted within OPAQUE’s control plane and shared with your organization using Azure RBAC. This gallery contains the confidential GPU images required for workload-attested deployments.
Supporting Azure services—such as Blob Storage and key vault—remain outside the O-TCB but communicate through encrypted, policy-enforced interfaces. The Opaque Attestation Service (OAS), shown in the diagram, performs runtime attestation over Private Link.
Unlike the AKS model, O-TCB deployments do not support autoscaling, since each GPU node operates within an attested enclave boundary configured at deployment time. Users configure these settings directly in the Azure Marketplace interface before launch.
DNS zones and private connectivity¶
During deployment, OPAQUE automatically provisions private DNS zones that handle secure name resolution and routing between customer-hosted and OPAQUE-managed components.
The following zones ensure all communication remains within private, attested network boundaries.
| DNS Zone | Purpose |
|---|---|
controlplane.opaque-int.com |
Hosts endpoints for coordination, attestation, and key management services (mp, notifications, audit-logger, vault-client, vault-dataplane). |
servicebus.windows.net |
Resolves Azure Service Bus endpoints used for secure message transport and signaling across both agentic AI and analytics workflows. |
privatelink.blob.core.windows.net |
Provides private connectivity to Azure Blob Storage resources used for agentic AI and analytics workloads. |
privatelink.dfs.core.windows.net |
Enables private data-plane access to the same Blob Storage resources for distributed file operations. |
All zones are provisioned and linked automatically during deployment. No manual configuration is required, but they can be useful reference points when validating private connectivity or diagnosing DNS resolution issues.
aTLS mesh¶
To protect all data throughout its lifecycle, OPAQUE uses an attested TLS (aTLS) service mesh to secure communication between all deployed components. This mesh ensures that no service communicates with another unless both parties have cryptographically verified each other's identity and runtime integrity through remote attestation. This mechanism, know as mutual aTLS (maTLS), enforces:
- Strong cryptographic verification before any connection is established, including validation of each service's attestation evidence—covering the hardware root of trust (e.g., AMD SEV-SNP, TPM, or NVIDIA NRAS), firmware, kernel, and measured workload image—against trusted baselines maintained by OAS.
- End-to-end encryption for all traffic between services.
- Hardware-rooted trust boundaries at the network layer.
All necessary components to enforce this mesh—such as proxies, policy engines, and certificate managers—are automatically injected into workloads that handle confidential data. These protections are applied transparently and do not require user configuration. (A more detailed overview of the aTLS mesh design is available upon request.)
Control plane integration¶
OPAQUE’s control plane, hosted in a separate Azure subscription, integrates securely via:
- Azure Service Bus, which transports job coordination signals and heartbeats.
- Private Link, which establishes a secure, private connection between your deployment and Opaque’s control plane over Azure’s internal network.
Summary¶
Deploying OPAQUE through Azure Marketplace sets up a full confidential AI stack. All components are provisioned and connected using automated infrastructure-as-code workflows triggered by a purpose-built VM.
Both deployment options deliver the same core Opaque functionality. The Private AKS configuration provides a confidential compute environment suitable for most enterprise workloads, while the O-TCB configuration extends those protections with hardware-based workload attestation for environments requiring stronger cryptographic proof of runtime trust.