Product Prerequisites

This guide covers what Data Security for Dell AI Infrastructure needs before you install it and connect your first devices:

• Compute and registry requirements.
• Per-device connection details and credentials.
• Least-privilege service accounts.
• The firewall ports that must be open, with direction.
• How audit data and the classification pipeline flow through the system.

For the task-oriented walkthrough, see the Quick Start Setup Guide.

Two ways to deploy:

• VMware appliance (OVA): the console runs in a virtual machine, and the pipeline agents run on Linux hosts that you provide. See Install on VMware (OVA).
• Kubernetes (Helm): the console, its databases, and the pipeline agents all run in your cluster. See Install on Kubernetes (Helm).

Compute and registry requirements

The console is validated against Kubernetes v1.31 to v1.37. This applies to the cluster the product runs on and to any monitored cluster that you add on Settings > Clusters. The card of each monitored cluster shows its observed version and flags it if it falls outside this range.

A newer cluster still scans on a best-effort basis, and unknown fields from a later Kubernetes release are tolerated. Versions outside the validated range are not fully tested. Upgrade the console to get official support for a newer Kubernetes version.

VMware appliance (OVA)

The requirements of the virtual machine are in Install on VMware (OVA). The pipeline agents run on Linux hosts that you provide. Their requirements are on System Operations > Fleet Management > Agent Installation. See Agent Installation.

Kubernetes (Helm)

The sizing below is the validated configuration in the example values files of the chart, which are the starting point in Install on Kubernetes (Helm). Memory is the per-pod limit, CPU is the request, and disk is the persistent volume per pod.

Component	Pods	Image	CPU (request)	Memory (limit)	Disk
Console	1	aisec-console	4	6 GiB	1 GiB
Extraction agent	1	extraction-agent	2	4 GiB	2 GiB
Linguistic Coherence (LC) agent	2	lc-agent	4 each	12 GiB each	2 GiB each
Classify agent	2	classify-agent	4 each	8 GiB each	2 GiB each
PostgreSQL (metadata / OLTP)	1	postgres	0.5	1 GiB	30 GiB
ClickHouse (audit store)	1	clickhouse/clickhouse-server	4	30 GiB	250 GiB

Totals: about 26.5 CPU requested, 81 GiB of memory limits, and 291 GiB of persistent volumes, plus the two bundled operators.

The defaults of the chart, which apply when a value is not set, differ. For example, ClickHouse defaults to 500 GiB of disk and PostgreSQL to 100 GiB. Size the ClickHouse disk for your audit volume and retention.

Pipeline agents scale by replica count. Each extra agent adds the figures of its row.

Container image registry

Kubernetes installs pull the product images from a registry. The VMware appliance ships with its images and needs no registry access. It is the deployment to use for an air-gapped site, because air-gapped Kubernetes installs are not supported.

What	Value
Image registry (server)	northamerica-northeast2-docker.pkg.dev/superna-579/oci/aisecurity. Google Artifact Registry, public and anonymously pullable. No pull secret is needed for the Superna images.
aisec images	aisec-console, extraction-agent, lc-agent, and classify-agent under the registry above. Set the image tag of the release you deploy. See Install on Kubernetes (Helm).
Helm chart (OCI)	oci://northamerica-northeast2-docker.pkg.dev/superna-579/oci/aisecurity/charts/aisec, at the chart version of your release. Requires Helm 3.18.6 or newer.
Public dependencies	PostgreSQL, ClickHouse, the CNPG and Altinity operators, and the console init busybox image pull from ghcr.io and docker.io.
Port / protocol	443 / HTTPS (outbound)

note

Private mirror: to pull from your own registry (Harbor, Artifactory, or Nexus), repoint default.image.registry (the Superna images) and each dependency's <component>.image.registry at it. Every image also supports digest-pinning through <component>.image.digest in values.yaml.

Devices, accounts, and API keys

Each device below matches an add-device form on Settings > Clusters or Settings > Storage. Provide the endpoints and the account, and create the API key or token as shown. Optional integrations are marked.

Kubernetes cluster

• Add-device fields: API Endpoint https://<host>:6443 (or the Rancher proxy URL), plus Dell CSI namespace and CSI secret for PowerScale PVC discovery. The Dell PowerScale CSI driver must already be installed.
• Account required: a service account with read access to pods, PVCs, and nodes.
• API key or token: run the following command and paste the result as the Bearer Token.

kubectl create token <sa> -n <ns> --duration=8760h

PowerScale (OneFS)

• Add-device fields:
  • IP.
  • SSH host (SmartConnect FQDN) on port 22, plus user and password.
  • Audit Log Dir /ifs/.ifsvar/audit/logs.
  • OneFS Mgmt host on port 8080, plus user and password.
• Account required: an SSH user (audit-log read) and a OneFS user with a Platform-API role.
• API key or token: none. Use a OneFS local or AD user, and assign a platform-API read role (user and password only).

ObjectScale / Dell ECS

• Add-device fields:
  • Management Endpoint on port 4443.
  • S3 (data) Endpoint on port 9020 (HTTP) or 9021 (HTTPS).
  • SSH admin:22 (audit-log SCP).
• Account required: an ECS management user and an S3 access/secret key pair.
• API key or token: in the ECS Portal, open the user and generate the S3 secret key. The management user is the ECS management login.

RunAI (optional, GPU and workload context)

• Add-device fields: Base URL https://runai.<domain>, Client ID, and Client Secret.
• Account required: a RunAI Application (OAuth client).
• API key or token: in the RunAI UI, go to Settings > Applications > New, then copy the Client ID and Client Secret.

Trino audit (optional, event-listener plugin)

• Add-device fields: none. Trino audit is configured on the Trino coordinator, not in an add-device form. The plugin posts to POST /api/trino-audit/ingest on the console.
• Account required: a Trino audit ingest token, stored AES-256 encrypted on the console.
• API key or token: on Settings > Trino Audit, generate or rotate the token. Then run the console-provided install.sh?token=… one-liner on the coordinator and restart it.

The Trino coordinator reads its settings from etc/event-listener.properties:

event-listener.name=superna-audit
superna-audit.console-url=https://<console>
superna-audit.ingest-token=<token from Settings > Trino Audit>
superna-audit.batch-size=100
superna-audit.tls-skip-verify=false     # true for lab use only

Minimum permissions

Connect each integration with a dedicated, clearly named least-privilege account, svcaisec. The account grants exactly what the product's ingest, inventory, audit, and read-access code paths touch, and nothing more. Do not use root, admin, or cluster-admin.

The task-oriented walkthrough is the Quick Start Setup Guide.

Integration	Identity	Minimum grant	Provisioned by
Kubernetes	SA superna-k8security	Read-only ClusterRole (get/list/watch), bundled k8security-rbac.yaml	kubectl apply
PowerScale	User svcaisec (role svcaisec_ro)	LOGIN_SSH, LOGIN_PAPI, IFS_BACKUP; SMB/NFS/AUDIT read-only	OneFS admin (isi CLI)
ObjectScale (mgmt)	Mgmt user svcaisec	System Monitor plus Namespace Administrator per protected namespace	ECS Security Administrator
ObjectScale (SSH)	Local audit user	Login plus read/list on the deployment-type log path (no sudo, write, or shell)	ECS node admin
RunAI (optional)	Read-only Application (OAuth client)	Viewer/researcher read scope	RunAI admin
Trino audit (optional)	Ingest token	Scoped to the single /api/trino-audit/ingest endpoint	Settings > Trino Audit

Kubernetes read-only service account

The product only ever does get, list, and watch. No cluster-admin or write access is required.

Apply the bundled RBAC manifest. It grants exactly the resources the product reads:

• nodes, namespaces, pods
• persistentvolumes, persistentvolumeclaims
• secrets (Dell CSI credential discovery)
• deployments, replicasets, storageclasses
• The RunAI CRDs
• The COSI buckets and bucketaccesses (required for ObjectScale bucket↔pod binding)

kubectl apply -f k8s/k8security-rbac.yaml
kubectl create token superna-k8security -n superna --duration=8760h   # paste as the cluster Bearer Token

note

A 403 on the COSI buckets resource silently breaks ObjectScale bucket↔pod binding: buckets are discovered but never marked COSI-managed.

Optional hardening: scope secrets to the Dell CSI namespace with a namespaced Role and RoleBinding instead of the cluster-wide grant. Verify that CSI PVC→path resolution still works.

PowerScale (OneFS) read-only role and user

Create a dedicated read-only role and user rather than using root. The role needs:

• Login: SSH/SFTP for the audit-log pull, and PAPI to authenticate to the management API.
• Read access to the audit directory.
• Read on SMB/NFS shares and the auditing configuration, for the read-only OneFS management features.

The role needs no write or provisioning privileges.

isi auth roles create svcaisec_ro --description "Superna AI Security read-only service account"
isi auth roles modify svcaisec_ro --add-priv ISI_PRIV_LOGIN_SSH     # SSH/SFTP audit-log pull
isi auth roles modify svcaisec_ro --add-priv ISI_PRIV_LOGIN_PAPI    # authenticate to the mgmt API
isi auth roles modify svcaisec_ro --add-priv ISI_PRIV_IFS_BACKUP    # read the audit dir (bypasses ACL; RESTORE omitted)
isi auth roles modify svcaisec_ro --add-priv-read ISI_PRIV_SMB      # read SMB shares (read-only)
isi auth roles modify svcaisec_ro --add-priv-read ISI_PRIV_NFS      # read NFS exports (read-only)
isi auth roles modify svcaisec_ro --add-priv-read ISI_PRIV_AUDIT    # read auditing config (read-only)
isi auth users create svcaisec --enabled yes --set-password
isi auth roles modify svcaisec_ro --add-user svcaisec

Use these credentials as both the SSH user and the OneFS management user.

• --add-priv grants an action or login privilege.
• --add-priv-read grants read-only.
• ISI_PRIV_IFS_RESTORE and all share and configuration write privileges are deliberately omitted.

ObjectScale (Dell ECS)

ObjectScale read access is not a plain read-only account. The product creates a per-namespace reader IAM user with a read-only S3 policy. The management identity therefore needs IAM-admin within each protected namespace, plus cluster-wide read for inventory. The reader the product provisions is least-privilege, and the management identity is scoped to inventory-read plus per-namespace IAM.

Management-API account:

• System Monitor (cluster-wide: ListNamespaces, ListBuckets).
• Namespace Administrator on every namespace this system protects. In the ECS Portal, go to Manage > Namespace > namespace > Edit > Namespace Administrators.
• Namespace Admin covers creating and managing the per-namespace reader. It is not full System Admin.
• Creating the management user itself requires a Security Administrator on ECS.

Reader (auto-provisioned):

• The product creates a per-namespace IAM user with a read-only S3 policy (s3:GetObject, s3:ListBucket).
• You do not create it by hand.

SSH/SCP audit account:

• Login plus read and directory-listing only on the audit-log directory for your ECS Deployment Type.
• No sudo, no write, no shell. The product only lists and reads files over SFTP.
• ECS has no granular SSH RBAC through its management API, so this is a local OS user on the ECS node (no wheel or docker group, no sudo). Grant read and list on the specific directory rather than assuming default access.

ECS Deployment Type (Settings)	Audit-log path
ObjectScale / Virtual ECS (default)	/var/log/vipr/emcvipr-object
Hardware ECS Appliance	/opt/emc/caspian/fabric/agent/services/object/main/log
Custom	The path you supply

note

The COSI driver for ObjectScale must be installed so COSI-provisioned buckets are discovered and bound to their pods. This binding also requires the Kubernetes COSI RBAC grant described in Kubernetes read-only service account.

RunAI (optional)

Create a dedicated RunAI Application (OAuth client) with a read-only / viewer scope sufficient to list projects, workloads, and users. The console only reads workload and user context for topology attribution. Copy the Client ID and Client Secret into the cluster integration.

Trino audit (optional)

The Trino integration uses a console-issued ingest token, not a platform account.

• The token is scoped to the single POST /api/trino-audit/ingest endpoint. It cannot reach any other API, setting, or table.
• Rotating the token immediately invalidates the previous value.
• On the Trino side, the account that runs the installer only needs write access to Trino's plugin/ and etc/ directories and the ability to restart the coordinator. It needs no product-side privileges.

Firewall ports and direction

Outbound means the console initiates the connection to the device. Inbound means an external client (or a device) connects to the console.

Direction	Source → Destination	Port / proto	Purpose
Outbound	Console → ObjectScale / ECS management	4443 / TCP HTTPS	Bucket inventory, management API
Outbound	Console → ECS S3 data	9020 / TCP HTTP · 9021 / TCP HTTPS	S3 read (read-access verify)
Outbound	Console → ECS / ObjectScale SSH	22 / TCP	Audit-log SCP
Outbound	Console → PowerScale SSH	22 / TCP	Audit-log SFTP
Outbound	Console → PowerScale OneFS management	8080 / TCP HTTPS	OneFS platform API
Outbound	Console → Kubernetes API server	6443 / TCP (or 443 via Rancher)	Pod / PVC / node discovery
Outbound	Console → RunAI (optional)	443 / TCP HTTPS	GPU / workload context
Outbound	Kubernetes nodes → northamerica-northeast2-docker.pkg.dev (Google Artifact Registry) + ghcr.io/docker.io (deps)	443 / TCP HTTPS	Image pull + Helm chart (Kubernetes installs)
Outbound	Console → support relay (supportbot.superna.io) (optional)	443 / TCP WSS	Remote support
Inbound	Operator browser → Console UI	443 / TCP HTTPS (the VMware appliance also answers on 80 and redirects to HTTPS; on Kubernetes, through the ingress)	Web console
Inbound	Trino coordinator → Console /api/trino-audit/ingest (+ plugin.jar, install.sh)	443 / TCP HTTPS	Structured (Trino) audit push + plugin fetch
Inbound	Pipeline agents → Console	443 / TCP HTTPS (on Kubernetes, the cluster network)	Agent enrollment, heartbeats, image download, results
Between agent hosts	Extraction agent hosts → LC / classify agent hosts	9101–9102 / TCP	Work hand-off (VMware appliance with agents on your hosts). See Agent Installation.
Outbound	Extraction agents → PowerScale (data interface)	22 / TCP (the SSH port of the cluster)	Read the files to classify (SFTP)
Outbound	Extraction agents → ECS / ObjectScale S3 endpoint	9020 / TCP HTTP · 9021 / TCP HTTPS (or 443)	Read the objects to classify (S3)
Loopback	Health probe → Console	8082 / TCP	Container health check

Data flow diagrams

Audit ingestion and management-API calls

• The console pulls file audit logs over SSH/SFTP (PowerScale) and SSH/SCP (ObjectScale).
• Object management data uses the ECS management API (4443) and the S3 API (9020/9021).
• OneFS configuration is read over the platform API (8080).
• Trino pushes query audit to the console over REST (HTTPS, 443).
• All audit records land in ClickHouse.

Classification pipeline

Discovered files and objects are enqueued as work items. They then flow through extraction → linguistic coherence (LC, optional/licensed) → classification. Results (PII, coherence verdict, classification) are written to ClickHouse and surfaced in Data Security Posture.

Install sequence

1. Install the product. Follow Install on VMware (OVA) or Install on Kubernetes (Helm).
2. Install the license on Settings > Licensing.
3. Add a Kubernetes cluster on Settings > Clusters: API endpoint, bearer token, and Dell CSI namespace and secret. Use the read-only service account described in Kubernetes read-only service account.
4. Connect storage on Settings > Storage: PowerScale (SSH and OneFS management) and/or ObjectScale (management, S3, and SSH). Use the least-privilege accounts described in PowerScale (OneFS) read-only role and user and ObjectScale (Dell ECS).
5. (Optional) Add RunAI on the cluster.
6. (Optional) Enable Trino audit on Settings > Trino Audit: generate the token, then run install.sh on the coordinator.
7. Open the firewall ports listed in Firewall ports and direction: outbound to devices and the registry, inbound for the console UI and the Trino push, and between agent hosts.

Once the devices are connected, audit data ingests automatically (see Audit ingestion and management-API calls). Discovered files and objects flow through the classification pipeline (see Classification pipeline).

For a guided walk-through of searching the audit data, see the File, Object and Trino auditing overview Quick Start tour (Help > Quick Start).