Launch OPAQUE from Azure Marketplace¶

This guide walks you through deploying OPAQUE using a private Azure Marketplace offering. You’ll configure your environment, complete a Marketplace form, and verify that everything deployed correctly. This process ensures your data and compute remain in your control while OPAQUE manages the control plane.

Overview¶

OPAQUE’s Azure Marketplace offering lets you deploy a managed application using a hybrid architecture: OPAQUE hosts and maintains the control plane, while your team retains full control over the client and data plane components.

This deployment requires a private plan tied to your subscription, along with pre-provided credentials and configuration values for automation and secure integration.

As part of your setup, you’ll choose your preferred configuration options—including deployment model (standard AKS or workload-attested O-TCB), network access (private or public), and how DNS and TLS certificates are managed.

Before you begin¶

Make sure you have all of the following information before launching your Azure-based OPAQUE deployment:

• Administrative requirements
  • A signed licensing agreement with OPAQUE.
  • A customer identifier (provided by OPAQUE).
  • An Entra P2 Azure license, required to: enable Just-in-Time (JIT) access during secure OPAQUE platform upgrades.
• Azure environment setup (for creating a private Marketplace offer tailored to your environment)
  • Service principal ID and secret (provided by OPAQUE): Enables the Managed Application to fetch customer-specific configuration from an Azure Key Vault.
  • User-assigned managed identity configuration (created by you): Required for deployment.
    • Must have Contributor, Storage Blob Data Contributor, and User Access Administrator roles in the subscription where OPAQUE will be deployed.
    • If deploying in a hub-and-spoke model with private components, also assign Network Contributor access to the hub VNet.
    • For setup guidance, see Manage user-assigned managed identities.
• Deployment parameters (defined by you and used during launch)
  • Terraform VM password: The admin password for the virtual machine that runs deployment automation.
  • OPAQUE application subdomain (e.g., yourdomain.opaque.com). This domain will host the UI and back-end services.
  • Hub VNet Peering Service Principal (private deployments only): If you choose a private AKS deployment, OPAQUE must peer the managed application (the spoke) to your existing hub VNet, which provides Internet access for AKS bootstrapping and for fetching OPAQUE container images. To enable this, you must pre-create an Azure service principal with Network Contributor access to the hub VNet. During deployment, you will provide its client ID, object ID, and client secret so the managed application can establish the required peering.
• Third-party credentials (required for automating DNS and certificate provisioning). Depending on your DNS and certificates management preferences, you'll need:
  • Cloudflare API token: Used to automate DNS record creation.
  • ZeroSSL credentials: Includes an HMAC key, key ID, and email for automated TLS certificate provisioning.
  • Hugging Face access token: Required if you plan to launch LLM workloads on confidential GPUs.
    • The Hugging Face account associated with the token must have access to the selected models (for example, Llama 32. 3B or Llama 3.2 8B).
    • You can request access to each model directly from its Hugging Face page (e.g., Llama 3.2 3B Instruct) and create a token at huggingface.co/settings/tokens).
  • TLS certificate and private key files: Required only if you choose to manage TLS manually.

• Environment network settings (required to set virtual network ranges, subnets, and service IPs for the Terraform runner, client resources, and data plane). The network layout depends on your selected deployment type:

  • AKS-based data plane: A single virtual network (VNet) is used for all components, with separate subnets for the Terraform runner, client, and data plane.
  • OPAQUE trusted computing base (O-TCB): Two VNets are used—one shared by the Terraform runner and client, and another dedicated to the data plane. Each has its own subnet within its respective VNet.

  You'll need to specify: CIDR ranges for each VNet and subnet, as well as cluster service CIDRs and DNS service IPs for both client and data plane clusters.

• Azure subscription requirements

  • Compute Quota for the VM families required by your deployment configuration:

    • 20 vCPUs in the Standard_E2_v5 family (Terraform runner and client plan components).
    • Sufficient vCPUs in the data-plane node family you select during deployment (for example, 20 vCPUs in the Standard_DCasv5 family).

    Need more vCPUs in either VM family?

    Request a quota increase from the Azure portal.

  • If you’re deploying a workload-attested O-TCB configuration with with confidential GPUs, ensure you have quota in the Standard_NCC40ads2023 Family vCPUs (H100) in East US 2.

  • Required resource providers:

    • Microsoft.Storage
    • Microsoft.Compute

    See Register resource providers for details.

Step 1. Verify the managed identity setup¶

To complete the following steps, the managed identity used for deployment must have Contributor and User Access Admin roles on the target Azure subscription.

In the Azure portal, navigate to the subscription’s Access control (IAM) blade, select the user-assigned managed identity, and confirm the required role assignments under Azure role assignments.

If you intend to enable user-defined routing (UDR) for AKS egress during deployment, the same managed identity must also have Network Contributor access on the subscription (or resource group) containing your hub VNet.

Step 2. Accept confidential O-TCB image (optional)¶

If your deployment uses a workload-attested OPAQUE Trusted Computing Base (O-TCB) configuration, you must first accept the confidential GPU image shared with your organization through Azure Marketplace.

This step allows your subscription to use the GPU-enabled confidential image required for O-TCB deployments. If you skip it, deployment will fail when the template attempts to pull the image.

To accept the image:

1. Check your email or Azure Portal for an invite from OPAQUE Systems to access the shared image.
2. Open the shared image listing in Azure Marketplace.
3. Select Accept Terms to authorize its use in your subscription.
4. Once accepted, return here and continue with Step 3: Deploy OPAQUE.

Step 3. Deploy OPAQUE¶

This step guides you through launching OPAQUE’s private Marketplace application and configuring key infrastructure, DNS, and certificate settings.

1. Open the private Azure Marketplace listing URL provided by OPAQUE.

2. On the Basics tab, fill in the form inputs using the values from your “Before you begin” checklist, including customer identifier, service principal ID and secret, and managed application details.

   

   These values enable the deployment process to authenticate securely and retrieve configuration values from your Azure Key Vault.

3. On the Application Configuration tab, specify the application subdomain name you want to use for your OPAQUE deployment (e.g., customer.opaque.com).

   This subdomain must be owned by your organization and will serve as the single access point for users and services. Whether you're using automated or manual DNS, this value defines the endpoint for your deployment.

   

   Optionally, you can also enable OpenTelemetry (OTLP). This allows OPAQUE to export metrics to any OTLP-compatible collector.

   Important

   If you plan to use telemetry, you must enable OTLP at deployment time—it cannot be turned on later without redeploying. The destination endpoint can be configured afterward.

   Requirements for your OTLP receiver:

   • Must accept metrics over a gRPC stream.
   • Must present a valid TLS certificate signed by a trusted authority.
   • Must use bearer token authentication.

   HTTP-based export may be supported in a future release, but gRPC is currently required for performance and reliability.

4. On the Infrastructure Configuration tab, you define how your deployment handles cluster access, workload attestation, scaling, and GPU support for LLM workloads. These settings determine how your OPAQUE environment operates at runtime.

   General settingsWhen using workload attestation . . .

   You can choose to:

   • Select the node size for data plane AKS cluster, which opens a side drawer where you can select from available Standard DCas v5 confidential compute VM sizes, including approximate associated costs.
   • Enable autoscaler for data plane AKS cluster, which allows the data plane cluster to scale automatically based on workload demand. When enabled, you must also specify the maximum number of nodes.
   • Set advanced compute config options for data plane AKS cluster. When selected, you’ll see four sliders for CPU and memory request/limit settings. Use these controls only if you require fine-grained tuning for confidential workloads.

   

   When you use workload-attested data plane (preview), all data plane workloads run in a verified, attested environment to ensure that only trusted code can access sensitive data. This configuration provides the highest level of runtime assurance within the OPAQUE trusted computing base (O-TCB).

   Note

   When using this option, you won’t be able to enable autoscaling, which currently is not supported for workload-attested deployments.

   When using workload attestation, you can choose to:

   • Enable confidential GPU for LLM workloads (NVIDIA H100 94GB) to accelerate model inference in a trusted execution environment.

   • Select LLM models to deploy. These options become available only after enabling a confidential GPU. You can deploy a mix of up to three of the following models (four listed, but total selection is limited by GPU memory):

     • Llama 2 7B Chat (Quantized – ≈ 12 GB GPU memory)
     • Llama 2 13B Chat (≈ 34 GB GPU memory)
     • Llama 3.2 1B Instruct (≈ 16 GB GPU memory)
     • Llama 3.2 3B Instruct (≈ 46 GB GPU memory)

   Note

   Due to GPU memory constraints, launching all four models simultaneously is not supported. Selecting larger or more complex LLMs may increase compute requirements and runtime, which can raise overall compute usage but does not affect the per-node cost.

   • Provide your Hugging Face access token for authenticated model retrieval. (Ensure your Hugging Face account has been granted access to any Llama models you plan to deploy; access requests are managed on each model's page in Hugging Face.)
   • Enter the OPAQUE gallery app object ID (provided by OPAQUE). This value is used to validate access to the confidential O-TCB image required for workload attestation.

   

   These options let you tailor how the OPAQUE control plane integrates with your security, scaling, and AI/LLM runtime environments.

5. On the Network Configuration tab, define the address ranges and service IPs for all the networks used by your OPAQUE deployment.

   You’ll begin by choosing a deployment connectivity mode, Public or Private, which determines how traffic flows between your environment, the AKS clusters, and Azure services.

   Note

   If you selected Workload-attested data plane on the previous tab, an additional field—Data plane VNet CIDR—appears under Data plane network. This field defines the separate virtual network used to isolate attested workloads in O-TCB deployments.

   Public modePrivate mode

   In this mode, OPAQUE uses standard public connectivity for cluster management and service access. This is the default configuration when deploying through Azure Marketplace.

   • The AKS control plane uses a public endpoint, secured by Azure-managed network controls.
   • OPAQUE’s client and data plane services expose their endpoints through public load balancers, secured with TLS.
   • No VNet peering or routing configuration is required.
   • All you need to specify are the standard CIDR ranges for the Terraform runner VM, client cluster, and data plane cluster.

   This mode is typically chosen for:

   • Simpler deployments
   • Environments without existing hub-and-spoke networking
   • Teams not requiring private control-plane access

   

   The following table shows the default default address ranges and service IPs for the networks OPAQUE will use. You may keep these values or update them to match your internal IP planning.

   Setting	Description	Default
   VNet CIDR	Virtual network address space for Terraform runner VM	10.24.0.0/14
   Terraform runner subnet CIDR	Subnet range within VNet for Terraform runner VM	10.27.0.0/24
   Client subnet CIDR	Subnet range within the client VNet	10.24.0.0/22
   Client cluster service CIDR	Service address range for the client Kubernetes cluster	192.24.0.0/22
   Client cluster DNS service IP	DNS service IP for the client Kubernetes cluster	192.24.1.10
   Data plane subnet CIDR	Subnet range within the data plane VNet	10.25.0.0/22
   Data plane cluster service CIDR	Service address range for the data plane Kubernetes cluster	192.25.0.0/22
   Data plane cluster DNS service IP	DNS service IP for the data plane Kubernetes cluster	192.25.1.10

   In this mode, OPAQUE is deployed into a private hub-and-spoke network. The client and data plane stay on private IP space, and outbound access (for example, during AKS bootstrap and image pulls) is routed through your existing hub network.

   When you select Private, you’ll provide the following hub and peering details:

   • Hub VNet resource ID: The full Azure resource ID of the hub virtual network you want to peer with the OPAQUE spoke VNet.
   • Hub firewall private IP: The private IP address of your hub firewall (or egress appliance) that will handle outbound traffic.
   • Peering service principal ID, object ID, and secret: Credentials for a pre-created service principal that has Network Contributor permissions on the hub VNet. OPAQUE uses this identity to create and configure VNet peering automatically during deployment.

   Use Private mode when your organization:

   • Requires private network boundaries for cluster and service connectivity
   • Uses a hub firewall or centralized egress for outbound routing
   • Needs to integrate OPAQUE into an existing hub-and-spoke Azure network design

   

   After you enter the required hub and peering values, the rest of the tab works the same way as Public mode: you can keep the default CIDRs and service IPs, or adjust them to match your address plan.

6. On the Security & Certificates tab, choose how you want to manage DNS records and TLS certificates for your domains. You can automate DNS and certificate management using Cloudflare and ZeroSSL or manage everything manually.

   Automate certificate managementBring your own certificate

   Automated certificate management lets OPAQUE handle DNS and TLS setup for you. Simply provide your Cloudflare and ZeroSSL credentials, and the system will create DNS records and generate certificates during deployment.

   

   Select Use custom TLS certificate to manage both DNS and certificates yourself. You'll be asked to upload two TLS files:

   • TLS certificate file (e.g., "codeops.crt")
   • TLS private key file (e.g., "codeops.key")

   After upload, update your DNS to point to the deployment’s public IP.

   Certificate requirement

   Your TLS certificate must:

   • Be a wildcard certificate (e.g., *.example.com) so that it secures both your OPAQUE application subdomain and its associated API subdomain.
   • Include the full certificate chain, with the server certificate followed by all required intermediate certificates, to ensure client trust validation.

   

   Info

   Certificates are securely applied to OPAQUE-managed endpoints. You retain full control of domain and certificate management. Uploaded certificates are validated for correct format, key match, and resolvable domain fields before deployment continues.

7. On the JIT Configuration tab, enable JIT access so time-limited access can be granted for secure platform upgrades when needed. Then select Customize JIT configuration to review and set the approval mode and activation duration.

   

   For most deployments, we recommend: - Approval mode: Automatic - Activation maximum duration: 8 hours

   

   These settings provide time-limited access for upgrade operations without requiring manual approval each time.

8. On the Review + Submit tab, review your configuration and confirm the required terms.

   First, under Co-Admin Access Permission, select I agree to the terms and conditions above. This is required to create the managed application.

   

   Next, verify your entries, then click Create.

   

   After submission, you’ll be redirected to the Deployment page. On the Managed Application page, look for the message “Deployment is in progress.” Provisioning typically completes within one hour.

Step 4. Verify your deployment¶

Once you submit the deployment form, Azure begins provisioning your OPAQUE environment. The steps for verifying deployment differ slightly depending on how you configured TLS.

Step 5. Post-deployment tasks¶

After a successful deployment, you’ll need to confirm that your OPAQUE environment is accessible and notify your OPAQUE contact so they can finalize setup on their side.

• Access the OPAQUE front end.

  Visit the OPAQUE application subdomain you specified on the Application Confirguration tab during deployment. You should see the OPAQUE login page.

  

• Notify OPAQUE that deployment is complete.

  Once you’ve verified access, let your OPAQUE contact know that deployment has finished. They will perform the final configuration and validation steps required to activate your environment.

• (If applicable) Provide private details to OPAQUE.

  If your deployment includes private blob storage—for example, when the Private cluster for AKS option is selected during deployment—share the following information for each storage account with your OPAQUE contact to enable secure private connectivity:

  • Storage Account ID: The full Azure Resource Manager (ARM) path to the storage account. Example:

  /subscriptions/<subscription_id>/resourceGroups/<resource_group>/providers/Microsoft.Storage/storageAccounts/<storage_account_name>
  

  • Storage Account Name: The unique storage account name in Azure.

  Example: amareleasemrgsolaras5a43

  • Tenant ID: The Azure Active Directory (AAD) tenant ID under which the storage account exists.

  Example: e4ab718c-3334-4f94-ba08-09c69c746e0a

  Once you’ve provided these details, an OPAQUE engineer will complete the final automation steps to create the required private endpoints and verify secure connectivity between your deployment and OPAQUE’s services. After this, you’ll need to approve the private connection from your Azure portal—but only for the analytics storage account, which is automatically created as part of your deployment.

When your environment is fully operational, you can enable Okta SSO for OPAQUE to provide secure single sign-on (SSO) access for your users.