Prerequisites - Helm - HiddenLayer Docs

Licenses

During Onboarding

Username and Password
- A username and password are provided during onboarding and is used to authenticate to HiddenLayer registries when downloading product images.
License IDs
- License IDs are provided during onboarding and are used as the registry password when downloading HiddenLayer products.
- The AI Security Platform: Self-Hosted/Air-Gapped install now bundles Runtime Security and AI Attack Simulation.
  Product License ID
  AI Security Platform (includes Runtime Security and AI Attack Simulation) AI Security Platform License ID

Product	License ID
AI Security Platform (includes Runtime Security and AI Attack Simulation)	AI Security Platform License ID

Hostname

A hostname for the HiddenLayer AI Security Platform.
- Example: http://server1.test.hiddenlayer.com.

Supported Cloud Providers

The AI Security Platform installation has been tested on AWS cloud infrastructure. The installation should work with other cloud providers.

Services

The below services are required for the Platform to be deployed and to function as expected.

For a detailed example of services, see Example AWS.

Service	Service Type	Requirements
Apache Kafka	Event Streaming	Kafka version is 3.6 or higher No authentication enabled.
OpenSearch - Platform	Event/report indexing and query	OpenSearch version is 3.x or higher No authentication enabled.
OpenSearch - FusionAuth	Search indexes for the identity provider	OpenSearch version is 2.6.0 or higher No authentication enabled.
PostgreSQL	Database	PostgreSQL version is 16.8 or higher Requires user account with superuser access Requires two PostgreSQL extensions pg_cron pg_partman
Redis	In-Memory Data Structure Store	Redis version 7.x or higher No authentication enabled.

What the Cluster Must Provide

The installer deploys only what is specific to the HiddenLayer AI Security Platform. It does not install, configure, or manage the cluster-level capabilities a production Kubernetes cluster is normally expected to provide.

The HiddenLayer AI Security Platform depends on several cluster capabilities. Installing the AI Security Platform on a cluster that lacks these capabilities will appear to succeed, but the pods will stay Pending or storage requests will go unfulfilled.

The following compute information is for the Helm installation of the AI Security Platform. For an Embedded Cluster installation, see the Embedded Cluster Prerequisites.

K8s

Kubernetes version 1.36 or newer.

You must have administrator access to the cluster to install the AI Security Platform.

Node Capacity and Scaling

The AI Security Platform installer does not deploy a cluster autoscaler. The configuration exposes scheduling rules under global.k8s.scheduling, separately for CPU and GPU workloads. Node affinity and tolerations that determine where each class of workload is placed.

global:
  k8s:
    scheduling:
      cpu:
        affinity: {}
        tolerations: []
      gpu:
        affinity: {}
        tolerations: []

Whatever placement you express here must be satisfiable. Either run static nodes that match the rules, or run an autoscaler capable of adding nodes that do. If neither is true, the affected pods remain unschedulable indefinitely. Kubernetes reports this as Pending with an “unschedulable” event rather than as an install failure. The same applies to raw capacity. The platform requests meaningful CPU and memory, and nothing in the install expands the cluster to accommodate it.

Persistent Storage

The AI Security Platform installer does not deploy a storage provisioner or a CSI driver. Components that persist data request PersistentVolumeClaims and expect a working StorageClass to fulfill them. global.k8s.storageClass is read by the object store and the in-cluster PostgreSQL only. Every other component’s claim goes to the cluster’s default class.

global:
  k8s:
    storageClass: gp3

If no usable class exists, PVCs stay Pending and the components that need them never start. A default StorageClass is required whatever global.k8s.storageClass is set to. The monitoring stack requests its volume without naming a class, in every install. This matters most where the installer deploys in-cluster copies of PostgreSQL, Kafka, OpenSearch or Redis. Supplying all five externally, as recommended for production, removes most of the platform’s storage demand.

GPU Nodes

The AI Security Platform installer does not install the NVIDIA GPU Operator or any GPU device plugin on a bring-your-own cluster.

CUDA GPU required for Runtime SecurityExamples: T4, A10, L4, L40, RTX PRO 4500, and RTX PRO 6000.

For GPU workloads, the cluster must already expose schedulable GPU resources (drivers, container runtime support and device plugin in place) and global.k8s.scheduling.gpu must place those workloads onto the nodes that carry them.

Ingress and External Exposure

The AI Security Platform installer does not deploy an ingress controller or load balancer. It deploys an internal nginx proxy, which is the single entry point to the product and is exposed as a ClusterIP Service listening on 8443. Getting external traffic to that service is the cluster operator’s responsibility. Common approaches:

Your own ingress controller. Set global.ingress.enabled: true and global.ingress.ingressClassName to your controller’s class, and the installer creates an Ingress resource pointing at the proxy. The controller itself must already be running.
A Service of type LoadBalancer, a NodePort, or a gateway of your choosing, routed to the proxy service on 8443.

TLS termination follows from that choice, either at your ingress or load balancer, or at the proxy.

How Much Compute to Provision

Approximate aggregate for the AI Security Platform’s own workloads, with PostgreSQL, Kafka, OpenSearch and Redis supplied externally as recommended. It is a planning figure for sizing a node pool or an autoscaler’s limits, not a guaranteed footprint. Actual usage scales with the traffic you send the AI Security Platform.

Resource	Requirements
CPU	16 vCPU
Memory	32 GB
GPU	1 GPU, on a node with a least 6 vCPU and 16 GB RAM of its own
Persistent Storage	50 GB, from your `StorageClass`.

Other things about the table:

GPU is required (global.gpu.enabled: true). One platform component uses a GPU, requesting a single device along with roughly 5 vCPU and 12 GB of RAM on the same node. Disabling the GPU is not recommended for production environments.
Object storage runs in-cluster regardless. The platform includes its own S3-compatible object store; there is no external-S3 option. It accounts for most of the persistent storage above.
The figures exclude the four external data services. Size those separately per infrastructure prerequisites. If you let the installer deploy in-cluster copies instead (evaluation only), add substantial CPU, memory and storage on top of these numbers.
Nodes must also leave room for whatever your cluster runs on every node: CNI, kube-proxy, logging agents, and the like.

Other cluster-level capabilities:

Also assumed present, and not installed by the platform: DNS (CoreDNS or equivalent), a CNI, certificate issuance if you want automated TLS, and cluster-level logging, backup and monitoring.
The AI Security Platform ships its own application monitoring components; it does not manage the cluster’s.

​Licenses

​Hostname

​Supported Cloud Providers

​Services

​What the Cluster Must Provide

​K8s

​Node Capacity and Scaling

​Persistent Storage

​GPU Nodes

​Ingress and External Exposure

​How Much Compute to Provision

Licenses

Hostname

Supported Cloud Providers

Services

What the Cluster Must Provide

K8s

Node Capacity and Scaling

Persistent Storage

GPU Nodes

Ingress and External Exposure

How Much Compute to Provision