Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Quick Start Setup Guide

This is a start-to-finish walkthrough for a new install. You will log in, connect your first Kubernetes cluster and storage devices, run the inventory and audit-ingest jobs, confirm that data is flowing, search the audit log, and optionally connect a Trino query engine.

Each section tells you:

  • What to enter.
  • The minimum permissions the account needs.
  • How to confirm it worked before you move on.

For the full compute-sizing table, every device field, firewall ports with direction, and data-flow diagrams, see Product Prerequisites. For per-tab detail, see the Setup pages: Clusters, Licensing, and Storage. This guide is the task-oriented path that ties them together.

Before you begin​

After you install the product and complete first boot:

  1. Browse to the console (https://<console-host>). On the first visit, the console asks you to create its administrator account: enter a username and a password of at least 8 characters. After that, log in with them.
  2. There is no database step. ClickHouse (audit store) and PostgreSQL (metadata) are configured automatically on first boot.
  3. Have the following ready:
    • Your license key.
    • A Kubernetes API endpoint and a service-account token.
    • The connection details and credentials for each PowerScale and/or ObjectScale device you want to protect.

The minimum permissions each account needs are called out in every section below.

Follow the sections in this order:

  1. Install your license.
  2. Add a Kubernetes cluster.
  3. Add storage devices.
  4. Run jobs and validate inventory collection.
  5. Ingest audit data and verify.
  6. Run audit searches.
  7. (Optional) Connect a Trino query engine.

Install your license​

Where: Settings > Licensing

Paste your license key into the License Key field and click Install. The status updates immediately, and the license activates the product features and branding for your subscription.

Confirm before moving on: the Licensing tab shows the license as installed and valid, with the correct product name.

For details, see Licensing.

Add a Kubernetes cluster​

Where: Settings > Clusters > Add Cluster

The cluster connection lets the product inventory your pods, PVCs, and nodes, and map storage back to the workloads that use it.

Fields​

All fields are mandatory unless noted.

FieldWhat to enter
Display NameA label for the cluster.
K8s API EndpointThe HTTPS API-server URL, for example https://<host>:6443, or your Rancher proxy URL.
Bearer TokenA service-account token with read access to pods, PVCs, and nodes. See the minimum permissions below.
Dell Storage Integration > CSI Namespace and CSI SecretSelect these so PowerScale-backed PVCs can be resolved to a path. The Dell PowerScale CSI driver must already be installed. Select its credentials secret, for example csi-isilon-creds.
RunAI sectionOptional. Leave it blank unless you use that integration.

Minimum permissions​

A read-only Kubernetes service account is enough (superna-k8security). The product only ever does get, list, and watch. No cluster-admin or write access is required.

Apply the bundled RBAC manifest k8s/k8security-rbac.yaml. It grants exactly the resources the product reads:

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

Then create a token:

kubectl apply -f k8s/k8security-rbac.yaml
kubectl create token superna-k8security -n superna --duration=8760h

Paste the token as the Bearer Token.

Confirm before moving on: click Test Connection and confirm that it returns a green check, then click Save Settings. After you run the Kubernetes scan in Run jobs and validate inventory collection, your nodes, pods, and PVCs appear in the inventory.

For details, see Clusters.

Add storage devices​

Audit logs and content are read from the storage devices. Each device needs connection details plus a service account with the minimum read permissions described below.

Select your storage platform.

Where: Settings > Storage > PowerScale > Add PowerScale Cluster

Audit logs are pulled over SSH/SFTP, so every field is mandatory:

  • Display Name and IP Address.
  • SSH Host (SmartConnect FQDN preferred), SSH Port (default 22), SSH User, and SSH Password.
  • Audit Log Directory: the remote path, default /ifs/.ifsvar/audit/logs.
  • OneFS Management API: Mgmt Host (default port 8080, HTTPS), Mgmt User (a platform-API role), and Mgmt Password.
  • Keep Ignore TLS on for OneFS self-signed certificates.

Ports used:

  • SSH 22 (audit-log transfer).
  • OneFS management API 8080 (HTTPS).

Minimum permissions: create a dedicated read-only role and user (svcaisec) rather than using root or admin. The role needs:

  • Login for the SSH audit-log pull and for the platform API.
  • Read-only file 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-ro ISI_PRIV_LOGIN_SSH    # SSH/SFTP for audit-log pull
isi auth roles modify svcaisec_ro --add-priv-ro ISI_PRIV_LOGIN_PAPI   # authenticate to the mgmt API
isi auth roles modify svcaisec_ro --add-priv-ro ISI_PRIV_IFS_BACKUP   # read the audit log dir
isi auth roles modify svcaisec_ro --add-priv-ro ISI_PRIV_SMB          # read SMB shares (read-only)
isi auth roles modify svcaisec_ro --add-priv-ro ISI_PRIV_NFS          # read NFS exports (read-only)
isi auth roles modify svcaisec_ro --add-priv-ro 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 the SSH and management user.

Confirm before moving on: Test SSH and Test Mgmt API both succeed, then click Save Settings.

For details, see Storage and Product Prerequisites.

Run jobs and validate inventory collection​

With the cluster and storage connected, run an inventory pass so the product discovers what to protect.

  1. Kubernetes scan: trigger a Kubernetes scan from the Jobs page, or with POST /api/k8/scan. If a scan is already running, the API returns {"running":true} with no job ID. Retry until you get a job_id, then wait for the job to complete.
  2. Storage inventory: run the PowerScale and ObjectScale inventory passes. They discover clusters, exports, and buckets.

Validate:

  • Kubernetes: your nodes, pods, and PVCs appear (Lifecycle Watch or Data Security Posture).
  • PowerScale: the cluster is listed and its exports and paths resolve.
  • ObjectScale: buckets are listed, and COSI-provisioned buckets show as COSI-managed.

COSI-managed status is what binds a bucket to the pod using it. It requires the COSI RBAC grant from Add a Kubernetes cluster. Without it, the bucket is discovered but never bound.

If a bucket is discovered but not COSI-managed, re-check that the cluster service account can list the COSI buckets resource.

Ingest audit data and verify​

The console pulls file and object audit logs and writes them into ClickHouse:

  • PowerScale: over SSH/SFTP.
  • ObjectScale: over SSH/SCP.

Trino audit works the other way: Trino pushes it to the console.

  • Audit ingest runs on a schedule. To pull immediately after connecting a device, trigger an ingest-now for that storage type.
  • Audit collection is forward-looking: only activity that happens after the device is connected is captured. Generate some file or object activity if you want to see events right away.

Validate:

  • The Ingest Offsets page shows the ingest advancing for each source.
  • Audit event counts climb for the connected devices.
  • Optionally, allow a few minutes. OneFS relays audit to the log directory with a short delay before the console pulls it.

For details, see Ingest Offsets and File Activity.

Run audit searches​

Where: Data Auditing > File Activity

  1. Set the date range first.
  2. Choose the Protocol:
    • SMB or NFS searches PowerScale file audit.
    • S3 searches ObjectScale object audit. Selecting S3 switches the source automatically.
  3. Narrow the results with the optional filters, which are combined with AND:
    • Operation, for example DELETE, write, or PUT.
    • Bucket (S3).
    • Storage Cluster.
    • For PowerScale, the path and user fields.
  4. Click Search. Results are paginated, and the Operation column is color-coded so destructive operations stand out.
  5. Optionally, click CSV to export the results.

Validate: a search over a recent window returns the activity you generated in Ingest audit data and verify.

For details, see File Activity.

(Optional) Connect a Trino query engine​

This section is relevant only if you run Trino (for example with Dell AIDP) and want SQL query activity audited alongside file and object audit. It is an optional, licensed capability. Skip it if you have no Trino engine.

Where: Settings > Trino Audit

  1. Generate an ingest token (Generate or Rotate). The plaintext value is shown once. Copy it, because it is encrypted at rest and never shown again. Rotating immediately invalidates the previous token.
  2. Make sure the plugin JAR is hosted on the console. The status card shows this.
  3. On the Trino coordinator, run the console-provided one-line install.sh command. Run it as a user who can write Trino's plugin/ and etc/ directories. It downloads the plugin, places it in plugin/superna-audit/, and writes the event-listener configuration with the console URL and your token.
  4. Restart the Trino coordinator. Trino loads event listeners only at startup, so nothing is audited until it restarts.
note

The OVA/appliance default is HTTPS with a self-signed certificate. For a self-signed console, do one of the following:

  • Install the console's CA on the Trino host.
  • Use the TLS-skip installer: append &tlsSkipVerify=true to the install.sh URL, and fetch it with curl -k. The script then downloads the JAR with curl -k and adds superna-audit.tls-skip-verify=true to the plugin configuration, so ingest works over the self-signed link.

Also set Console DNS on Settings > Trino Audit to a bare host or host:port. Do not include http(s)://, and do not add a port that is already the browsing port.

Minimum permissions (Trino side):

  • The ingest token is scoped to the single /api/trino-audit/ingest endpoint. It cannot reach any other API, setting, or table.
  • The coordinator-side account only needs write access to Trino's plugin/ and etc/ directories and the ability to restart the coordinator.

Validate: run a few queries on Trino, then open File Activity > Structured Data Audit (Trino). Your queries appear as rows (who ran what SQL against which catalog, schema, and table).

A 401 response on ingest means the token is wrong or was rotated. Rotate the token and reinstall.

For details, see Trino Audit.

Next steps​

Once the cluster and storage are connected and the jobs have run, audit data ingests automatically. Discovered files and objects flow through the classification pipeline (extraction → linguistic coherence, if licensed → classification) and surface in Data Security Posture.

From here, explore:

Use File Activity for ongoing audit investigations.