This guide walks through the fully automated deployment of the Cloudmersive Private Cloud Virus Scan API on Azure Kubernetes Service (AKS) with the Cloudmersive deployment pack. You provide a few settings, and a single automated deployment does the rest: it creates the Azure infrastructure, installs the Virus Scan API, and exposes it over HTTPS on a hostname you choose. You do not need to build the cluster or install anything into it by hand. The only manual step afterwards is a DNS record for your hostname.

There are two ways to run the deployment. Both create the same resources and produce the same result.

• Deploy to Azure opens a guided wizard in the Azure portal. You fill in a few pages, select your certificate file, and click Create. Nothing needs to be installed on your computer.
• Bicep uses the same template from the command line. Choose this if you manage your Azure infrastructure as code, want to review or change the template, or want to run the deployment from a pipeline.

The deployment takes about 30 minutes. Most of that time is spent by the Windows nodes downloading the Virus Scan API container image for the first time.

What the deployment creates

All resources are created in one resource group that you choose.

• Virtual network. The network holds the cluster nodes and the gateway. It gets two subnets, or four when private endpoints are enabled.
• AKS cluster. The cluster has a Linux node pool for Kubernetes system components and a Windows Server 2022 node pool that runs the Virus Scan API.
• Application Gateway for Containers. The gateway is the public HTTPS entry point. It presents your TLS certificate and forwards requests to the Virus Scan API inside the network. Nothing in the cluster has its own public IP address.
• Key Vault. The vault stores your TLS certificate, the Windows node administrator password and your Cloudmersive Node ID.
• Managed identities. Four managed identities handle every call between Azure services, so no passwords or service principals are created.
• Deployment script. A one-time configuration step installs the gateway controller and the Virus Scan API inside the cluster.
• Container registry (optional). When enabled, the Virus Scan API image is copied into an Azure Container Registry in your subscription and pulled from there with a managed identity.
• NAT Gateway (optional). When enabled, all outbound traffic from the cluster leaves through one stable public IP address.

With the default settings, the deployment creates two Standard_E4s_v5 Windows nodes (4 vCPUs and 32 GB of memory each) running two replicas of the Virus Scan API, and two Standard_D2s_v5 Linux nodes. The AKS cluster uses the Standard pricing tier, which includes the uptime SLA. Use the Azure pricing calculator to estimate the monthly cost for your region.

Before you start

Have the following ready:

• Your Cloudmersive Node ID. It is shown on your Virus Scan API node's page in the Cloudmersive portal, as described in Step 1. It identifies your private cloud node and is not a secret.
• A hostname and a TLS certificate. Decide which hostname your applications will call, for example scan.contoso.com, and have a TLS certificate for that name as a .pfx file with its password. If the certificate is already stored in one of your Azure Key Vaults, you can select it from there instead. For a quick test without a certificate, you can choose a self-signed certificate; browsers will then show a warning and API clients must be configured to skip certificate validation.
• Azure permissions. You need permission to create a resource group and role assignments in the subscription. The Owner role works, as does Contributor together with User Access Administrator.
• Azure quota. With the defaults, the region you choose needs quota for 8 vCPUs in the Esv5 family and 4 vCPUs in the Dsv5 family. You can check and request quota on the Quotas page of the Azure portal.
• A supported region. The region must support Application Gateway for Containers and Windows Server 2022 node pools. Most major regions do.
• Outbound access. The cluster needs outbound Internet access to reach Cloudmersive's management and update services and to download the container image. If your organization restricts outbound traffic, contact Cloudmersive Support for the list of addresses to allow.

Step 1: Open the deployment options in the Cloudmersive portal

1. Sign in to the Cloudmersive portal at https://portal.cloudmersive.com.
2. Go to Private Cloud and open your Virus Scan API node.
3. Click the Azure Kubernetes Service tab.
4. Choose the deployment type in the Deployment Type list:
   • ARM - Deploy to Azure is selected by default. Continue with Path A.
   • Bicep shows the download for the Bicep pack. Continue with Path B.
   • Manual (YAML or Helm) shows the manual installation steps for an AKS cluster you build yourself. That option is not covered in this guide.

Your Cloudmersive Node ID is shown on both the Deploy to Azure and Bicep options, with a copy button. Copy it now; you will need it in the next step.

Path A: Deploy to Azure

A1. Start the wizard

Click the Deploy to Azure button. The Azure portal opens in a new tab with the deployment template and its wizard already loaded. Sign in to Azure if you are asked to.

On the first page, choose the subscription and either create a new resource group or select an empty one, and choose the region.

A2. Basics page

• Name prefix is used at the start of every resource name. The default is cmpcvs. It must be 2 to 10 characters long, use only lowercase letters and digits, and start with a letter. If you deploy more than one Cloudmersive deployment into the same resource group, give each one a different prefix.
• Cloudmersive Node ID is the value you copied in Step 1.
• Public hostname is the name your applications will call, for example scan.contoso.com. It must match the name on your TLS certificate.

A3. TLS certificate page

Choose a Certificate source:

• Upload a PFX file shows a file picker. Select your .pfx file and enter its password.
• Use a certificate in an existing Key Vault lets you pick a certificate that is already stored in one of your Key Vaults.
• Self-signed (testing only) creates a certificate for testing only. Replace it with a real certificate before production use, as described in Renewing or replacing the TLS certificate.

Leave Redirect plain HTTP (port 80) to HTTPS selected unless you have a reason to turn it off.

A4. Cluster page

The defaults on this page suit most deployments.

• Windows node pool. This pool runs the Virus Scan API. Choose the Windows node size and the number of nodes, or select Autoscale the Windows node pool and set the minimum and maximum. The size list shows only sizes available in your region. Standard_E4s_v5 is recommended. Each Windows node needs at least 16 GB of memory, so the smallest supported size is Standard_D4s_v5. Use v4 or v5 sizes for this pool; v6 sizes do not support the Windows Server 2022 node image.
• Linux system node pool. This pool runs Kubernetes components and the gateway controller. The default of two Standard_D2s_v5 nodes is sufficient.
• Grant my user cluster admin access is selected by default. It gives the account running the deployment the Azure Kubernetes Service RBAC Cluster Admin role, so you can view the cluster's workloads in the Azure portal and connect with kubectl afterwards. If you clear it, those views return an access error until someone assigns you a role.
• Advanced contains the AKS pricing tier, the Kubernetes version and the Windows node administrator account. If you leave the administrator password blank, a strong password is generated and stored in the Key Vault.

A5. Network page

The defaults create a new virtual network with the address space 10.240.0.0/16, and use 10.241.0.0/16 for Kubernetes services. Change the address ranges only if they overlap a network you plan to connect to this one, for example through peering or VPN.

This page also has the following options:

• Outbound connectivity can be changed from the AKS load balancer to a NAT Gateway if you need all outbound traffic to come from one stable public IP address.
• Private API server turns off the public Kubernetes API endpoint. You then need network access to the virtual network to use kubectl. When the API server stays public, you can limit it to your own IP ranges under API server authorized IP ranges.
• Private endpoints places the Key Vault, the container registry and the deployment's storage account behind private endpoints. Read the Private endpoints section of this guide before you turn this on.

A6. Registry and services page

• Create an Azure Container Registry is off by default, and the Virus Scan API image is pulled directly from Cloudmersive's container registry. Turn it on if your policies require images to be pulled from a registry in your own subscription.
• Key Vault name and Container registry name are generated from the name prefix when left blank.
• Image tag is the Virus Scan API release to install. It defaults to the current release at the time the deployment pack was published. The Cloudmersive portal's Azure Kubernetes Service tab shows the latest release; if it is newer, you can enter it here.
• Virus Scan API replicas defaults to 2. Each replica runs on its own Windows node, so when autoscaling is off, the number of replicas cannot be greater than the number of Windows nodes.
• The remaining settings, which are the Helm chart version, the Kubernetes namespace and the chart download URL override, should be left at their defaults unless Cloudmersive Support asks you to change them.

A7. Tags page

Add any tags your organization requires. They are applied to every resource the deployment creates.

A8. Create the deployment

Click Review + create. Azure validates your choices. When validation passes, click Create.

The deployment takes about 30 minutes. You can follow its progress on the deployment page in the Azure portal. When it shows that your deployment is complete, continue with Step 2.

Path B: Bicep

B1. Download the pack

On the Bicep option of the Azure Kubernetes Service tab, click Download Bicep pack, and unzip the file. The pack contains the template (main.bicep), a parameter file (main.bicepparam), the template's modules and a README.

B2. Edit the parameter file

Open main.bicepparam and set at least hostName to your public hostname. Review the other values, which match the defaults described in Path A. The parameters you are most likely to change are listed below.

• hostName (required). This is the hostname on your TLS certificate.
• namePrefix (default cmpcvs). This is the prefix for resource names, 2 to 10 lowercase letters or digits starting with a letter.
• tags (no default). These tags are applied to every resource.
• tlsCertificateSource (default import). Use import to upload a PFX file, existingKeyVault to use a certificate in one of your Key Vaults, or selfSigned for testing.
• windowsNodeVmSize (default Standard_E4s_v5). This is the size of the Windows nodes that run the Virus Scan API.
• windowsNodeCount (default 2). This is the number of Windows nodes. Alternatively, set windowsNodeAutoscale to true with windowsNodeMinCount and windowsNodeMaxCount.
• replicaCount (default 2). This is the number of Virus Scan API replicas. Without autoscaling, it cannot exceed windowsNodeCount.
• imageTag (default: the current release). This is the versioned Virus Scan API image, for example win2022_win_virusscanapi_11_9_3.
• deployContainerRegistry (default false). Set this to true to copy the image into your own Azure Container Registry.
• outboundType (default loadBalancer). Set this to natGateway for one stable outbound IP address.
• enablePrivateEndpoints (default false). Read the Private endpoints section before turning this on.
• enablePrivateCluster (default false). Set this to true for a private Kubernetes API server.

Secrets are not stored in the parameter file. Your Cloudmersive Node ID and the certificate are passed on the command line in the next step. Every parameter has a description in main.bicep.

B3. Run the deployment

Open Azure Cloud Shell in the Azure portal and choose Bash, or use a terminal where the Azure CLI is installed and signed in. Upload your .pfx file and the unzipped pack to the same folder, change to that folder, and run the following commands. Replace the resource group name, region, Node ID and certificate password with your own values.

az group create --name cloudmersive-vs-rg --location eastus2

az deployment group create \
  --resource-group cloudmersive-vs-rg \
  --template-file main.bicep \
  --parameters main.bicepparam \
  --parameters cloudmersiveAccessKey='<your Cloudmersive Node ID>' \
               tlsCertificatePfxBase64="$(base64 -w0 certificate.pfx)" \
               tlsCertificatePfxPassword='<pfx password>'

If you set tlsCertificateSource to existingKeyVault or selfSigned, leave out the two tlsCertificatePfx parameters. For existingKeyVault, also set existingKeyVaultResourceId and existingKeyVaultCertificateName in the parameter file.

The command returns when the deployment is complete, after about 30 minutes.

Step 2: Point your hostname at the gateway

The deployment's frontendFqdn output is the address of the Application Gateway for Containers. Create a CNAME record in your DNS zone from your public hostname to that address.

• Deploy to Azure: open the deployment in the Azure portal, select Outputs, and copy frontendFqdn.
• Bicep: run the following command.

az deployment group show \
  --resource-group cloudmersive-vs-rg \
  --name main \
  --query properties.outputs.frontendFqdn.value -o tsv

DNS changes can take a few minutes to take effect.

Step 3: Verify the installation

1. Browse to https://<your hostname>/. You should see the Cloudmersive Private Cloud logo.
2. Send a test scan to https://<your hostname>/virus/scan/file. All of the Virus Scan API's /virus/... endpoints are available on the same hostname.

The Windows nodes download the container image the first time they start, which takes 10 to 15 minutes. If the hostname does not respond straight after the deployment finishes, wait a few minutes and try again.

Managing the deployment

Connecting to the cluster

If you kept Grant my user cluster admin access selected, you can view the cluster's workloads in the Azure portal and connect with kubectl. Replace <prefix> with your name prefix.

az aks get-credentials --resource-group cloudmersive-vs-rg --name <prefix>-aks
kubectl get pods --namespace cloudmersive

The deployment's getCredentialsCommand output contains the exact az aks get-credentials command for your deployment.

To give another person access to the cluster, assign them the Azure Kubernetes Service RBAC Cluster Admin role on the cluster. Role assignments can take a few minutes to take effect.

az role assignment create \
  --role "Azure Kubernetes Service RBAC Cluster Admin" \
  --assignee <user object ID or email address> \
  --scope $(az aks show --resource-group cloudmersive-vs-rg --name <prefix>-aks --query id -o tsv)

The Virus Scan API runs in the cloudmersive namespace. The gateway is the only public entry point; the Virus Scan API service inside the cluster is not exposed directly.

Updating the Virus Scan API

Each deployment runs a specific, versioned release of the Virus Scan API. To update, run the deployment again with a newer image tag. The Cloudmersive portal's Azure Kubernetes Service tab shows the latest release tag.

• Deploy to Azure: click the Deploy to Azure button in the Cloudmersive portal again. In the wizard, select the same subscription and resource group, enter the same name prefix and the same settings as before, and set Image tag on the Registry and services page to the newer tag. Azure does not keep certificate files or passwords from the earlier deployment, so select your PFX file and enter its password again.
• Bicep: run the same az deployment group create command with the additional parameter imageTag=<newer tag>.

Because the resource group and name prefix are the same, the deployment updates the existing resources instead of creating new ones, and the Virus Scan API is moved to the new release.

Scaling

To change the number of Windows nodes or replicas, run the deployment again with new values for the node count, autoscale settings or replica count. Keep the number of replicas at or below the number of Windows nodes unless autoscaling is turned on.

Renewing or replacing the TLS certificate

The certificate is stored in the Key Vault the deployment created, under the name cloudmersive-tls. To renew or replace it, import the new certificate as a new version of cloudmersive-tls. The gateway starts using it within a few minutes, and no redeployment is needed.

• Azure portal: open the Key Vault, select Certificates, select cloudmersive-tls, click New Version, and upload the .pfx file.
• Azure CLI: run the following command.

az keyvault certificate import \
  --vault-name <key vault name> \
  --name cloudmersive-tls \
  --file renewed.pfx \
  --password '<pfx password>'

The Key Vault name is shown in the deployment's keyVaultName output. Running the deployment again with a new PFX file has the same effect.

Private endpoints

The private endpoints option places the Key Vault, the container registry and the deployment script's storage account behind private endpoints inside the virtual network, and turns off their public endpoints. The deployment and the Virus Scan API keep working, because they run inside the network.

What changes for you is the Azure portal. The Key Vault's Secrets and Certificates pages and the container registry's Repositories page are read directly from your browser. From a network that is not connected to the virtual network, they show an error saying that public network access is disabled. Renewing the certificate through the Azure portal is then only possible from a computer with access to the virtual network, for example over VPN, ExpressRoute, a peered network or a jump host. Running the deployment again with a new PFX file still works from anywhere.

Turn this option on only if your organization already has private connectivity into its Azure networks. When private endpoints are enabled together with a container registry, the registry must use the Premium SKU. Turning the option off later re-enables public access, but leaves the private endpoints and their DNS zones in place until you delete them.

Removing the deployment

To remove everything, delete the resource group. The cluster's node resource group, which Azure creates automatically and names after your resource group and cluster, is deleted together with the cluster.

The Key Vault is created with purge protection, so after the resource group is deleted the vault remains in a soft-deleted state for 90 days and its name cannot be reused during that time. If you deploy again within 90 days into a resource group with the same name, use a different name prefix or set a different Key Vault name.