Prerequisites

Prev Next

1.0 Introduction

This article describes the prerequisites for installing and deploying Fortanix Confidential Computing Manager (CCM) in a customer-managed Azure Kubernetes environment (cloud-hosted).

2.0 Prerequisites

The following prerequisites must be completed before deploying Fortanix CCM.

NOTE

These components are not installed as part of the Fortanix CCM on-premises deployment and must be provisioned by the customer.

2.1 Kubernetes Cluster Requirements

  • Ensure that a Kubernetes cluster (for example, Azure Kubernetes Service (AKS)) is provisioned and accessible.

  • A production-grade Kubernetes cluster should be configured with separate node pools:

    • System node pool: Used for core Kubernetes components and general workloads. This pool can use non-SGX VM instances and should have a minimum of three nodes for high availability.

    • User node pool (SGX-enabled): Used for running Fortanix CCM workloads that require SGX. This pool must use SGX-capable VM instances, with SGX enabled according to the cloud provider configuration (for example, enabling the SGX add-on in AKS).

  • The node pools should be running Linux. Fortanix has validated this deployment on Ubuntu 24.x version.

  • Kubernetes version: 1.34 or later (or supported non-end-of-life version).

INITIAL AKS VERSION

SUPPORTED UPGRADE VERSIONS

1.34.1

1.34.x (minor updates), 1.35.0

1.34.2

1.34.x (minor updates), 1.35.0

1.34.3

1.34.x (minor updates), 1.35.0

  • The cluster must have a minimum of three nodes for user pool.

  • Ensure that the KUBECONFIG environment variable is set in the environment used to run Helm commands for installing the Fortanix Armor Kubernetes Operator.

    For example:

    export KUBECONFIG=<path-to-kubeconfig>

    Where, <path-to-kubeconfig> is the file path to your Kubernetes configuration file. For example: $HOME/.kube/config.

2.2 Node Requirements

  • Configure SGX Support on the Kubernetes cluster:

    • The Kubernetes cluster must include node pools with SGX-capable VM instances to run Fortanix CCM workloads.

    • Intel SGX must be enabled and functional on these nodes.

    • The Intel SGX Device Plugin must be installed in the cluster and expose the following resources:

      • sgx.intel.com/enclave

      • sgx.intel.com/provision

      NOTE

      For Azure AKS, SGX support requires enabling the SGX add-on when creating the cluster. For detailed steps, to refer to Microsoft official documentation.

Figure 1: SGX plugin running

  • The Kubernetes cluster must not have K8ssandra installed.

  • The Kubernetes cluster must have an Ingress Controller installed. For steps to install the Ingress Controller, refer to Installation Guide - On-premises.

  • The Kubernetes cluster must have cert-manager installed. For steps to install cert-manager, refer to Installation Guide - On-premises.

  • You must have Helm installed and access configured to deploy resources to the cluster.

  • Certificates - External or Internal Certificate Authority (CA) to sign Fortanix CCM UI and API certificates.

  • Customer-managed Cassandra deployments are not supported.

2.3 Image Registry Access

  • Fortanix CCM container images are hosted in a Fortanix-managed container registry. Customers must have access credentials to pull the required images during deployment.

  • The customer must create a Support Ticket with Fortanix to access the Fortanix OCI registry.

    For more information on the Fortanix registry configuration, refer to Deploy Fortanix Armor Kubernetes Operator.

  • An image pull secret must be created in each namespace used by Fortanix CCM to allow access to the registry.

  • The customer is responsible for maintaining and periodically refreshing the image pull secrets to ensure continued access to the registry.

2.4 Networking and Load Balancing Requirements

Fortanix CCM requires minimal external network exposure and standard Kubernetes-based load balancing. For detailed traffic flow, refer to the Fortanix CCM Architecture Diagram (on-premises).

Protocol

Inbound/ Outbound

Port Number

Load Balancer Use (Yes/No)

Purpose

TCP

Inbound

443

HTTPS- Used for static content.

TCP

Inbound

443

HTTPS- Used for Web UI and API access.

TCP

Outbound

443

Internet – Azure Attestation service.

TCP

Outbound

443

Internet - https://github.com/cert-manager to install cert-manager.

TCP

Outbound

443

Internet – Oracle OCI registry (oci://cr.download.fortanix.com/) to pull the Fortanix Armor Kubernetes Operator

TCP

Outbound

443

Azure’s Provisioning Certificate Caching Service (PCCS) endpoint  https://global.acccache.azure.net

TCP

Outbound

443

Internet – Pull nginx ingress oci://ghcr.io/nginx/

TCP

Outbound

443

Azure blob storage for CCM platform backup

TCP

Outbound (Optional)

514

If external Syslog is configured for audit logging

2.5 Operator Scope and Namespace Recommendation

  • Only one instance of the Fortanix Armor Kubernetes Operator can be deployed per Kubernetes cluster.

  • The operator is installed in a specific namespace (for example, armor), but operates with cluster-wide scope, allowing it to potentially manage Fortanix CCM resources across multiple namespaces.

  • As part of the deployment, a supporting K8ssandra operator (used to manage Cassandra) is also deployed with cluster-wide scope.

3.0 Where to go from here

For steps to deploy Fortanix CCM in a customer-managed Kubernetes environment (on-premises or cloud-hosted), click here.

Fortanix-logo

4.6

star-ratings

As of August 2025