Skip to content

CanaryBit Tower

Orchestrate Trusted Execution Environments (TEE)

CanaryBit Tower is a Confidential Computing resources orchestration service. It helps end-users to deploy secure processing environments and provides control over configuration drifts.

It creates all the required infrastructure resources and one or more TEE (see Confidential Computing). Tower orchestrates TEEs either on the resources of a Cloud Service Provider of your choice, or On-Prem. It destroys all the resources once the execution is completed or compromised. Each TEE is single-use and immutable once created.

CanaryBit Tower consists of multiple Terraform / OpenTofu module configurations. The Tower module is a collection of resources to provision Confidential VMs resources only.

What is a module?

To learn more about the module concepts and how to use it refer to the official Terraform or OpenTofu documentation.

Requirements

Download

Below a list of configuration for both Public Clouds and Bare-metal / Private setups supported by CanaryBit Tower.

Public Clouds

The below configurations are free to use under the Apache-2.0 licence.

Bare-metal / Private setups

A Premium License is required for the following configurations: Buy Premium

  • VMware

    Infrastructure as Code (IaC) configuration for VMware Confidential VMs

  • Proxmox

    Infrastructure as Code (IaC) configuration for Proxmox Confidential VMs

  • Openshift

    Infrastructure as Code (IaC) configuration for Openshift Confidential VMs/Nodes

  • Libvirt/QEMU

    Infrastructure as Code (IaC) configuration for Baremetal Confidential VMs

Configure

Edit the CanaryBit Tower module configuration.

Note

Always refer to the provided example files for up-to-date, supported configuration.

Example: AWS

... 

// ========================
//  Confidential VM (CVM)
// ========================

module "confidential-vm" {

    //  ************** DO NOT REMOVE THESE LINES ****************** // 

    source = "canarybit/tower/canarybit//modules/aws"       
    cb_username = var.cb_username
    cb_password = var.cb_password

    //  ************** CUSTOM CONFIG BELOW THIS LINE ************** // 

    // Confidential VM
    count = 2
    cvm_name = "my-cvm-${count.index}"
    ...
}

...

For more information about the expected arguments, please refer to each module Inputs tab (e.g. AWS: Inputs)

Remote Attestation

To enable Remote Attestation, simply add the remote_attestation code-block in the module providing the required variables.

In this scenario, CanaryBit Tower will use a specific cloud-init file (attested.yml) ensuring the security characteristics of each Confidential VM are verified at booting time or at a custom cadence.

Never trust, always verify!

Environment verification with CanaryBit Inspector service is recommended to certify the security capabilities of the execution environments, mitigate risks and ensure privacy.

Whenever a Confidential VM is created and not attested, the end-user is still trusting the hypervisor and infrastructure provider. In this scenario, the need of Confidential VMs becomes worthless.

You are at risk!

The security characteristics of this environment are NOT VERIFIED!
In this scenario, you are still trusting the hypervisor/infrastructure provider.

Add custom policies

It's possible to add a custom policies (e.g. mypolicy.rego) at different levels in the technology stack (hardware, hypervisor, OS and more). Custom policies will be enforced on top of the verifier defaults policies, and together assess both the security level and correctness of each TEE.

To create a custom policy, simply create a file with a custom Rego policy expression.

Example

A custom policy to enforce a specific OS kernel version, hypervisor, and region for the deployed TEE.

mypolicy.rego
package mypolicy

default allow := false

allow if {
  input.claims.attestations.canarybit.kernel_version == "6.17.0-14-generic"
  input.claims.metadata.hypervisor.cpuid_hypervisor == "HyperV"
  input.claims.metadata.instance.region = "northeurope"
}

Deploy & Attest

Automatically deploy Confidential VMs (cVM) applying your configuration for the selected target infrastructure.

Source your credentials

To deploy the configuration on the selected target infrastructure you first need to source both CanaryBit and the target infrastructure required credentials.

  1. Source your CanaryBit credentials:

    cb.rc
    export CB_USERNAME=***
export CB_PASSWORD=***

    Tip

    The Terraform/OpenTofu module expects your CanaryBit username (cb_username) and password (cb_password) as input. We recommend to use Terraform environment variables (TF_VAR_*):

    $ export TF_VAR_cb_username=$CB_USERNAME; export TF_VAR_cb_password=$CB_PASSWORD

  2. Source your target infrastructure credentials (e.g. AWS)

    aws.rc
    export AWS_ACCESS_KEY_ID=***
export AWS_SECRET_ACCESS_KEY=***
export AWS_REGION=***

Info

CanaryBit Tower configuration will automatically authenticate towards both CanaryBit and the target infrastructure Identity Providers (IdP) during the provisioning (apply) step.

Apply

In your terminal, apply the configuration via:

Terraform
terraform init
terraform apply
or

OpenTofu
tofu init
tofu apply

During the deployment CanaryBit Tower:

  1. authenticates the user towards CanaryBit;
  2. authenticates the user towards your infrastructure provider;
  3. creates the Confidential VMs and required virtual resources, e.g. networks, security groups, etc...;
  4. injects the cloud-init(with or without Remote Attestation enabled) in each deployed Confidential VMs;
  5. returns the details of the provisioned resources.

Download the report

The final report and additional insights are available for download on the CanaryBit Inspector Dashboard.