Skip to main content
Version: 2.22.0

Deployment

To deploy the ICAP server and the ICAP Profile Management API:

  1. Follow all the steps in the deployment overview to deploy Glasswall Halo for your chosen cloud provider.

    Once Halo is up and running, follow the steps below to deploy the ICAP server.

  2. Pull the ICAP server Helm chart:

helm pull oci://glasswallhub.azurecr.io/helm/icap-server \
   --version 2.2.3 \
   --untar \
   --untardir .
  1. Install the ICAP-server Helm chart:

Option A: Without MTS enabled

helm upgrade --install icap-server icap-server --atomic \
   --set image.tag="2.22.0-212371" \
   --set image.registry="glasswallhub.azurecr.io" \
   --set configuration.HALO__Version=2.22.0 \
   -n cdrplatform

Option B: With MTLS enabled

  • Create MTLS certificates by following Step 3 in the corresponding cloud provider.
  • Run the command below to sync the Kubernetes secrets with the secrets provider immediately.
kubectl annotate externalsecret external-secret force-sync=$(date +%s) --overwrite
  1. Deploy the Helm chart.
helm upgrade --install icap-server icap-server --atomic \
   --set image.tag="2.22.0-212371" \
   --set image.registry="glasswallhub.azurecr.io" \
   --set configuration.HALO__Version=2.22.0 \
   --set settings.ICAP.MutualTlsEnabled=true \
   -n cdrplatform

Note: configuration.ENABLE_MTLS was replaced by settings.ICAP.MutualTlsEnabled. An overlay or command still setting the old key stops the deployment with a message naming the replacement, rather than being ignored, so an existing overlay must be updated before upgrading.

Note: the ICAP server's certificate volume is always mounted, so enabling mutual TLS no longer changes the pod specification. It still takes effect on the next ICAP server restart, because the listener binds its port at startup.

Note: while mutual TLS is disabled the ICAP server does not bind the TLS port at all. Earlier releases bound the port and refused every connection on it, so an appliance deployed without certificates no longer reports that port as open.

Note: the ICAP-server deployment runs a cache cleanup job post-install and post-upgrade. To find out more, please refer to caching.

  1. Enable the ICAP Profile Management API in API-access with the clients__icapprofile__baseaddress configuration, which points at the policy API. It is unset by default, so ICAP profile endpoints stay unavailable until you set it.
helm upgrade --install cdrplatform-api-access cdrplatform-api-access \
   --set image.repository=glasswallhub.azurecr.io/cdrplatform-api-access \
   --set image.tag=2.22.0-212371 \
   --set configuration.CLIENTS__IcapProfile__BaseAddress="http://policy-api:8080" \
   --atomic

Note: leave this unset where the policy API is not deployed, so API-access does not advertise ICAP profile endpoints it cannot reach.

Note: the full list of available options for the API-access Helm chart can be found in the deployment steps based on the cloud provider used.

Turning the ICAP server on and off​

Once the chart is installed, an administrator starts and stops the ICAP server from the Portal: open Protection settings, select the ICAP tab, and use the control under ICAP configuration. Stopping it leaves the deployment and its saved settings in place, so turning it back on restores them.

The ICAP tab appears only when your licence includes the ICAP entitlement.

Where you have installed the Prometheus scaling chart with keda.icap.enabled=true, autoscaling owns how many ICAP servers run. The Portal control is then shown inactive with that reason, because a change made there would be reverted.

Note: upgrading an ICAP server release that was installed from a chart earlier than 2.2.0 starts the ICAP server once, whatever state it was in beforehand. If you had it stopped, stop it again after that first upgrade — from the Portal, or with:

kubectl scale deploy icap-server -n cdrplatform --replicas=0

Only the first upgrade behaves this way.

Specifying database provider​

During Helm chart deployment, the database provider can be configured with the configuration 'database__provider'. at the time of writing, Mongo and Cosmos are supported options.

--set configuration.DATABASE__Provider="Mongo"
Last updated on